By Josep Laborda, RACC (first published on LinekdIn Pulse)

We (all) love Google. The user interface of its search engine is sleek and dead simple to use. It’s basically composed of a beautiful, clean logo, and a big, neat search box. What else? Well, a closer look at Google’s main page will reveal some links at the footer (leading to privacy – will come back later to this topic -, terms of use, settings and other boring stuff), and direct links to services like Gmail and Youtube at the top right corner (I personally only seldom have entered my Google account from the search page, and I have never clicked any of the tiny links at the bottom). All in all, it’s an extremely well-designed and intuitive front-end where you know exactly what to do (enter a search term) and what to expect (tons of useful results for your query). All the magic happens in the back-end. It’s that easy (oh yes, there is a huge amount of talent and super-complex code behind Google’s search algorithms, but that’s another story). And, last but not least: it’s free!

Google search engine has become a massive success story (among other factors) because…

it solves a common problem (crawl the Internet to find the right content you need)…
in an easy (my father – not a digital literate – can use it and I don’t need to explain him how)…
convenient, (no need to sign up, no personal data requested – well, this is apparently true, but again, will come back later to this!) and…
economical way (no payment hassle, because you simply don’t pay for the service… apparently).

Now, what other common problems or needs can you think of? Personal communication? There you have Gmail for e-mail and Google Hangouts for messaging, telephone or video calls. Get directions, find places? There you have Google Maps, that you find on all Android devices and can be found in most other smartphones (I’m still amazed about the Street View feature), and you might as well explore the world from the palm of your hand with Google Earth. Create and share documents? No need to pay Gates for MS Office with Google Docs, Slides and Sheets. Despite some failed projects and having serious competitors for some of their services, it seems Google has an awesome free service for all your everyday needs…

Oh, wait… What about transportation? This is all about going places in our busy lives: our daily journey from home to work (and vice versa), driving kids to school (and then jumping into a gridlocked commute), going to the mall (and the “need” to have a big boot available in our car for the shopping bags), getting to the airport in time for our flight after a meeting on the other side of the city that is well far from a convenient public transport connection. All in all, a hell of possible combinations that are often not so easy to understand, which is especially annoying when strayed from our daily travel routine, with so many different operators behind, and too often not a flexible enough offering that would cover all of our mobility needs (the reason why many urban dwellers still keep their extremely inefficient, expensive and polluting private cars parked 95% of the time at the garage, for when they will “need” them).

Transportation is a common, huge challenge, especially in cities. Luckily, and not surprisingly, there have arisen hundreds of ICT-powered services / apps that solve (sometimes brilliantly) pieces of the whole mobility puzzle / challenge: the ubiquitous Google Maps for trip planning, traffic and transit information; Waze (acquired by Google) for crowd-sourced traffic information; RACC Infotransit for real-time and predictive traffic, plus other mobility contents (parking, fuel prices, speed cams, etc.) in Spain; Uber and Lyft competing in the same space to match private drivers with users in need of a ride (with some experiments of Uber and Lyft with car-pooling services, named UberPool and Lyft Line, among other initiatives launched in some markets); BlaBlaCar, the pioneer of car-pooling; MyTaxi and Hailo, the well-known taxi-booking apps (with MyTaxi first acquired by Daimler to be integrated into Moovel – the German automaker’s notable attempt to implement MaaS -, and later merged with its rival Hailo to take on Uber); expanding car-sharing services like Car2Go (also owned by Daimler, and integrated into Moovel) and DriveNow (owned by a joint venture between BMW and car-rental company Sixt); peer-to-peer car-sharing services, like the Spanish SocialCar; trip planners like CityMapper, and Moovit; and a growing number of startups entering the mobility scene, with more and more alliances between automakers, startups and tech giants. Some apps provide information, both static (transit schedules, points of interest, etc.) and in some cases real-time and even predictive (on the traffic status, on transit schedules and eventual delays, on availability of parking spots, etc.); other apps also provide services (routes to avoid congestion, rent a vehicle, hail a taxi, pay for parking, etc.). Some introduce “new” mobility paradigms that are beginning to gain traction: (P2P) car-sharing, car-pooling, ride-sharing, etc. And all of them rely on two interconnected trends. On the one hand, the spread of smartphones, which provide ubiquitous Internet access and geolocation. On the other hand, the rise of the “sharing economy”, where social networks help building trust networks among strangers and therefore remove barriers to sharing available capacity (e.g. share a vehicle – car, bike -, or rent your car to a stranger), and thus cut costs, among other win-wins (e.g. less privately-owned cars + electrification of transport means less pollution, etc.).

