This position paper discusses the customer-oriented combination of mobility services offered by multimodal mobility platforms. We present a process-oriented approach on the selection and provision of complex mobility services and give an overview of state-of-theart mobility platforms in German-speaking areas. We exemplify the limitations of current mobility platforms with regard to customerorientation and claim that these platforms do not consider travelers' preferences to a sufficient extent. Based on these results, we motivate the need for customer-induced orchestration platforms that support customers in combining mobility services with services of other domains. Contrary to operator-induced combination of services, customer-induced orchestration would allow customers the autonomous selection of component services and support their orchestration to bundles of mobility and complementary services. Service selection; service platforms; reference models; customer context; customer-induced orchestration.
Digitization and interconnectedness play an important role in the
domain of mobility and transportation services. In recent years,
traditional mobility services such as public transportation have
been amended by innovative mobility services such as car and ride
sharing. These innovative shared mobility services are
characterized by their flexible spatio-temporal availability [
Multimodal mobility platforms promise to integrate traditional,
timetable-bound public transportation with innovative mobility
services such as shared mobility services. In recent years, the
number of multimodal mobility smartphone apps and online
platforms has increased significantly. However, available platforms
differ heavily in functionality and customer orientation. In this
position paper, we discuss current functionality and limitations of
mobility platforms based on an overview of existing platforms for
German-speaking areas (see Sect. 2). We use the discovered
limitations to motivate the need for a new paradigm, namely
customer-induced orchestration of complex mobility and
complementary services. The corresponding framework is
discussed in Sect. 3 and extended to customer-induced
orchestration of services beyond mobility services. The position
paper is concluded in Sect. 4.
2. MULTIMODAL MOBILITY PLATFORMS
Multimodal mobility platforms promise to support the selection and
bundling of mobility services to complex services bundles. To
investigate the level of customer orientation that is already
provided by current multimodal mobility platforms, we have
analyzed their functionality and customer orientation with regard to
the support of the mobility service process. Fig. 1 shows the
mobility service process, which was derived by [
Consulting
Search for Information Traveler
Payment
Booking Realization
The search for information phase comprises all activities that help
the traveler in discovering ge.neral information of available
M
o
b
i
ilt
y
S
e
r
v
i
c
e
P
r
o
c
e
s
s
mobility services. The consulting phase discusses potential
alternatives that could meet the traveler’s needs, i.e., that consider
the traveler’s preferences. In the third phase, the traveler selects and
books a particular mobility service, which is then realized by a
mobility service provider. Finally, the traveler pays the stipulated
fee for the utilized service. From a mobility research perspective,
these phases can be understood as supporting the “pre-trip”, the
“on-trip” and the “post-trip” part of a journey with appropriate
information.
Based on the above mobility service process and dimensions
defined by the well-known architecture of integrated information
systems (ARIS) [
The number of considered component services per platform is shown in Fig. 2. The considere.d services are conducted by train, planes, taxis, rides, long-distance buses, private cars, local public 3 3 4 5 6 7 7 9 12 14 transit, bike sharing, car sharing (free-floating/station based), walking, rental cars, private bike and ferry. The absolute number of considered component services varies significantly; platforms with a focus on local transport usually offer a larger number of component services than long-distance platforms. Qixxit provides the widest selection of component mobility services so far. To investigate the functionality of the platforms, we developed the following three test instances reflecting a request for local travel, regional travel and long-distance travel:
Local: Berlin/Breitscheidplatz to Berlin/Pariser Platz Long-Distance: Berlin/Main Station to Cologne/Main Station Regional: Karlsruhe/Main Station to Freiburg/Main
Station.
To determine the appropriate complex mobility services that fulfill the above requests, each platform needs to combine component services according to travelers’ preferences based on data such as expected time, location and price of a service. This is especially challenging for the long-distance request, where component services from different areas and of different modes need to be selected. Typically, at least one long-distance trip (e.g., per train or plane) and two local or regional trips (first/last mile to/from the long-distance trip) are to be combined. As a result, only six out of nine platforms are able to combine component services that operate on different modes (intermodal solutions), while the others are not able to augment long-distance with last-mile services. Travelers using these platforms end up in manually assembling their complex services by combining their preferred last-mile service with the help of other platforms or smartphone apps.
Run Time
Ø Run Time 13.6
We have also measured the run time that the platforms needed to process the above requests. T. he results are shown in Fig. 3. Generally, there is a surprisingly large span between the fastest search at Rome2rio and the slowest search conducted by Waymate. One of the reasons is that some providers already start computing a possible combination of component services for the most likely origin and destination while travelers are still typing in the corresponding values into the app or on the website. Furthermore, some platforms obviously precompute service combinations for popular origin-destination pairs. Note that there is also a typerelated difference in the run time: on average, the construction of a complex service for the local travel request required 10 seconds, and the long-distance travel request required 17 seconds. For the latter, we observed that a flight search engine was included in the search process, which seems to add significant complexity and run time. respect to service providers and aims at the control of complex services during execution.
To investigate the level of customer-orientation that is provided by today’s multimodal mobility platforms, we have analyzed to which extent the mobility service process is supported by each of the platforms. We can state that all platforms offer sufficient support for the search for information and consulting phases. A choice of complex mobility services is generated from simple spatiotemporal information (when/where), and also types of component services can be selected (e.g. car/no car). It has also become quite common to provide information on the total cost of a service and of service combinations. However, there are limitations regarding the booking and payment phases, which are only supported by three platforms (Moovel, Mobility Map and FromAtoB). Booking and payment are also limited to selected component services only. The realization phase is only supported by Qixxit and Allryder. GoEuro, Rome2rio and RouteRANK also conciliate further, complementary component services such as hotel bookings.
The key to traveler-oriented selection of component services is the processing of detailed service and customer data. However, only five out of the nine investigated mobility service platforms ascertain static customer data (such as personal information) at all, and only four of them store them in a customer profile. This goes along with the insufficient support of the booking phase, where customer data is mandatory to finalize a booking. Dynamic customer data (such as the current location of a customer) is ascertained by five of nine platforms, and they are mainly used to improve the selection of currently available component services in accordance with the given spatio-temporal characteristics of the traveler.
In sum, only a small choice of service mobility platforms can actually handle a large variety of local as well as long-distance component services and can automatically assemble an appropriate combination of services according to travelers’ preferences. In general, the considered traveler and service characteristics remain very simple, and the traveler has only limited control of the selection process. Having selected appropriate component services on a dedicated platform, the traveler usually cannot book the desired complex service, and it is not possible to modify it with hindsight. 3. CUSTOMER-INDUCED ORCHESTRATION In the following, we embed the traveler-induced combination of mobility services to the customer-induced orchestration of services from several domains. Extending the idea beyond mobility services, customers in general expect improved support of services with respect to the control of selection and bundling today. In Fig. 4, a selection of relevant domains and corresponding services is shown. For a variety of domains, intuitive apps for smartphones have simplified control of individual services to a great extent. However, apparent weaknesses can still be identified in the combination of component services and in the construction of complex service bundles. This observation does not only hold for mobility services, but also for services in education, finance, and health domains.
As demonstrated for mobility services above, existing platforms lack an intelligent and integrated support of customer preferences, because the control of services is mainly induced by the service provider. Hence, we aim at a customer-induced control of services by means of tailored IT platforms. Beyond service selection and bundling, a user centric conduct of services strives for a choice with Abstracting from the mobility service process as shown in Fig. 1, traditionally, a service can be d.efined as a process of interaction between customer and service provider (Fig. 5). This process is induced by the service provider starting with a setup of applicable resources. In the next step, the customer attains information about the service from the service provider before the customer and service provider make an agreement and the service is realized (booking). The latter phase typically requires the direct interaction of customer and service provider. The process terminates with the billing of the service provider and the payment of the customer.
If several component services need to be combined in order to fulfill the customers’ needs, th.is results in a significant effort of coordination. Typically, a bundling of individual component services into a complex service is required. For each component service involved, the entire service process has to be executed repeatedly. Agents typically take over the control of selecting and combining the component services, hiding the complexity of the complex service from the customer. Today, in the digital economy, the provider of some core (focal) component service often conducts the selection of the remaining services to provide a complex service (e.g. German Railways as focal service on a long-distance trip in the Qixxit platform). As a drawback, the customer gives up control of the details finding him/her confronted with a one-size-fits-all complex service.
This phenomenon can also be observed in the orchestration of so called smart services, where control of the component services is achieved by automated service platforms. The black box paradigm of such platforms hinders transparency of service selection and may exacerbate the availability of competing services and/or new innovative component services, though. Furthermore, whenever component services from different service domains have to be combined in order to satisfy some specific customer demand, neither agents nor smart services are available to cope with the complexity of a complex service. Just think of interrupting a business trip in order to see a dentist due to a serious injury. No longer will smart services be available to coordinate the cancellation of a hotel, the re-booking of flights, the correspondence with health insurance and the appointment at a dentist’s clinic. Moreover, the cancellation of leisure or sports activities may be involved. The customer himself/herself has to coordinate all combination activities.
The above example incorporates different domains and can be generalized by accepting that customers tend to act in different domains simultaneously. Under this assumption, today’s smart services counteract the customer’s need to manually control complex services at a detailed component level. Future customerinduced control of service selection and service bundles may alleviate the above sketched weaknesses [2].
To enable customer-induced orchestration, we propose to
investigate the following topics using the example of relevant
domains such as mobility, finance, education and health and
combine the insights in a generic, domain-independent reference
model. The core questions for modeling and execution of
customerinduced orchestration are:
Modeling of the customer context. Customer-induced
orchestration requires information about the situation of the
customer, about the customer’s preferences and about available
component services. The customer context [
Representation of services. There is a semantic gap between the customer’s domain language and service operator’s domain language, which is a serious obstacle for automated, customerinduced service orchestration. Methods and models are required that present and represent complex and component services appropriately. Hence, we propose to investigate how complex service bundles can be modelled adequately in a domain comprehensive way, and how complex services can be presented to customers.
Methods of automated selection. To enable customer-induced orchestration, component services need to be selected and configured such that they are a good fit with the customer’s preferences and such that they fit well together to define a reasonable complex service. Depending on the domain, there are different requirements at methods of automated selection. Hence, we propose to investigate how complex services can be matched with customer profiles and customer contexts, and whether it is possible to incorporate data of former service execution for this task.
Construction of a reference model. Customer context, representation and automated selection need to be condensed by means of a generic reference model which allows the domainspecific as well as domain-independent derivation and implementation of service platforms. However, it is an open issue to which extent domain-specific approaches can be generalized and whether they can be generalized at all. Hence, we propose to investigate whether a reference model does alleviate the above listed issues, and how the degree of user centric control be measured.
Travelers expect better support in the orchestration of complex mobility services. Mobility platforms promise to select and combine services according to the given preferences of the traveler. Based on an overview of mobility platforms available in Germanspeaking areas, we have found that the functionality of the existing platforms is rather limited. In particular, these platforms often consider only simple spatio-temporal parameters in the selection of mobility services. Furthermore, the capability of fast intermodal search is often underdeveloped, which leads to long run times and insufficient results of the search.
To ensure customer-oriented combination of mobility services and component services in general, we propose the paradigm of customer-induced orchestration. Our idea is to develop a generic reference model that allows for the conceptualization of mobility service platforms in particular and service platforms in general. A core part of this model is the design of the customer context, a choice of service selection methods such as recommender systems and/or mathematical optimization, and an appropriate representation of services and travelers/customers. We expect that the combination of recommender systems and mathematical optimization will be the methodological core of such a reference model and the derived platforms.