The next step is to combine these disparate mobility experiments with public transport (a key, central piece of the urban mobility puzzle), rental cars, taxi, and parking (yes, we need to park our private cars safe when connecting with public transport; they call this “park & ride”!) to get the traveller seamlessly from door to door, combining the various options in the most efficient and cost-effective way. I personally hate having so many mobility apps on my smartphone and paying separately for my monthly public transport card, my eventual taxi rides, parking, etc. That is why I find the idea of “Mobility as a Service” (MaaS) so appealing: a single app that includes pay-as-you-go or monthly subscription multi-modal packages that bundle monthly travel requirements at a single price (for instance, get unlimited public transport + 8 hours / month of bike share + 50 Km / month of taxi + 4 hours / month of car share at X €).

Let’s use the following parallelism to explain the idea of delivering MaaS, from a very conceptual point of view: electricity or water supply are considered basic “services” for households. The only thing you have to do as a consumer is contract a utilities company, have your home installation connected to their distribution network (they will do that for you, no hurdles!) and provide your bank account number. You then just turn on the light or the tap and get the electricity or water flowing. This simple (provided you keep paying your bills!). Your utilities company will take care of everything (from generation to distribution, accounting for taxes, etc.) needed to take electricity or water services to your home. It’s like the magic behind Google Search. You just enter a search term and wait for results. And it’s the same magic behind MaaS unique selling proposition. Buy a (customized) mobility package to your MaaS operator and get moving. No need to care about buying transport tickets anymore, no need to sign in for different mobility service providers (MSP), no need to interface with different apps. A single touch point and a flat rate you have under control.

The MaaS pitch idea is neat and, like with other innovations that come across as obvious solutions for problems, it makes you think: “Why didn’t anyone think of that before?” Likewise, as with every disruptive idea, there are not so clear aspects (that are closely interconnected) that will need to be tackled by any player aiming at deploying MaaS for real (it’s the execution that matters, not the idea!):

The users: today, more than half of the world’s population lives in urban centres. It’s an increasing trend that poses many urgent challenges for (smart?) cities. An obvious one is transportation, aka mobility. So, if you offer mobility as a service, in principle you should expect to have (millions of?) users willing to pay for this service. Great. The (potential, future) users of a new service, though, need to be “seduced” with new approaches to their everyday needs (like mobility), and MaaS presumes a change in our mindsets, where owning a car would not be indispensable (especially when there would be other cheaper and equally convenient alternatives). Millenials and young urbanites are likely to be early adopters of “many-things-as-a-service” (music, movies, …, mobility, probably). But, what about my father? He can use and loves Google Search in his brand new iPhone, but I doubt he will (ever?) get rid of his car. We’re creatures of habit, mobility is indeed a habit, and this is difficult to change. The question is whether the first MaaS schemes will reach a sufficient user base to validate a positive business case.

The business model: owning a car is expensive, undoubtedly. Consider the purchasing price (and the quick depreciation that follows), the financing costs, insurance, taxes, fuel, and maintenance. Consider average private car usage is around 4-5% in urban areas. And many might end up concluding it was not a good business to buy a car. Moreover, car / bike sharing, ride sharing and other mobility services are flourishing in cities as a real alternative to the private vehicle (add public transport to the equation and there you have the ingredients of any MaaS offering). Now, MaaS Global’s pitch states that the TCO of private cars is not sustainable for many users, and that the ARPU (Average Revenue Per User) in transport (in other words, the money in the users’ pocket they are willing to spend, monthly, in transportation) is an average of 300 €/month, 10 times bigger than the ARPU of the telecom industry. Consider there might be millions of users in urban areas willing to buy MaaS and it would shape a global market worth some trillion €. Fair enough. This is a pitch that works for conferences and public presentations, but I’d rather prefer to have more realistic insights into the pitch used to engage investors in first “real” MaaS implementations. There, fussier, much more interesting questions are answered behind closed doors (or concrete plans are presented to overcome the complexities and specifics of each city, and the stakeholders involved). For instance, how will a given MaaS implementation find a good balance between the interests, roadmaps (strategic/tactical and technical), fears, and prejudices of different stakeholders involved in a city or region? Why would a ride-sharing or taxi firm want to sign up to a scheme that may direct customers to its rivals? What’s the role public authorities aim at playing in the whole game (“privilege” public transport at all costs? Or support innovation and alternative modes of personal transportation?). It’s not only about having a consistent and credible business model and some sound business cases for MaaS, but to combine (to some extent) the business model and business cases of each disparate MSP included in a given MaaS scheme, which implies, among many other aspects, identifying win-win “opportunities” on a case-by-case basis (e.g. public transport – and taxis as well – run almost empty in some off-peak time frames, which makes it extremely inefficient and expensive to maintain; could a smart MaaS scheme contribute to better balance the mobility choices of the users?).

Privacy: data is today’s currency. In the digital era, customers demand personalized and reliable products and services, at the time and in the place they want them. Thanks to a large amount of data being made available by the billions of connected devices out there, it’s easier than ever before for businesses to meet these expectations. But all this comes at a cost: there is no real privacy. Whim, MaaS Global’s app, makes it clear in the description of the service: “The more Whim is used, the more it learns about users’ preferences. Like a dynamic and intelligent personal assistant, it syncs with their calendar and suggests the best way to get to every event”. Firms such as Bridj are using the wealth of data they collect from users’ smartphones to model travel patterns, and thus to run on-demand minibusses in several American cities. Likewise, Google Now uses (anonymized?) location data from their users to notify them of disruptions to their commute due to traffic, among other recommendations. Access to data is essential to run a good service, and to implement the needed corrections to it on the go, in a continuous improvement strategy. The threat is that data might as well be used for purposes other than providing an outstanding service (no need to mention how Google reaps huge benefits from the wealth of their users’ data; by the way, go check this!). Data ownership is a hot, controversial topic in mobility. While consumer organizations like the FIA and automobile clubs are calling on automakers to be transparent about what data they collect from connected cars, automakers themselves have Google’s Android Auto as a serious Trojan horse. Now, add some level of automation to any of the legs of the (multimodal) trip (automation clearly is the technology that will make many mobility services profitable, in the long run, and the major players, like Google, and Uber, have well understood this by investing huge amounts of money into getting rid of drivers). Self-driving cars must integrate driver monitoring systems for the sake of safety. Therefore, data privacy cannot be 100% safeguarded; this is just not possible, nor reasonable (by the way, I am happy to further elaborate on this topic in the context of the H2020 research project ADAS&ME). Nevertheless, technology is not sufficient. Without other factors in place – the right business models, the tools for collecting, analysing and sharing the relevant type of data, and the correct standards and policies – we stand to gain nothing.

Technical aspects: the IT infrastructure supporting a MaaS implementation is key for the “magic” to happen, that is, that every single transaction, every interface to and from connected back-end systems exchanging data, the business intelligence (aka big data processes) needed to tailor the service to the specific users’ needs, but also the user interface (typically, an app) work seamlessly from the end-user point of view, realising the ultimate MaaS vision of providing ease of mind for the travellers, a user experience close to that of turning the light on: you just need mobility (as a service!), right here and now, so you turn your app on and, with just a few taps you easily get flexible alternatives to get to your wanted destination, no worries about how this is managed from the technical side. It’s “the brains of Maas”, ultimately. The IT back-end system manages the business processes (booking, payment, ticketing, identity management, security clearance, …), interfacing with the information systems of the different MSPs included in a given MaaS scheme (this will sometimes imply the inevitable pain of dealing with old legacy systems, especially those of public transport operators). In order for the whole thing to work smoothly and the MaaS market to develop to its enormous potential, building blocks (IT systems, but also hardware) should be as interoperable as possible to enable multivendor capability and avoid vendor lock-in, system architectures and interfaces should be designed with an “openness” approach in mind (this has many technical implications!) and based on standards (noteworthy is one of Google’s notable contributions to the transportation sector, that is creating GTFS, a de facto standard defining a common format for public transportation schedules and associated geographic information). In general, MSPs have well understood the need to open their APIs/SDKs to third-parties and developers to stimulate a healthy mobility ecosystem (countless are, for instance, the services and applications that build on Google Maps API); public transport operators, on the other hand, still too often fail at implementing real open data policies that work, with nice exceptions like Transport for London, which created the conditions for CityMapper to pop up, one of the best-known open data success stories (which today integrates data from other big players in the mobility scene, like Google – it’s only natural! -, Open Street Maps, Uber, Hailo, Car2Go, Autolib and more). Data is the new currency, that is true, but data needs to turn into information, and standards are needed for this. A standard worth exploring for MaaS is SIRI (which in turn is based on the Transmodel abstract model for public transport information), but there are many more standards for public transport data, and for other types of mobility-related data; therefore, cooperation is very much needed with Standard Development Organizations (SDOs).

Legal and policy-related aspects: stakeholders willing to deploy MaaS must seek complicity from and cooperation with public authorities and policy makers to identify legal and regulatory barriers to MaaS (both at European but also at a local level), and put the required legal framework in place to overcome these. Finland, in that respect, is pioneering the development and implementation of MaaS, and has recently put a nice legislative piece of work and strategic roadmap in place, the Transport Code Project of the Finnish Ministry of Transport and Communications, which postulates the Finnish as forerunners in the MaaS expansion, setting the ground for other cities and regions to follow. Political buy-in must be based on a smart combination of different factors: the social benefits of MaaS (fewer cars on the road means less pollution, enhanced productivity of travellers as a consequence of reduced congestion, etc.), the potential of MaaS to bring more users to public transport (and taxi, too!), and fostering new mobility services to ease citizens’ lives. In order for MaaS to be successfully implemented in a city or region, though, an existing rich (and flexible) urban mobility ecosystem is required. In this regard, there are many local policy measures and incentives that can be rather easily implemented (while aligned with the specific urban mobility plans of a city) such as, for instance, free parking for shared EVs in the city. Public authorities play a determinant role in enabling the conditions for new mobility services to be launched, that can later be integrated into MaaS schemes. Yet, at the same time, there are often conflicts between the different MSPs competing for the same users in an area, especially when there is not a clear existing legal framework supporting the new ones entering the market (e.g. in some countries, Demand-Responsive Transit services, to some extent, or services like Uber, more notably, have faced a strong opposition from the taxi sector, that is tightly regulated). In my opinion, innovation and regulation don’t mix well. That is why I believe political interventionism should be delimited in order for MaaS to spread in cities to its full potential, as innovation is often mainly driven by private enterprises. However, a fluid cooperation with public authorities is absolutely essential, as public transport no doubt must be a central piece of any MaaS scheme, and because there is a lot of legislative work still pending, such as that for enabling driverless vehicles in our roads, and streets.

The prospects for Mobility-as-a-Service are certainly promising, with some trailblazing cities, entrepreneurs, technology firms and MSPs already seizing the huge opportunity. There you have the previously mentioned MaaS Global’s Whim (just launched in Helsinki, and adding two more Finnish cities soon, while exploring other markets); UbiGo (a successful MaaS pilot run in Gothenburg, now planning for expansion to rest of Sweden and other countries); Daimler’s Moovel (available, in beta mode, in Helsinki, Kiev, Lviv, Boston and Portland); Deutsche Bahn’s Qixxit in Germany; Xerox’s GoLA in Los Angeles and GoDenver in Denver; GVH’s Hannovermobil in Hannover; the Smile pilot in Vienna; … just to name a few remarkable examples. The good momentum has promoted the establishment of the MaaS Alliance, a public-private partnership engaging transport operators, MSPs and users. Can we expect Google to join the MaaS Alliance? I have heard a similar question been raised in quite some other fora, where my counterparts would speculate on Google’s approach to the topic under discussion, and sometimes complain about the lack of inputs from the tech giant. My personal view is that Google prefer not to be involved in such industry-driven groups (with some notable exceptions to the rule, such as the Open Automotive Alliance, formed by automakers, tier1s and technology firms bringing the Android platform to cars). Google has its own roadmap and approaches to everything, and has large ambitions to upend transportation. I bet there are already smart minds at Google exploring opportunities around MaaS, but I rather see Google more as kind of an “enabler” of MaaS than a potential MaaS operator, which is good news, I think. Google will keep spreading its tentacles to all the fields of transportation, acting as a market catalyst for new urban mobility. Good evidence for this are the recent update to Google Maps including a ride services tab showing fare estimates and ETA from ride-sharing partners such as Uber, Lyft, Gett, and more; or a less “friendly” take on Uber’s turf with a ride-sharing service to help San Francisco commuters join carpools through Waze (an equivalent service is available in most parts of Israel since last year). Google and Uber were once allies (Google Ventures put $258M into Uber in 2013, in its largest deal ever) but more recently have become rivals in some areas, like driverless cars. Google has led the way with such technology, while Uber has recently started testing robotic taxis in Pittsburgh, beating Google to a commercial test of self-driving technology. It’s indeed interesting to watch how Google “bites”, what an aggressive player it is.

Last but not least… automakers. Automakers (and, to some extent, other companies such as automobile clubs, that have been traditionally focused on making business out of services to privately-owned cars) are rebranding themselves as MSPs to face the threat coming from nimble tech firms like Google (who else?), Uber, and Apple, though it seems the latter has downsized its Titan project to build an all-electric driverless car, while still making it into cars through CarPlay. Other big players, such as Tesla, have started to prove you can build a car company (may we rather say, a “tech company”) from scratch with enough investment, and have recently announced that its autonomous driving hardware is in all vehicle off the assembly line right now… The ultimate level of this profound transformation might well be seizing the MaaS opportunity.

The post Host blog: Google, MaaS, etc. appeared first on MAAS-Alliance.