Business model prototyping for intelligent transport systems: a … · Business Model Prototyping...

Business model prototyping for intelligent transport systems: aservice-dominant approachCitation for published version (APA):Traganos, K., Grefen, P. W. P. J., Hollander, den, A., Turetken, O., & Eshuis, H. (2015). Business modelprototyping for intelligent transport systems: a service-dominant approach. (BETA publicatie : working papers;Vol. 469). Technische Universiteit Eindhoven.

Document status and date:Published: 01/01/2015

Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:[email protected] details and we will investigate your claim.

Download date: 10. Nov. 2020

https://research.tue.nl/en/publications/business-model-prototyping-for-intelligent-transport-systems-a-servicedominant-approach(6bf7dae8-2c21-4f35-8c20-6b07ca56ed7b).html

Business Model Prototyping for Intelligent Transport Systems

A Service-Dominant Approach

Konstantinos Traganos, Paul Grefen, Aafke den Hollander

Oktay Türetken, Rik Eshuis

Beta Working Paper series 469

BETA publicatie WP 469 (working paper)

ISBN ISSN NUR

982

Eindhoven March 2015

Business Model Prototyping for

Intelligent Transport Systems

A Service-Dominant Approach

Case Study for

Praktijkproef Amsterdam Fase 2

deelproject Zuidoost

Konstantinos Traganos Eindhoven University of Technology (TU/e)

Paul Grefen Eindhoven University of Technology (TU/e)

Aafke den Hollander Municipality of Amsterdam, Praktijkproef Amsterdam

Oktay Türetken Eindhoven University of Technology (TU/e) Rik Eshuis Eindhoven University of Technology (TU/e)

2

Contents

1 Introduction .................................................................................................................................... 4

1.1 Purpose ................................................................................................................................... 4

1.2 Context .................................................................................................................................... 4

1.3 Objectives................................................................................................................................ 5

1.4 Structure ................................................................................................................................. 5

2 Business Model Design ................................................................................................................... 6

2.1 Introduction ............................................................................................................................ 6

2.2 Service-Dominant Business Model Radar ............................................................................... 7

2.3 Stakeholder Analysis ............................................................................................................... 8

3 Business Model Blueprints ............................................................................................................ 12

3.1 Approach ............................................................................................................................... 12

3.2 Business Model Radars ......................................................................................................... 12

3.2.1 Business Model 1 – Ultimate Event Experience ............................................................ 12

3.2.2 Business Model 2 – Stress-free Event Journey ............................................................. 14

3.2.3 Business Model 3 – Free Ride Amsterdam Event ......................................................... 16

4 Business – System Architecture mapping ..................................................................................... 19

4.1 ITS NL - System Architecture ................................................................................................. 19

4.1.1 Physical View – High Level with building blocks ........................................................... 20

4.2 Mapping for Business Model 2 ............................................................................................. 24

References ............................................................................................................................................ 30

Appendix A: BASE/X Framework ........................................................................................................... 31

A.1 Introduction .......................................................................................................................... 31

A.2 Business Design in BASE/X .................................................................................................... 31

A.3 Tooling in BASE/X business design ........................................................................................ 32

A.3.1 Graphical Annotation of Business Model Radar ........................................................... 34

Appendix B: Participants per workshop ................................................................................................ 36

Appendix C: Business Models – Results of Workshops ........................................................................ 37

C.1 Workshop 1 – Ultimate Event Experience ............................................................................ 37

C.2 Workshop 2 – Stress-free Event Journey .............................................................................. 38

C.3 Workshop 3 – Free Ride Amsterdam Event .......................................................................... 40

Appendix D: Original Sketches of Business Model Radars .................................................................... 42

Appendix E: Description of elements of Physical view ......................................................................... 45

3

Appendix F: Business – System Architecture mapping for BM 1 and BM 3 ......................................... 49

F.1 Mapping for Business Model 1 ............................................................................................. 49

F.2 Mapping for Business Model 3 ............................................................................................. 51

Appendix G: Contributors ..................................................................................................................... 55

4

1 Introduction

In this introduction, we set the scene of this document. First, we state its purpose. Next, we discuss the context of the project and its objectives. We conclude this introduction with an outline of the structure of the rest of this document.

1.1 Purpose

The current document introduces the approach for designing multi-sided, service-dominant business models for Intelligent Transport Systems (ITS). This approach has been applied in three workshops for the Praktijkproef Amsterdam Zuidoost project1. The purpose of these workshops was to arrive at prototype business models for traffic management around large events in the Amsterdam South-East region. In the workshops, most of the relevant stakeholders have participated. This report presents the followed approach and the designed business model blueprints, which are based on the results of these workshops. Also, a mapping of a business model to a system architecture of an ITS is described for further deployment of business solutions.

1.2 Context

The mobility of people and goods suffers from delays, unreliability, lack of safety and air pollution, especially in metropolitan areas. On the other hand, the demand for mobility is growing faster than the available infrastructure. The development and deployment of Intelligent Transport Systems (ITS) reduces traffic and number of accidents, leads to lower vehicle emission levels and improves quality of life. In addition, the benefits of ITS are motivating both developed and developing countries to invest in these technologies instead of spending huge amounts on transportation network expansion.

Various governmental, academic and industrial stakeholders are in the process of describing a shared vision on this new approach and first practical steps toward this goal should be taken. Concurrently with the technology investments, investigations are carried on how various business models can be applied to enable financial feasible roll out of traffic management services.

In the Netherlands, many ITS projects are being developed. Praktijkproef Amsterdam (PPA) is one of them. The Amsterdam Practical Trial (PPA) is a trial aimed at reducing traffic congestion in the Amsterdam region. It is a unique, large-scale pilot involving the innovative use of both in-car and roadside technologies. Road users receive personalized travel advice in the car, to enable them to make the best choice for their journey. Traffic lights and electronic displays respond in a coordinated manner to traffic jam predictions. This enables road users to reach their destination faster and provides them reliable travel times.

The Netherlands is a global trailblazer in collaborating to deliver public services. In PPA, the public, private, science and technology sectors work together in an innovative fashion to create solutions for improved accessibility in regions with high traffic volumes. Demonstrable cost-effectiveness will enable national and international applications, and open up opportunities for Dutch businesses.

PPA is split in two phases. Phase 1 consists of two parts:

1 www.praktijkproefamsterdam.nl

http://www.praktijkproefamsterdam.nl/

5

- Testing of the integration of the proactive, automated traffic management system. The trial is taking place on the western side of the A10 ring road west, junctions S101 (Nieuwe Hemweg) to S107 (Henk Sneevlietweg).

- In Car system offering personalized journey information: traffic lights and feeder lights on entry slip roads and traffic lights are providing a coordinated response to traffic jam predictions. Two consortia will start with In Car services testing: Arcadis/VID under the name “Amsterdam Mobiel” and ARS/TNO under the name “Amsterdam Onderweg”. Road-users, trial participants, will receive current traffic and parking information in their cars and will use this information to choose their best route (In Car services testing).

In Phase 2 the project is split to three subprojects, PPA Noord, PPA West and PPA Zuidoost. They contribute to the integration of the proactive, automated traffic management system and the In Car system offering personalized journey information. PPA Zuidoost focuses on improving individual in-car advises by utilizing data gathered by road-side systems in the south-east part of Amsterdam during large scale events.

1.3 Objectives

Given the current situation of the PPA Zuidoost project, where a number of (prototype) technologies

is being tested, many parties with different roles and responsibilities are involved, and even the

(non-)functional requirements are not clear yet, the question is “how to achieve a clear overview of

all the stakeholders and their collaborations in an operational business model”. Therefore, one of

the objectives of the project is to design blueprints business models with the use of a structured

framework.

Eindhoven University of Technology (TU/e), with the help of industry, has developed such a framework, called BASE/X2, which is partially used for the design of service-dominant business models, as we explain in Business Model Design.

1.4 Structure

In Business Model Design we discuss how business can be designed in a service-dominant world by introducing the BASE/X framework. We focus on a specific component of the framework that provides a conceptual tool for designing business models. In this chapter, we also present a stakeholder analysis in order to provide a structure for the long list of parties taking part in the transport and mobility domain. In Business Model Blueprints, we present a number of business model blueprints as examples of the deployment of ITS applications, based on the results of the three workshops in which first attempts of designing business model prototypes were made. Finally, in we describe how a business model can be mapped to a system architecture of an ITS.

2 BASE/X is the acronym for Business Agility through Service Engineering in a Cross-Organizational Setting.

6

2 Business Model Design

This chapter introduces the service-dominant logic in the transportation domain and presents, in Service-Dominant Business Model Radar, a structured method to design high-level business models. In Stakeholder Analysis, a stakeholder taxonomy of the ITS domain is presented.

2.1 Introduction

The transport and mobility business domain is currently transitioning towards a service-dominant business setting. Before the transition, business settings used to be centered on the delivery of products or stand-alone services. After the transition, they will be centered on the provisioning of solution-oriented, integrated services to customers (either business organizations or individual consumers). Services may require the deployment of products, but these products become part of the delivery channel of services, not the focal point themselves. Ownership of products becomes a less relevant issue. The emphasis shifts from the value of the individual product or service to the value of the use of the product or service in an integrated context – the so-called value-in-use. A representative example of such a value-in-use is the transition from leasing a car (asset) to the provisioning of integrated mobility solutions, including public transportation, flexible work offices, etc. for a hassle-free relocation.

This transition though has consequences for the very basic characteristics of doing business. First, customers expect coherent solutions, not stand-alone solution fragments. Thus, solution-oriented services are of a complex nature that requires the integration of the capabilities of multiple service providers. This introduces the necessity of explicitly managed business networks, in which traditional mobility and transport service providers, equipment providers, authorities, and user organizations collaborate to co-create the value-in-use. Second, customer-driven requirements to solution-oriented services will evolve much faster than requirements to the underlying products. Rapid developments in information and transport technology will further reinforce this process. Thus, managing agility in service delivery will be a key factor in the market position of a service provider. Third, managing service complexity and business agility requires a tight integration between the structure of business strategy and models on the one hand and the structure of business operation and information management on the other hand. It is not only about what transport or mobility service to sell, but also about how to get it delivered.

Performing the transition to service-dominant business and managing its consequences is a formidable task for any non-trivial business organization. Taking a traditional top-down, business-strategy-to-operations approach will be too slow in the current fast pace of market developments. Taking a quick-win, opportunity-driven, bottom-up approach will result in isolated implementations and chaos in integration efforts. A visionary, industry-strength approach is required that is completely tuned to the service-dominant transition and that has the very basics of service business at its core. BASE/X is such an approach.

BASE/X is a business engineering framework for service-dominant business, i.e., business that puts service management at the forefront of its design and operation. It covers the entire spectrum from high-level business strategy definition to business information system architecture design. For the purposes of the current document, we focus only on the business design aspect of the framework and more specific on the design of business models. A small introduction of BASE/X is presented in Appendix A: BASE/X Framework, while more information can be found in the full documentation of the framework in [1].

7

2.2 Service-Dominant Business Model Radar

A business model is a set of assumptions about how an organization will create value for all its stakeholders. The design of a business model is done by using tools like the Business Model Canvas (BMC) [2]. However, approaches like this are typically not focusing on service-dominant business and are organization-centric, not network-centric. Therefore, we use here a tool that has a service-dominant starting point, called Service Dominant Business Model Radar (SDBM/R) (We use in this document an adapted version of the conceptual tool that was initially proposed in [3]).

The Service-Dominant Business Model Radar (SDBMR) uses as a central aspect the notion of Co-created Value-in-Use which defines what is the proposed co-creation proposition in terms of the solution to the customer’s problem or customer’s experience. Three concentric circles are framing this value-in-use. The first one is the Actor Value Proposition, which defines a value proposition to co-create value by a co-creation actor to the solution for the benefit of the same or other actor within the ecosystem. Co-Production Activity is the next element defining any activities that each actor performs in the business for achieving the co-creation of value. In the business model, we have also to define the Benefits/Costs as the financial and non-financial gains/expenses of the co-creation actor participating in the value co-creation. Finally, we have the co-creation actors represented as radial regions covering all con-centric circles. These actors are the Focal Organization, Core and Enriching Partners and of course the Customer. The Focal Organization defines the role of co-creation actor that proposes the business model and participates actively in the solution or experience. A Core Partner defines the role of co-creation actor as a partner that participates actively in core of the solution or experience while an Enriching Partner element defines the role of co-creation actor as a partner that participates actively in enriching the solution or experience.

The elements that are discussed above are shown in the radar of Figure 1.

8

Figure 1 Service Dominant Business Model Radar

2.3 Stakeholder Analysis

The provisioning of mobility solutions involves many role categories with actors who play a direct or indirect role in multi-sided business models. In this section we present the main stakeholders of traffic-related applications in the frames of PPA Zuidoost project, starting from high-level general categories and specifying underneath more specific actors. Examples of actors are given only for illustrative purposes and these actors are of course not the only ones that can play a specific role in a business model.

In a large-scale project like PPA-Zuidoost, the list of stakeholders is rather exhaustive and the first step is to put some structure in that list. Two main dimensions are used to classify stakeholders: Public – Private stakeholders and Service Providers – Service Consumers. However, while the first dimension is rather mutually excluding, the second dimension can contain overlappings, i.e. an actor can play a dual role, either a service provider or a service consumer, depending on a specific business model.

The classification list is as follows:

GOVERNMENT BODY/POLICY MAKER & REGULATION: Represents the stakeholders that are defining the policies and are monitoring the compliance with the regulation and legislation related to the services. These parties are mainly service providers but in some cases can be considered as service consumers. - Country/Ministry (RWS)/Province/Municipality/Sub-city: the hierarchy of public administration for defining policies, providing grants and funding ITS services. - Traffic Manager/Road Operator: supervises the traffic management of an area (i.e. a city or a highway) and is responsible for its optimization.

9

- Police/Enforcement: monitoring authority and certification of violations of the “Code of the Road” and related law collections. It includes P.S.A.P. (Public Safety Answering Point), that is the collection center for emergency calls and rescue. - Certification body: entity that certificates the adherence and compliance of products and services with standards and technical guidelines. - Public Transport: Train/Metro/Bus/Tram Operators like NS/GVB/Connexxion/EBS. - Auxiliary body: For instance Ambulances or Fire brands that in some cases require priority on a road.

TRAFFIC SERVICE PROVIDER: Represents the stakeholders that are contractually providing the service(s) directly or indirectly from the producers to the consumer(s). A Traffic Service Provider is the main interlocutor with the users. Usually a software/technological company or a navigation provider acts as a service provider. However, it could also be a different stakeholder, for example a private company owned by a consortium of cities of a region.

USER/CONSUMER: Represents the stakeholders who are perceived as users of the service (public, commercial or private) and who are willing to pay the service provider for the service(s). - Individual road user: the real final individual user of the road network, either a driver or a vulnerable road user like a pedestrian or a cyclist, or a service. A distinguish between event visitors and non-event visitors to include users who may face traffic problems but are not travelling to an event (An extra distinction can be made for ITS-road users and non-ITS road users in order to take into account in some business scenarios any user who is not equipped with ITS-enabled devices). - Transport Company: we distinguish between fleet managers, actors who manage a number of vehicles, such as busses, emergency vehicles, trucks or taxi and truck drivers (including also bus drivers, taxi drivers etc.). TECHNOLOGY SUPPLIER: Represents the stakeholders that are supporting the producers of the functionality of the service(s) or the service provider with the necessary technology and devices. It can be any actor providing devices, hardware platforms, software applications, consulting services to all the other actors involved in the services like: - Road Side Unit (RSU) provider: provides complete RSUs and in some cases has the task to install and maintain the RSUs in the road infrastructure. - Road Sensor provider: provides any type of sensor (e.g. camera, speed sensor, location module, actuators) to be connected or integrated in a RSU in order to capture real data and information. - On-Board Unit (OBU) provider: provides the OBUs to the car/truck maker or to retrofit installer in aftermarket scenarios. - Vehicle maker: represents the role of a maker of every kind of vehicle (cars, trucks, buses, ambulances, fire-fighters vehicles, etc.). - IT provider: provides hardware (HW) and (SW) support for Back-Office operations.

SERVICE ENABLER: Represents the stakeholders that are supporting the service provider with necessary services and contents. - Content provider: finds and creates content (traffic data, information, basic services) to build useful services to end users (e.g. POI on maps). - Connectivity provider: provides the SIM card/module to be inserted into the OBU and RSU, connectivity services to users and other actors, other value-added services like Location or identity management. - Broker: a facilitator between a seller of a service and a consumer by providing an integrated platform for mobility services.

EVENT LOCATION PROVIDER: Represents the stakeholders who own or hire facilities for event hosting.

10

- Stadium provider: responsible (either owner or lessee) of a stadium that can hold an event (such as a concert, sport event, etc.). - Hall provider: responsible (either owner or lessee) of a (music) hall which can hold a music concert or an exhibition. - Cinema/Theatre provider: responsible (either owner or lessee) of a cinema/theatre.

EVENT ORGANIZER: Represents those stakeholders who organize events and eventually gather people in a specific area or location. - Sports events organizer - Music events organizer - Exhibitions organizer

RETAILER: Represents the stakeholders who provide facilities for accommodation or any leisure activities, attracting people in specific areas. - Hotel

- Restaurant/Café

- Shopping Mall/Shop: any owner of a shop, either individual or part of a large shopping mall in an area.

PARKING OPERATOR: Represents the stakeholders that own, manage and provide parking facilities and services. It can be either public actors, private business actors or both.

ADVERTISER: Represents the stakeholder(s) that are advertising their services/products through the provisioning of ITS applications and may finance any of these applications in specific business models. Note that a specific actor can play multiple roles in the same or different business models. For example, a company as a specific actor can act as a navigation provider and the traffic content provider in the same or in different business models.

Placing these roles and actors in a two-dimensions matrix, we have the following Figure 2. The vertical layers distinguish stakeholders between Service Providers and Service Consumers, while the horizontal layers separate them between Public and Private ones. The main categories are represented as rounded rectangles, covering one or two layers (i.e. service provider-service consumer or public-private). More specific actor types are included in each of these rectangles and in turn a few examples of parties that can play these roles are shown for illustrative reasons.

11

Stakeholder

Pri

vate

Pu

blic

Service Provider Service Consumer

Government body

Country

RWS

Province

Municipality

Subcity

Traffic Manager/Road Operator

Police

Netherlands

Noord-Holland

Amsterdam / Ouderamstel

Amsterdam South-East

Event Location Provider

Stadium Amsterdam Arena

Hall Heineken Music Hall / Ziggo Dome

Event Organizer

Concert Mojo / Rocket

Match KNVB

Retailer

Hotel

Restaurant/Cafe

Mall/Shop

Parking Operator

Individual Road User

Event Visitor

Non-event visitor

Transport Company

Fleet Manager

Truck Driver

Service Enabler

ContentProvider

Connectivity Provider

Traffic Service Provider

Private Consortium

Navigation Provider

Technology Provider

Road Sensor Provider

OBU Provider

Vehicle Maker

HD Traffic / Flitsmeister / Google /Social Media

GSM / SIM Card

RSU Provider Vialis / Siemens

TomTom

Traffic Info ProviderNDW

AWNB

Software Company

Auxiliary body Ambulance / Fire brand

Public Transport NS / GVB / Connexxion / EBS

Certification Body

Cinema/Theater

Public Area

Q-ParkPrivate garage

Advertiser

IT Provider

Exhibition

Broker

Figure 2 Stakeholders Taxonomy

12

3 Business Model Blueprints

With the aim to design a set of business model radars as perceived by the domain experts, three 2-hours sessions were held at Municipality of Amsterdam, on 29th and 30th of October 2014. The lists of participants per workshop are presented in Appendix B: Participants per workshop. In this chapter, we discuss in Approach the approach followed during the workshops and present in Business Model Radars the business model blueprints which are based on the results produced during the workshops.

3.1 Approach

With the help of experts from TU/e, the mobility domain experts were guided in the design of blueprint business models based on business scenarios related to PPA Zuidoost project.

- The first step was to define the co-created value-in-use of a customer’s problem/solution. - Upon agreement, the identification of the two main actors was the next step, namely the

focal organization that orchestrates the activities and the customer who is the main consumer of the service-solution.

- Next step in the process was to include all main partners, core and/or enriching, that contribute to the proposed value-in-use. For each of these actors, the “actor value proposition” ring of the radar had to be filled.

- The ring of “co-production activity” was skipped during the workshop mainly due to time constraints.

- Final step was to identify the costs and benefits per actor (monetary on non-monetary). The “+” symbol was used to indicate a benefit, while a “-” indicates a cost. How a benefit of an actor incurs cost for another actor is represented by the use of the same color (more explanations about the graphical annotation of the radar can be found in A.3.1 Graphical Annotation of Business Model Radar).

3.2 Business Model Radars

Based on the results of the workshops (which can be seen in Appendix C: Business Models – Results of Workshops), we processed the ideas of the participants in order to complete the business model radars. The results are presented in this section.

3.2.1 Business Model 1 – Ultimate Event Experience

The identified value-in-use of this business model is the Ultimate Event Experience for visitors of an

event in the area of Amsterdam Zuidoost. An Event Organizer can play the role of a focal

organization with the experience they have in the event content. They undertake the role to

orchestrate all related activities among all actors of the business models and of course to arrange

any content contract. The customer is the Mass Event Visitor who is part of a crowd coming to the

area. An Event Location Provider is a core partner since most of the events are held in specific

premises/facilities. Their coproduction activities are both providing the location and sub-

orchestrating activities among actors, aiding in that way the Event Organizer. A Transport Facilities

Provider will enrich the value-in-use by providing easy access to the event. This role includes all

types of transportation, like train, bus, tram and even a parking operator. Note here that an event

13

visitor can choose one type of such a provider, i.e. either parking operator for those coming by car or

public/private transport for the rest. A Transport Info Provider will add access transparency by

providing real time transportation information. This information can be generated by reliable, real

time raw data that are gathered by a Transport Data Provider, e.g. a Road Operator.

The main benefit for the customer will be a concentrated joy and good memories from the

experience of visiting the event he/she desired to, while on the other hand he/she has to sacrifice

his/her time. In monetary terms, this will incur an integrated passport ticket, including both the

event ticket price and any transportation/parking tickets (we assume that the Event Organizer will

charge for any transportation/parking service so the event visitor does not have to care for any extra

tickets).

The integrated passport ticket is paid to the Event Organizer, while in turn they have to pay any

content fees (e.g. artists/music bands) and fees for renting the location of the event. We assume

also that the transportation/parking services are sub-orchestrated by the Event Location Provider, so

the Event Organizer has to pay access fees to them.

The Event Location Provider will receive the location renting and access fees, but they have to pay

the Transportation Facilities Provider for the access fees. These include any public/private transport

ticket or parking ticket for car visitors. Of course, the event will incur additional operational costs.

The Transport Facilities Provider (public/private transport company or parking operator) will receive

the access fees from the Event Location Provider. As another benefit from the upfront information

on how visitors will travel to the event, is the insight in traffic flow in a specific area, in a specific

time range. Their main costs, apart from the operational costs, are the fees they have to pay to the

Transport Data Provider for real time traffic data. We can also make the assumption that they pay a

fixed subsidy to the Transport Information Provider who for example provides a website/mobile

application for transport information without any advertisement support.

The Transport Information Provider will receive the fixed subsidy we mentioned above (presuming

that this is the main source they earn money from). To provide their services however, they have to

pay for real time traffic data from the Transport Data Provider and of course they incur any IT

infrastructure costs.

The Transport Data Provider will receive the fees for the real time traffic data they provide to other

stakeholders as mentioned above. Their main costs are infrastructure costs which will probably be

increased due to the happening of events.

The business model radar is presented in Figure 3.

14

Figure 3 Business Model 1 - Ultimate Event Experience

3.2.2 Business Model 2 – Stress-free Event Journey

Event visitors want to have a good time and positive experience without having to care much about transportation and any event related issues. A business model with a Stress-free Event Journey value-in-use will contribute to that direction. We focus, however, in this business model on visitors by car, making an explicit separation from a business model for visitors by public transport means.

The Event Organizer undertakes the role to orchestrate the other parties like the Private Traffic Manager who provides easy access to the event, the Event Location Provider, who provides comfort, the Municipality, who contributes to a metropolitan atmosphere and provides accessibility, the Parking Provider, who provides parking services so the visitor does not have to care about his car while enjoying his favorite music band, the Road Authority who provides reliable and safe traveling to the event. Retailers are also part of the business model since they contribute to customer’s experience with pre- and post-event convenience (shopping, eating, etc.). Apart from people who are visiting an event, we care also about those who are using the same road network and visit the area around Amsterdam Zuidoost during the event, adding liveliness to the area, the Non-Event Visitors.

15

The main coproduction activities of the Event Organizer, except the orchestration, are the arrangements of any content contract and the provision of upfront information to other stakeholders since they have the data for the exact number of visitors.

A Private Traffic Manager undertake the role to gather traffic data, both from Road Authorities and floating car data, and provide an traffic management and enhanced traffic information to road users on how to reach the event venue.

The Event Location Provider provides the venue facilities while the Municipality of Amsterdam has to perform marketing activities to promote the area and provide traffic management during an event. The Parking Provider has the task of providing parking services while the Road Authority provides the road infrastructure, traffic data and manages the traffic with their expertise. The role of the Retailer is rather obvious, to sell their products to people visiting their store.

The Event Visitor will take advantage of the provided solutions when visiting an event and experience the metropolitan atmosphere. On the other hand, he will pay the ticket for the event, the parking costs, service fees for the traffic information he gets and any other money in the shops/bars he will visit.

The Event Organizer will receive the ticket fees and also will increase their reputation by providing a stress-free experience. To do so, they have to pay rent to the Event Location Provider and of course pay for the organization of the event (the artists, etc.).

The Private Traffic Manager has to pay Road Authorities in order to get traffic data. On the other hand, they charge road users for the enhanced traffic information they provide (service can be charged on a per-contract basis or on a fixed yearly fee). We make here the assumption that in-vehicle traffic information is provided to the customers of Event Organizer who are the Event Visitors. In this case, Non-Event visitors are being charged for any service.

To be part of this business model and reap the benefits, like increased reputation and venue fees, the Event Location Provider has to increase its operational costs for providing more and of better quality services.

The Municipality of Amsterdam will increase its reputation as being a city with high accessibility and nice atmosphere in busy events areas. The reputation will consequently attract more visitors, help to reduce any economic damage and the deployed intelligent transport systems will further decrease operational costs. However, they traffic management they have to perform will incur some costs.

The benefits for the Parking Operator are the parking fees that they get from car visitors. Their monetary costs are any extended operational costs.

The Road Authority will also benefit of that business model since such a solution will help them meet their targets on traffic management. Moreover, they get fees from the traffic data they sell to the Private Traffic Manager. Traffic management costs are still there but intelligent transport systems will eventually lead to reduced operational costs.

Regarding the Retailers, the turnover is an issue that needs further financial analysis whether it will be positive or negative. This is because the spending of the event visitors may be equilibrated by the fact that less people who are not visiting the event will go for shopping, drink or dinner during the event in order to avoid the crowd. The same goes for the reputation of these stores. On the other hand, Retailers have to spend more on extended operational costs in case it requires to stay open for extra hours due to an event.

16

Finally, for Non-Event Visitors, the advanced traffic solutions will help them in the accessibility to the area and the experience of the metropolitan atmosphere. However they will have to endure the nuisance that the event visitors cause. And of course, non-event spendings should be counted as their main monetary costs.

One main remark we can make about this business model is that it is close to the current situation with the respect to the roles that the identified stakeholders play. Moreover, we can say that actors are loosely connected and are not tied so much to the focal organization, as was the case in the first business model of the Ultimate Event Experience, in which the idea of an integrated passport ticket required a more explicit and better orchestration of actors.


Figure 4 Business Model 2 – Stress-free event journey for Car visitors

3.2.3 Business Model 3 – Free Ride Amsterdam Event

The idea for this business model is rather extreme since it proposes a “free ride” to an event to

those who plan their arrival by car at a much earlier time than the beginning of the event. The term

free refers to free parking (or even fuel consumption coupons, however in that case we should

consider gas station owners as co-creation actors). With that scenario traffic jams will be reduced

17

and many stakeholders need to contribute. A Mobility Broker is the focal organization offering

integration and being the central point of contact. They are responsible to orchestrate not only

traffic-related actors, but also the visitors who wish to book a ticket for an event. A Parking Provider

will simply provide parking services for an easy car disposal while the Road Authority provides the

road infrastructure and traffic management before and after the event for a reliable trip. Retailers

are also involved in the business models, contributing to pre and post experience by selling products

to people coming to the area. The Event Organizer will provide the content while the Event Location

provide will contribute to a comfortable stay before, during and even after the event.

The main benefit for the visitor is of course the “free ride” (free parking) and the concert experience

as well. Their non-monetary costs are their flexibility and the sacrifices in their time schedule since

they need to be there at given times to exploit the “free ride”. The event incurs a ticket fee and any

non-event spendings that visitors make especially due to the fact that they arrive much earlier.

The Mobility Broker will get variable kickback fees from the Event Organizer, the Event Location

Provider and the Retailers since these stakeholders will advertise themselves in the broker. Another

monetary benefit is the ticket fees since we made the assumption that they orchestrate the booking

of the ticket for the visitors. On the other hand, the broker will pay the “free ride” as parking fees to

the Parking Operator for providing parking services to its customers. They will also have to expose

the data for number of visitors to Retailers to let them estimate any changes on their turnover.

Parking Providers are expecting an increase in the demand due to the fact that more people will

desire to exploit the “free ride”. However, this demand may lead to capacity constraints and to

extended operational costs.

For the Road Authority, the main benefit is that the expected reduced traffic congestions will help

them meet their traffic management targets (monetary and non-monetary). On the downside, they

have to get and manipulate the traffic data and still have to perform the necessary traffic

management.

Retailers will benefit from the “free-ride” business model in terms of increased popularity, higher

turnover since people will spend more hours before the event and have the advantage of estimating

people’s attendance from data got from the Mobility Broker. However, they need to pay kickback

fees to the broker and extend their operational costs.

The Event Organizer and the Event Location provider will also benefit from the proposed solution

and will expect an increase in popularity and subsequently in their turnover. They also have to pay

kickback fees to the Mobility Broker to advertise their services and facilities. Moreover, for the Event

Location Provider, extended operational costs should be taken into account.


18

Figure 5 Business Model 3 – Free ride Amsterdam event

19

4 Business – System Architecture mapping

In this chapter we discuss the mapping between a business model and the system architecture of an ITS with the goal to show how a business solution can be deployed by the use of technology. The system architecture we use for the mapping is the Reference Architecture for Cooperative-ITS applications in the Netherlands as designed per December 2014 by the DITCM 3and agreed by various stakeholders [4]. For each of the three complete business models blueprints of Business Model Radars, we link the involved actors to specific elements of the system architecture, showing who is owner/responsible of/for which element of an ITS. Activities as identified in the business model radars are also mapped to architecture elements to make a more explicit connection between business and technology.

First, we briefly present in ITS NL - System Architecture the ITS System Architecture that is used for the mapping. Then, in Mapping for Business Model 2, we present the models for the business – system architecture mapping for one of the complete business models (the most representative), leaving the mapping of the other two business models to be found in Appendix F: Business – System Architecture mapping for BM 1 and BM 3. These mappings are rather blueprints to act as a guideline for further implementations.

4.1 ITS NL - System Architecture

The objective of “Reference Architecture for Cooperative-ITS applications in the Netherlands” project is to develop an ITS reference architecture consisting of a system architecture and business aspects of an eco-system with stakeholders from public and private parties - in a Dutch context, i.e. with knowledge of the existing role of the Dutch road operators and the roadside and traffic management systems with e.g. loop detection, variable message signs, traffic light controllers (both urban and highway access) and Traffic Management System (TMS) with their interface specifications. The reference architecture should give guidance to future ITS deployment projects in the Netherlands. To define that first release of the reference architecture, a number of projects were selected as source for the ITS reference architecture for the Netherlands.

Regarding the system architecture, different views have been used to describe the elements of the reference architecture. These are:

- Physical view: describes the sub-systems and the communication interfaces between these sub-systems

- Functional view: describes the application objects (or functional components) that are attached to the physical objects as well as abstract functions (processes) within application objects and their logical interactions (data flows) between functions

- Communications view: describes the interfaces between the physical and functional building blocks via a layered set of communications protocols that are required to support communications among the sub-systems.

In the current project, we are focusing on the Physical View and more specific in high level models of it since our goal is to provide a first kind of business – system architecture mapping.

3 Dutch Integrated Test site for Cooperative Mobility, http://www.ditcm.eu/

http://www.ditcm.eu/

20

4.1.1 Physical View – High Level with building blocks

In the physical view the system architecture is depicted as a set of sub-systems that interact and exchange information to support the ITS applications. Sub-systems are defined to represent the major (physical) components of the connected vehicle environment. (Human) actors are treated as external entities that interact with the system. The main categories are:

- Vehicle Driver: An actor driving in a vehicle. The vehicle is a motorized vehicle (car, bus, truck) and not a vehicle of a vulnerable road user (bike, moped, motor).

- Vulnerable Road User (VRU): A VRU is a human actor like a pedestrian, cyclist or powered-two-wheel driver (PTW); A motorcyclist is also an example of a PTW and is treated as a vulnerable road user in specific road hazard situations with other cars.

- End User: A human actor who uses a product or service as an individual, i.e. not on behalf of an organization.

- Road Operator: An actor responsible for the traffic management of a road network. - Service Provider: An actor (organization) supplying services to one or more customers.

Customers are either other organizations, including government (B2B / B2G / G2B / G2G) or end users (B2C / G2C). Typical examples of service providers are a Navigation Provider or a Traffic Information Provider.

- Other: Any other actor that has interaction with the ITS or is interested in the deployed applications.

These actors can be represented by the list of stakeholders presented in Stakeholder Analysis, a subset of which is used in the business models blueprints. An ITS as a black box with interacting actors is presented in Figure 6.

ITS system

Vehicle driver

ServiceProvider

OtherRoadOperator

VRUEnd User

Figure 6 System architecture – Higher level

The physical view of system architecture is based on best common practice of previous ITS projects, i.e. there is a split in physical layers for vehicle, roadside and central; in addition a support and a traveller/vulnerable road user layer are added. The five “layers” are shown in Figure 7.

21

Central

Traveller / VRU

Vehicle

Roadside

Support

Figure 7 ITS Reference Architecture Physical View: Layers

1. Support layer: Sub-systems to support the overall system e.g. governance, test and certification

management and security and credentials management. 2. Central (or back-office) layer: Sub-systems to support connected vehicles, field and mobile

devices and to perform management and administration functions. The sub-systems in this layer are typically virtual systems that can be aggregated together or geographically/functionally distributed.

3. Roadside layer: Covers the ITS infrastructure on or along the physical road infrastructure, e.g. surveillance or control devices (signal/lane control, ramp meters, or systems to supply information to connected vehicles.

4. Vehicle layer: Covers the intelligent/cooperative on-board systems (advanced driver assistance / safety systems, navigation, remote data collection or information). Also specific sub-systems for fleet–type vehicles are included e.g. for signal priority, monitoring activities, fleet management or passenger services.

5. Traveller or vulnerable road user (VRU) layer: Covers both “personal” devices (e.g. mobile devices, navigation devices) and specific systems connected to vehicles of VRU’s or VRU’s itself (e.g. tags).

The identified “building blocks” (physical objects or sub-systems) in the five layers are shown in Figure 8.

22

Central

Traveller /VRU

Vehicle

Roadside

Support

Roadside System (RS)

Vehicle Platfom(VEE)

Personal Information Device

Vehicle On-Board Unit (OBU)

Vehicle VRU Localization System

(V-VLS)

Roadside Unit (RSU or RIS)

Service Provider Back-Office

(SP BO)

Data Provider Back-Office (DP BO)

Traffic Management System (TMS)

Traffic Information System (TIS)

VRU-OBU

Service Provider Exchange System

(SPES)

Remote Vehicle OBU (R-OBU)

GovernanceTest & certification

ManagementSecurity & credentials

Management

VRU Transponder (VRU-T)

Roadside VRU Localization System

(R-VLS)

Communication Provider Back-Office

(CP BO)

Operational Management

Remote VRU-OBU

Figure 8 ITS Reference Architecture Physical View: With Sub-systems

More information about the description of each of the building blocks can be found in Appendix E: Description of elements of Physical view.

Adding now the connections and among the sub-elements for the support of identified ITS

applications, we get Figure 9.

23

Vehicle

Central

Traveler

RoadsideRoadside System

(RS)



OBU

Service / Data Provider BO (SP / DP BO)

Comm. Provider Back-Office (CP BO

or CIS)


VRU-OBU


(SPES)


RSU or RIS


Remote VRU-OBUVRU-Transponder

(VRU-T)


(V-VLS)


(R-VRS)


(SP BO)

Support GovernanceTest &

certification Management

Security & credentials

Management


Figure 9 ITS Reference Architecture Physical View: With interfaces among Sub-systems

The architecture models of Figure 8 and Figure 9 are used to map the actors and their main activities, as identified per business model. Actors are linked to the main elements which perform their activities. Figure 10 below shows an overview of the mapping. Actors of the radar are mapped to actors of the ITS. Co-production activities are also mapped to descriptions of activities performed by actors of an ITS. The other elements that are not directly mapped to the identified actors are greyed for presentational reasons (they are needed though in a fully functional ITS, but owned/managed by actors that are not part of a specific business model). Note here that in each mapping, other important actors may be missing, owning crucial parts of an ITS. However, the aim of the mapping is to show how the parties that contribute to a specific value in use of a business model interact from a technology point of view.

24

Figure 10 Overview of business - system architecture mapping

4.2 Mapping for Business Model 2

The Business Model of a Stress-free event journey for car visitors as presented in Business Model 2 – Stress-free Event Journey, is a representative business model for Amsterdam Zuidoost area. We make use of this business model to show in Figure 11 below how elements of the business model radar of Figure 4 (actors and activities) map to the physical view of an ITS architecture.

25

Non-Event Visitor

Traveller /VRU

Vehicle

Event Visitor by Car

RoadsideRoad Authority

Municipality


Event Organizer

Retailer

Parking Operator

Central

Support






(V-VLS)



(SP BO)




VRU-OBU


(SPES)




Management



(R-VLS)


(CP BO)


Remote VRU-OBU

Manages Traffic

Manages TrafficProvides infra

Drives thereDrives there

Gets thereGets there

Provides parking info

Private Traffic Manager

Provides traffic data

Sends/Receives info

Access traffic state info

Provides upfront info


Provides traffic info

Manages traffic

Gathers floating data

Figure 11 Business - System Architecture Mapping - Business Model 2

In the figure above, we see how Private Traffic Manager, Road Authority and Municipality are linked

to Traffic Management System (TMS) to provide traffic management, each from their own

perspective.

Private Traffic Manager requires access to Service Provider Back-Office (SP-BO) and Service Provider

Exchange System (SPES) to provide traffic information to event visitors. They also require access to

Roadside System (RS) to get traffic data and to Vehicle On-Board Unit (OBU) to gather floating

vehicle data.

Parking Operator provides information on the availability of parking slots in his facilities to Traffic

Information System (TIS) which can be further used from the TMS for traffic management.

One point to mention is the approach we followed to distinguish the actor “Non-Event Visitor”. We

distinguished that from those who may travel around the event venue by a car (vehicle) (and thus

linked to the Vehicle layer) and from those that are in the area as pedestrians or by bike (thus linked

to the Traveller/VRU layer).

The Support layer contains sub-elements that are not directly connected to sub-elements of other

layers but cover a full spectrum of activities and processes in them. Therefore, actors that are

relevant to components of the Support layer are linked to the whole layer with a dashed line, to

26

indicate that they are not linked explicitly to specific components of it. Since our purpose in this

project is to show a blueprint mapping, we leave the explicit mapping of that layer for further

elaboration.

Finally, one notices how actors like Event Organizer, Event Location Provider and Retailers are not

directly linked to any of the components of the architecture since their activities are not related to

transportation or traffic management. The orchestration that the Event Organizer provides can be

done through its own information systems. This is shown for example in the link between the Event

Organizer and Retailer/Event Location Provider, where upfront information, like the number of

visitors, is shared.

By mapping now actors and their activities to the physical view in which connections of sub-

elements are presented, we get Figure 12:

27

Vehicle

Central

Traveler

Roadside

Support

Non-Event Visitor

Event Visitor by Car

Road Authority

Municipality

Event Organizer

Parking Operator

Manages Traffic

Manages TrafficProvides infra

Drives there

Drives there

Gets there


Gets there




OBU



or CIS)


VRU-OBU


(SPES)


RSU or RIS



(VRU-T)


(V-VLS)


(R-VRS)


(SP BO)

GovernanceTest &



Management


Private Traffic Manager



Sends/Receivesinfo

Access traffic state info


Retailer



Provides traffic data

Manages traffic

Gathers floating data

Figure 12 Business - System Architecture Mapping with connections - Business Model 2

Actors, architecture elements and activities performed by these actors on the linked components are presented in a tabular form below.

Table 1 Actors - Elements mapping for Business Model 2

Actor/Stakeholder Architecture element Activities

Event Organizer None Non ITS-related activities.

Private Traffic Manager Communication Provider Back-Office (CP BO)

The Private Traffic Manager uses CP BO to get access at several communication layers from other BO systems (like SP BO, TMS, TIS etc.) to send and receive ITS information to/from vehicles or other road users.

Roadside System Traffic state information from roadside

28

(RS) substations and traffic light controllers needs to be gathered by the Private Traffic Manager meaning that a link to RS is necessary.

Vehicle On-Board Unit (OBU) Floating vehicle data are gathered from OBUs for improved traffic management and traffic information.


Private Traffic Manager can provide enhanced traffic management through TMS.

Service Provider Back-Office (SP BO)

The Private Traffic Manager uses SP BO to support personal information services for, e.g. navigation or traffic information applications on OBU/PID.

Service Provider Exchange System (SPES)

SPES is also used for traffic information provisioning and for service authentication and authorization purposes as well.

Event Visitor by Car Vehicle On-Board Unit (OBU) The driver uses the OBU of his vehicle to get traffic/navigation information on how to get to the venue of the event.

Event Location Provider None Non ITS-related activities. Informed by the Event Location Provider through own (non-ITS) systems.

Municipality Governance Municipality uses the Governance sub-system for policy maker and regulations.


Provides traffic management through the TMS.

Parking Operator Traffic Information System (TIS) The Parking Operator provides information on the availability of parking slots in his facilities to TIS which can be further used from the TMS for traffic management.

Road Authority Traffic Management System (TMS)

Provides traffic management through the TMS.

Roadside Unit (RSU or RIS) Responsible for the road side infrastructure.


Provides traffic data to the Private Traffic Manager.

Retailer None Non ITS-related activities. Informed by the Event Location Provider through own (non-ITS) systems.

Non-Event Visitor Vehicle On-Board Unit (OBU) The non-event visitor who drives around the venue of the event uses the OBU of his vehicle to get traffic information on how to avoid traffic jams.

Personal Information Device A VRU non-event visitor can either use a PID or a VRU-OBU to get traffic information on how to avoid traffic jams.

VRU On-Board Unit (VRU-OBU)

One note we can make here about the above linking of actors to components of an ITS and their corresponding activities is that it may depict the current situation in traffic management domain, but it does need to be followed for future developments. The most representative example may be the link of a Private Traffic Manager to the Roadside System to gather traffic state information. The trend in mobility domain is that all traffic related information can be gathered with Floating Car Data (or Probe Vehicle Data) through Navigation Providers and consequently replace most of the roadside infrastructure (or limiting to the legal minimum) [5]. Also, traffic management can be provided through in-car (personalized) services by private parties, in addition to roadside traffic management

29

as performed by road authorities. Thus, in all these scenarios, actors have to link to new components to get the information they require for provisioning their services.

30

References

[1] P. Grefen, E. Lüftenegger, E. van der Linden and C. Weisleder, BASE/X Business Agility through

Cross-Organizational Service Engineering, Eindhoven University of Technology, 2014.

[2] A. Osterwalder and Y. Pigneur, Business Model Generation, Wiley, 2010.

[3] E. Lüftenegger, Service-Dominant Business Design, Eindhoven University of Technology, 2014.

[4] M. v. Sambeek, F. Ophelders, T. Bijlsma, O. Türetken, R. Eshuis, K. Traganos and P. Grefen,

“Reference Architecture for C-ITS applications,” 2014.

[5] C. J. van de Weijer and B. C. Rutten, “The fast-growing role of in-car systems in Traffic

Management,” TomTom, 2013.

31

Appendix A: BASE/X Framework

In this Appendix we present briefly the BASE/X framework which is used in the current document for business model design in a service-dominant context. We introduce the framework in A.1 Introduction and discuss business design as part of it in A.2 Business Design in BASE/X. Finally, in A.3 Tooling in BASE/X business design we present the conceptual tools in BASE/X business design.

A.1 Introduction

BASE/X framework is a well-structured way to address the analysis and design of service-dominant business. It covers the entire spectrum from high-level business strategy definition to business information system architecture design, including elements like business model conception, business service specification and business process modelling. The very core of BASE/X is the understanding that to achieve truly agile service provisioning business, these elements cannot be treated in isolation.

To capture networked, service-oriented business, BASE/X has two core business principles: 1. Business services and the value-in-use they deliver to customers are the primary building

blocks for contemporary business design and execution. 2. To deliver integrated business services as a solution to a customer, networks of

providers of basic services are required. Given the volatility of many markets, these networks must be dynamic and explicitly orchestrated. Orchestration of networks is of paramount importance.

To structure business organizations, BASE/X uses two core business engineering principles: 3. An explicit distinction is required between the stable essence of a business organization

and the agile market offerings of that organization. These two elements must be explicitly co-engineered in business design.

4. An explicit distinction is required between business structures, organization structures, and information technology structures. These three elements must be explicitly co-engineered in operations design.

Here we present a few core concepts about the business design aspect of BASE/X, while more information on the organization and IT platform design aspects can be found in the full documentation of the framework in [1].

A.2 Business Design in BASE/X

Business design in BASE/X is based on the observation that we need the distinction between business goals (the ‘what’ of business) and business operations (the ‘how’ of business) on the one hand and the distinction between the stable essence of an organization and its agile market offerings on the other hand. This leads to a model with four layers, as shown in Figure 13 below.

32

Figure 13 BASE/X Business Pyramids

As shown in the left side of the figure, the top half of the pyramid covers business goal engineering. As shown in the right of the figure, the top layer contains the service-dominant business strategy. This strategy describes the identity of an organization in a service-dominant market. The identity is relatively stable over time: the strategy evolves. The second layer contains service-dominant business models. Each business model describes a market offering in the form of an integrated, solution-oriented complex service: they describe a concrete value-in-use. Business models follow fluid market dynamics and are agile: they revolve – they are conceived, modified, and discarded as required.

The bottom half of the pyramid covers business operations engineering. The bottom layer contains business services, each of which contains a core service capability of the organization. As these capabilities are related to the resources of the organization (covering both personnel and large-scale technical infrastructures), they are relatively stable over time: they evolve. The third layer of the pyramid contains the service compositions. Each composition is a combination of business services to realize the service functionality required by a business model: they implement a concrete value-in-use. The combination includes business services from the organization’s own set, but also business services of partner organizations in a business network. As service combinations follow business models, they are agile: they revolve with their associated business models.

A.3 Tooling in BASE/X business design

BASE/X offers more than the conceptual approach outlines above. It also offers a set of business design tools for each of the four layers of the business pyramid:

For strategy design, a service-dominant business strategy canvas is available. This canvas is inspired by the well-known Business Model Canvas of [2], but focusses on the strategy level in a service-dominant context.

For business model design, a service-dominant business model radar is available. Like a canvas, this tool is a template for business design. Unlike other business modeling tools, the radar tool has network-centric business model design at its core (shown in its circular design), allowing the composition of service design in multi-party business networks.

For service composition design, models are available from established business process management practice, applied in a service management context. These include both the support of provider-managed service solutions and customer-managed service solutions.

For business service design, models, templates and design criteria are available for the creation of well-structured business service catalogs. These catalogs are the basis for the agile creation of multi-party service compositions.

33

For merely illustrative reasons, an example business strategy canvas and business model radar are shown below (taken from a service-dominant business design in the travel industry domain). The business model radar shows one of the business models associated with the business strategy modeled in the strategy canvas. Similar models can be constructed for business strategies and business models in the transport and mobility domain, supporting a clear decoupling between long-term strategic business design (e.g., including the development and deployment of core capabilities based on complex, costly infrastructures) and medium-term tactic business design (covering the development of multi-party collaboration and earning models).

Figure 14 Service Dominant Strategy Canvas for TraXP example

34

Figure 15 Service Dominant Business Model Radar for TraXP example

A.3.1 Graphical Annotation of Business Model Radar

In Service-Dominant Business Model Radar we introduced the main elements of the business model radar (core, concentric rings and radial regions). Here, we explain some graphical notations for understandability/readability reasons:

- The Customer is represented in the rightmost sector of the upper half part of the radar. The full sector is colored with a bluish tinge, i.e. light blue. The name has also a dark bluish color and is underlined.

- The Focal Organization is represented in the rightmost sector of the lower half part of the radar. The full sector is colored with a reddish tinge, i.e. light red. The name has also a dark reddish color and is underlined.

- The names of Core and Enriching Partners are written in a bluish color. Core Partners are distinguished by underlining.

- The fields of “actor value proposition” and “actor coproduction activities” of all actors have the same (e.g. bluish) color.

- Benefits are indicated by a “+” sign, while costs are indicated by a “-“ sign. - For costs/benefits of each actor, the color of the text depends whether it is related to a

benefit/cost of another actor(s) or not. o If the cost/benefit is independent to any other benefit/cost and is exclusive for the

actor, a default (e.g. dark blue) color is used. o If a cost/benefit is related to a benefit/cost of another actor(s) that appear in the

radar, the same colors (not the default ones) are used. For instance, in the example of Figure 15, the kickback fees as a benefit for TraXP has the same (green) color with

35

the kickback fees that Trasnsport, Accomondation and Insurance companies have to pay to TraXP.

Note that other colorations can be used but there should be a consistency like described above.

36

Appendix B: Participants per workshop

Below we present the lists of participants per workshop.

Table 2 Session 1 (Wednesday, 29th October, 16.00 hr – 18.00 hr)

Name Organization

Aafke den Hollander Ingenieursbureau Amsterdam


Kostas Traganos Eindhoven University of Technology (TU/e)

Marco Geresse Amsterdam ArenA

Joris Feis Trinite

Karin Ruben Parkeergebouwen Amsterdam

Daniel van Motman Gemeente Amsterdam , DIVV

Arnold Meijer TomTom

Hans Kramer Rijkswaterstaat

Giovanni Huisken MapTM

Joost van Os Stadsregio Amsterdam

Table 3 Session 2 (Thursday, 30th October, 10.00 hr – 12.00 hr)

Name Organization




Martin Cramer Mojo

Ronald Fiolet Ziggo Dome

Bep van der Molen Villa ArenA

Maarten Egmond Gemeente Amsterdam, Stadsregisseur

Henk Haverkamp Stadsdeel Zuidoost

Table 4 Session 3 (Thursday, 30th October, 13.00 hr – 15.00 hr)

Name Organization




Annet van Veenendaal Rijkswaterstaat

Harm Jan Mostert Provincie Noord Holland

Luuk Verheul Connecting Mobility

37

Appendix C: Business Models – Results of Workshops

Following the approach described in Approach, three blueprints business model radars were drawn per workshop. The original models were interactively composed on large posters with the use of post-its and can be seen in Appendix D: Original Sketches of Business Model Radars. Here we present these radars in a digital format.

C.1 Workshop 1 – Ultimate Event Experience

The identified value-in-use of this business model is the Ultimate Event Experience for visitors of an event in the area of Amsterdam Zuidoost. An Event Organizer can play the role of a focal organization with the experience they have in the event content. The customer is the Mass Event Visitor who is part of a crowd coming to the area. An Event Location Provider is a core partner since most of the events are held in specific premises/facilities. Road Authorities, Transportation Providers and Traffic Data Providers will enrich the value-in-use by providing easy access and relocation from the visitor’s home place to the event venue.

The main benefit for the customer will be a concentrated joy and good memories from the

experience of visiting the event he/she desired to. Of course, this will incur an integrated passport

ticket, including both the event ticket price and any transportation tickets (we assume that the Event

Organizer will charge for any transportation service so the user does not have to care for any extra

tickets). The integrated passport ticket is paid to the Event Organizer, while in turn they have to pay

fees for renting the location of the event. The Event Location Provider will receive these renting fees.

For the Road Authority, the main benefit we foresee is the upfront travel information of the visitors

to a specific area, in specific time range. This will subsequently lead to better traffic management.

That information is also beneficial for the Traffic Data Provider for getting insight in future for similar

events.


38

Figure 16 Workshop 1 - Ultimate Event Experience

C.2 Workshop 2 – Stress-free Event Journey

Event visitors want to have a good time and positive experience without having to care much about transportation and any event related issues. A business model with a Stress-free Event Journey value-in-use will contribute to that direction. The Event Organizer undertakes the role to orchestrate the other parties like the Event Venue provider, who provides comfort, the Road Authority who provides quick access and safe traveling to the event, the Parking Operator who provides parking services so the visitor does not have to care about his car while enjoying his favorite music band, the Public Transport Provider and any Infrastructure Provider for traffic management. Retailers are also part of the business model since they contribute to customer’s experience with pre- and post-event convenience (shopping, eating, etc.). Apart from people who are visiting an event, we care also about those who are using the same road network around Amsterdam Zuidoost, the Non-Event Visitors.

The Event Visitor will take advantage of the provided solutions when visiting an event but he will pay the ticket (including transportation and parking tickets) and any other money in the shops/bars he will visit. The Event Organizer will receive the ticket fees and also will increase their reputation by providing a stress-free experience. To do so, they have to pay rent to the Event Venue provider, pay fees for parking services of their customers and any public transport tickets, and of course pay the

39

artist. To be part of this business model and reap the benefits, the Event Venue provider has to increase its operational costs for providing more and of better quality services. The Road Authority will also benefit of that business model since such a solution will increase the reputation of the city and consequently attract more visitors and will reduce any operational costs. On the other hand, their duty of providing reliable traffic management can be considered as their main cost. The benefits for the Parking Operator are the parking fees that they get from the Event Organizer (who gets them from Event Visitors) and the efficiency in their service provision through the upfront information. However, this will incur extended operational costs. Regarding the Retailers, the turnover is an issue that needs further financial analysis whether it will be positive or negative. This is because the spending of the event visitors may be equilibrated by the fact that less people who are not visiting the event will go for shopping, drink or dinner during the event in order to avoid the crowd. The crowd will also result in more efforts to provide accessibility to that places (shops/cafes/bars). Finally, for Non-Event Visitors, the advanced traffic solutions will help them in the accessibility to the area, however they will have to endure the nuisance that the event visitors cause.


Figure 17 Workshop 2 – Stress-free event journey

40

C.3 Workshop 3 – Free Ride Amsterdam Event

The idea for this business model is rather extreme since it proposes a “free ride” to an event to those who plan their arrival by car at a much earlier time than the beginning of the event. The term free refers to free parking (or even fuel consumption coupons, however in that case we should consider gas station owners as co-creation actors). With that scenario traffic jams will be reduced and many stakeholders need to contribute. A Mobility Broker is the focal organization who gets data and services from Road Authority, Parking Provider, Event Location Provider, Event Organizer and Retail, orchestrates them and serve the event visitor. Since the services are free, the cost for the customer are non-monetary but in terms of flexibility and sacrifices in their time schedule. The Mobility Broker will get kickback fees from the Event Organizer, the Event Location Provider and the Retailers since these stakeholders will have an increased turnover from visitors who will spend their money in activities before, during and after the event. However, the broker will pay fees to the Parking Operator for providing parking services to its customers. For the Road Authority, the main benefit is that they will decrease the operational costs for providing traffic management due to less traffic jams. On the downside, they have to get and manipulate the traffic data.


41

Figure 18 Workshop 3 – Free ride Amsterdam event

42

Appendix D: Original Sketches of Business Model Radars

Below we include photographs of the original paper versions of the business model radars that were sketched during the workshops.

Figure 19 Workshop 1 - Business Model Radar

43


44


45

Appendix E: Description of elements of Physical view

Below we present an explanation of the elements of the five layers of the Physical view of the

system architecture of an ITS (Figure 22), as described in [4].

Central

Traveller /VRU

Vehicle

Roadside

Support






(V-VLS)



(SP BO)




VRU-OBU


(SPES)


GovernanceTest & certif ication


Management



(R-VLS)


(CP BO)


Remote VRU-OBU

Figure 22 ITS Reference Architecture Physical View: With Sub-systems

At the support layer the following sub-systems are defined:

1. Governance system: A system from policy makers for regulations & enforcement of the ITS system of environment / safety measures;

2. Test and certification management system: A system for registration of tested and certified communication systems for ITS (safety) applications;

3. Security and credentials management system: A high-level aggregate representation of the systems that enable trusted communications between mobile devices, roadside devices and centers, and protect data from unauthorized access. This sub-system will be implemented as an interconnected system of support applications that enable the secure distribution, use, and revocation of trust;

4. Operational Management System: A system for operational processes like fault, performance and configuration management of the sub-systems.

At the central layer the following sub-systems are defined:

1. Traffic Management System (TMS): A TMS is the functional back-office system of the responsible road operator to enforce legal actions on urban or high-way road sections or intersections based on real-time traffic data from loops, cameras, speed sensors, etc. or actions by traffic controllers. The real-time data that flows from the Traffic Info System is integrated and processed by the TMS (e.g. for incident detection), and may result in traffic measures (e.g. traffic routing, dynamic speed limits) with the goal of improving safety and traffic flow;

46

2. Traffic Information System (TIS)4: A Traffic Information System is the functional back-office system of a road-operator to collect and process real-time traffic data from traffic data systems (e.g. roadside sensor systems (loops, cameras) or connected vehicles) and to distribute real-time and/or aggregated information on traffic state (speed, flow and travel times) or road state to TMS or external systems like a Service Provider Back-Office (SP-BO). In practice several distributed TIS from different road operators can be interconnected to a central TIS (e.g. from NDW), which provides aggregated information for the Netherlands;

3. Service Provider Back-Office (SP BO): A generic back-office system of a service provider used for the specific services of the SP to connected drivers or end-users to inform end-users or other SP BO systems from providers. A SP BO can be used to support personal information services for, e.g. navigation or traffic information applications on OBU/PID. A SP BO can also be used to gather floating car data from OBU/PID;

4. Data Provider Back-Office (DP BO): A Data Provider BO system is a data system that collects and fuses floating car data and real-time traffic data from roadside sensor systems to increase insight in actual and expected traffic state (e.g. on traffic jams). The DS also distributes enriched (aggregated) information on traffic state (speed, flow and travel times) to service providers;

5. Communication Provider Back-Office (CP BO) or Central ITS System (CIS): A generic back-office system of a communication provider used for access at several communication layers from other BO systems (like SP BO, TMS, TIS etc.) to send and receive ITS information to/from vehicles or other road users;

6. Service Provider Exchange System (SPES): an e-Market (“broker”) system for discovery and exchange of ITS (end-user) services and ITS communication services; the SPES can support functions like service discovery, service authentication, authorization, accounting (AAA) and billing.

Other back-office systems can also be located at this layer depending on the type of application. One example is a Fleet and Freight Management System which provides the capability for commercial drivers and fleet-freight managers to receive real-time routing information and access databases containing vehicle and/or freight equipment locations as well as carrier, vehicle, freight equipment and driver information. Fleet and Freight Management Center also provides the capability for fleet managers to monitor the safety and security of their commercial vehicle drivers and fleet.

In the roadside (or field) area the following sub-systems are defined:

1. Roadside System (RS): Different types of existing roadside systems are identified: a. Roadside Substation (RSS): a system deployed along high-ways and includes sensors

(loops), control logic and actuators. The system can run as a stand-alone closed loop system i.e. run stand-alone local traffic control functions (e.g. traffic jam tail detection and warning via Variable Message Signs) or can be controlled by the TMS;

b. Traffic Light Controller (TLC): a TLC is a specific type of roadside system. It includes the input from loop detectors or other sensors, a control logic, and the actuation of the traffic lights. A TLC can be run as a stand-alone closed-loop traffic control system. A TLC can also be controlled by a central Traffic Management System, e.g. in green wave applications between different TLC’s. A TLC is deployed on urban road or can be deployed at highway access roads for access control;

4 A split is made between TMS and TIS. A TMS receives traffic information always via a TIS, and sends traffic

actuation measures always to external systems via a TIS. In real world a TMS consists of several building blocks for traffic control.

47

2. Roadside Unit (RSU) or Roadside ITS System (RIS): A RSU/RIS is a cooperative roadside communication system responsible for the two-way communication functionality at a part of a road network (typically an intersection or a road section of 500m – 1km). This physical object is responsible for implementing communication functionality in the roadside layer and optionally also application functions. A RSU/RIS is part of the ITS reference architecture standardised by the European Telecommunication Standards Institute (ETSI ITS). A RSU/RIS is part of the roadside communication network with distributed radio units, and centralized functions covered in the Communication Provider Back-Office.

In the vehicle area the following sub-systems are defined:

1. Vehicle Platform or Vehicle E/E system (VEE): The Vehicle Electrical and Electronic system (E/E) system includes all in-car sensors (speed, lights, etc.) and actuators (brake, etc.). The Vehicle Electrical and Electronic system provides sensor information (e.g. speed) from a vehicle to an external Cooperative-ITS (C-ITS) system and optionally enables the control/actuation (e.g. speed control) of that vehicle by an external system. The Vehicle E/E must include safety measures to ensure the safe operation of the vehicle, independent of the interaction between the Vehicle E/E and external sub-systems. A further differentiation can be made per vehicle type, e.g. emergency vehicle, commercial vehicle or (public) transport/transit vehicle;

2. Vehicle On-board Unit (OBU): An on-board unit is a sub-system attached to a car and needed for driver assisted applications to inform / advise a driver via a HMI. The OBU provides the vehicle-based processing, storage, and communications functions necessary to support connected vehicle operations. The radio(s) supporting Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications are a key component of the Vehicle OBU. Four different types of implementations are represented by the Vehicle OBU:

a. Vehicle Awareness Device – This is an aftermarket electronic device, installed in a vehicle without connection to vehicle systems that is only capable of sending the basic safety message over short-range communications. Vehicle awareness devices do not generate warnings;

b. Aftermarket Device – This is an aftermarket electronic device, installed in a vehicle, and capable of sending and receiving messages over a wireless communications link. The self-contained device includes GPS, runs connected vehicle applications, and includes an integrated driver interface that issues audible or visual warnings, alerts, and guidance to the driver of the vehicle;

c. Retrofit Device – This is an electronic device installed in vehicles by an authorized service provider, at a service facility after the vehicle has completed the manufacturing process (retrofit). This type of device provides two-way communications and is connected to a vehicle data bus to integrate the device with other on-board systems. Depending on implementation, the device may include an integrated driver interface and GPS or integrate with modules on the vehicle bus that provides these services;

d. Integrated System – This is a system of one or more electronic devices integrated into vehicles during vehicle production. The Integrated System is connected to proprietary data busses to share information with other on-board systems. The Integrated System may include many control modules.

In retrofit and integrated implementations, the Vehicle OBU interfaces to other on-board systems through a vehicle bus (e.g., Controller Area Network - CAN), represented as the Vehicle Platform, this interface provides access to on-board sensors, monitoring and control systems, and information systems that support connected vehicle applications. The vehicle bus may also be the source for GPS location and time, and the access point for the vehicle's

48

driver-vehicle interface. Self-contained devices include an integrated GPS and driver interface that supports direct visual, audible, or haptic interaction with the driver. The Vehicle OBU includes the functions and interfaces that support connected vehicle applications for passenger cars and trucks. Many of these applications (e.g., V2V Safety applications) apply to all vehicle types including personal automobiles, commercial vehicles, emergency vehicles, transit vehicles, and maintenance vehicles. The Vehicle OBU is used to model the common interfaces and functions that apply to all of these vehicle types, i.e. also commercial, public transport or emergency vehicles;

3. Remote Vehicle OBU (R-OBU): Remote Vehicle OBUs represents other vehicles that are communicating with the host vehicle. This object provides a source and destination for information transfers between connected vehicles. The host vehicle on-board unit, represented by the Vehicle OBU physical object, sends information to, and receives information from the Remote Vehicle OBUs to model all vehicle V2V communications.

At the traveller / VRU layer the following sub-systems are defined:

1. Personal Information Device (PID): A personal information device is typically a smartphone or personal navigation device used by an end-user. The PID provides the capability for travellers to receive formatted traveller information wherever they are. Capabilities include traveller information, trip planning, and route guidance. It provides travellers with the capability to receive route planning from the infrastructure at home, at work, or on-route using personal devices that may be linked with connected vehicle on-board equipment. A PID might include the communication functionality of a Personal ITS station, as specified in ETSI ITS specifications;

2. VRU Vehicle OBU (VRU-OBU): an on-board unit is a sub-system attached to a VRU vehicle (e.g. moped, electric bike) and needed for VRU assisted applications to inform / advise a driver via a HMI;

3. VRU Transponder (VRU-T): a VRU transponder is part of a tag-based communication system. A transponder can be active (i.e. with own battery, sending data at constant time intervals), semi-passive (with own battery, sending message at request of an interrogator) or passive tag/chip (without own battery, responding to interrogator request). The tags communicate with an external interrogator, called VRU Localisation System, which can be integrated in a vehicle (car, bus, truck) or in a roadside system:

Vehicle VRU Localization System (V-VLS): A VRU Localization System is part of a tag-based communication system.

Roadside VRU Localization System (R-VLS): A VRU Localization System is part of a tag-based communication system. The VRU transponder carried by a VRU, is an active (i.e. with own battery) or passive tag/chip that can respond on an interrogation signal (trigger) from the VRU Localisation System. A VRU Localization System can be integrated in, e.g., a Traffic Light to detect the presence of a specific user, e.g. a person with a disability.

The VRU transponder carried by a VRU, is an active (i.e. with own battery) or passive tag/chip that can respond on an interrogation signal (trigger) from the VRU Localisation System. This transponder is different from a VRU OBU system, since the transponder is only able to send a limited amount of data (typically only ID and potentially some sensor values, and not able of self-locating).

49

Appendix F: Business – System Architecture mapping for BM 1 and BM 3

For reasons of completeness, we present here the mapping for the complete business models 1 and 3.

F.1 Mapping for Business Model 1

Below we present how elements of the business model radar of Figure 3 (actors and activities) map to the physical view of an ITS architecture.

Traveller /VRU


Event Organizer

Public/Private Transport Facilities

Provider

VRU

Vehicle Driver

Transport InfoProvider

Transport DataProvider Parking OperatorCentral

Provides reliable real time data

Provides real time travel info

Drives there

Vehicle

Provides trip


Gets there

Roadside

Support






(V-VLS)



(SP BO)




VRU-OBU


(SPES)




Management



(R-VLS)


(CP BO)


Remote VRU-OBU

Gets there


Gathers traffic dataAuthenticates/Authorizes services


Note here the split of the Mass Event Visitor to two actors, namely Vehicle Driver and VRU. This is

done because in the business model we included both car event visitors and those who travel by

public means of transport (or walk to the event venue).

Similarly, we split the Transport Facilities Provider to Parking Operator, who is responsible for

providing parking services and Public/Private Transport Facilities Provider who provides trip for

event visitors who do not take their vehicle to drive to the event venue.


elements are presented, we get the following Figure 24:

50

Vehicle

Central

Traveler

Roadside

Support


Event Organizer

Public/Private Transport Facilities

Provider

VRU

Vehicle Driver

Transport InfoProvider

Transport DataProvider Parking Operator

Provides reliable real time data

Provides real time travel info

Drives there

Provides trip

Gets there





OBU



or CIS)


VRU-OBU


(SPES)


RSU or RIS



(VRU-T)


(V-VLS)


(R-VRS)


(SP BO)

GovernanceTest &



Management


Gets there

Gathers traffic data

Authenticates/Authorizes services

Figure 24 Business - System Architecture Mapping with connections - Business Model 1

One point we have to stress on the above figure is that main components like Traffic Management

System (TMS) or Roadside Unit (RSU or RIS), which appear to be connective components among

layers, are greyed. As we had explained in Physical View – High Level with building blocks, these

elements are owned/managed by actors that do not appear in the business model. Needless to say

that they are required in the deployment of an ITS, having to think in that case who of the identified

actors can take responsibility of those or whether is better to include more actors in the business

model.

Presenting now actors, architecture elements and activities performed by these actors on the linked elements in a tabular form, he get the following table:

51



Event Organizer None Non ITS-related activities.

Vehicle Driver Vehicle On-Board Unit (OBU) The driver uses the OBU of his vehicle to get traffic/navigation information on how to get to the venue of the event.

Vulnerable Road User (VRU)

Personal Information Device A VRU can either use a PID or a VRU-OBU to get traffic/navigation information on how to get to the venue of the event.

VRU On-Board Unit (VRU-OBU)

Event Location Provider Nonne Non ITS-related activities

Parking Operator Traffic Information System (TIS) The parking operator provides information on the availability of parking slots in his facilities to TIS which can be further used from the TMS for traffic management.

Public/Private Transport Facilities Provider

VRU On-Board Unit (VRU-OBU) Since the main activity is to provide transportation, we focus on the driver of a transport means (e.g. bus) who uses the OBU of his vehicle to get traffic information regarding his route.

Transport Info Provider Service Provider Back-Office (SP BO) The traffic info provider uses back-office systems to provide real time travel information to its users.

Service Provider Exchange System (SPES)

SPES is also used for traffic information provisioning and for service authentication and authorization purposes as well.

Transport Data Provider Data Provider Back-Office (DP BO) The traffic data provider uses back-office systems to manipulate and provide reliable real time traffic data.

Roadside System (RS) Traffic state information from roadside substations and traffic light controllers needs to be gathered by the Traffic Data Provider, meaning that a link to RS is necessary.

F.2 Mapping for Business Model 3

Below we present how elements of the business model radar of Figure 5 (actors and activities) map to the physical view of an ITS architecture.

52

Central

Event Visitor

Road Authority

Mobility Broker


Event OrganizerRetailer

Parking Operator

Vehicle

Roadside

Support





(V-VLS)



(SP BO)





(SPES)




Management


(R-VLS)


(CP BO)


Provides parking infoOrchestrates services

Manages trafficProvides infra

Drives there

Provides services


In this business model we see that we do not have an explicit Service Provider for traffic information

or navigation services. The concept of the business model is that traffic jams will be avoided due to

the fact that visitors schedule their arrival to the event venue much earlier that the starting time of

the event. One assumption could be that the Mobility Broker could provide traffic information

services or this could be done through a subcontractor, like we did in in Mapping for Business Model

2 with the mapping of Business Model 2. However, we keep the business model simple and thus only

a few actors appear in the business – system architecture mapping.


elements are presented, we get the following Figure 26.

53

Vehicle

Central

Roadside

Support

Event Visitor

Road Authority

Mobility Broker


Event OrganizerRetailer

Parking Operator


Orchestrates services

Manages trafficProvides infra

Drives there



OBU



or CIS)



(SPES)


RSU or RIS


GovernanceTest &

certif ication Management


Management


Provides services


Actors, architecture elements and activities performed by these actors on the linked elements are presented in a tabular form below.



Mobility Broker Service Provider Exchange System (SPES)

The mobility broker uses an e-Market system to orchestrate services among stakeholders (providing authorization/authentication).

Service Provider Back-Office (SP BO) A SP BO is also needed in order the Mobility Broker can provide services to its customers, event visitors and other parties.

(Scheduled) Event Visitor (by Car)

Vehicle On-Board Unit (OBU) The driver uses the OBU of his vehicle to get traffic/navigation information on how to get to the venue of the event.

Parking Operator Traffic Information System (TIS) The parking operator provides information on the availability of parking slots in his facilities to TIS

54

which can be further used from the TMS for traffic management.

Road Authority Traffic Management System (TMS) Provides traffic management through the TMS

Roadside Unit (RSU or RIS) Responsible for the road side infrastructure.

Retailer None* Non ITS-related activities (could be possibly linked to SPES to get information on expected visitors/times of arrivals).

Event Organizer None* Non ITS-related activities (could be possibly linked to SPES to get information on expected visitors/times of arrivals).

Event Location Provider None* Non ITS-related activities (could be possibly linked to SPES to get information on expected visitors/times of arrivals).

*Event Organizer, Event Location Provider and Retailer could possibly be linked to Service Provider

Exchange System (SPES) which is managed by the Mobility Broker. They can do so in order to have

access to information on how many visitors plan to visit the area and at what time slots. However,

we make the assumption that this information can be provided through own, non-ITS systems.

55

Appendix G: Contributors

The following people contributed to the completion of the work presented in this report.

Table 7 Contributors

Name Organization

Hans Kramer Rijkswaterstaat

Harry Ooststroom Rijkswaterstaat

Ronald Adams Rijkswaterstaat

Working Papers Beta 2009 - 2015 nr. Year Title Author(s) 469 467 466 465 464 463 462 461 460 459 458 457 456

2015 2014 2014 2014 2014 2014 2014 2014 2014 2014 2014 2014 2014

Business Model Prototyping for Intelligent Transport Systems. A Service-Dominant Approach Where to exert abatement effort for sustainable operations considering supply chain interactions? An Exact Algorithm for the Vehicle Routing Problem with Time Windows and Shifts The RePro technique: a new, systematic technique for rethinking care processes Exploring maintenance policy selection using the Analytic Hierarchy Process; an application for naval ships Allocating service parts in two-echelon networks at a utility company Freight consolidation in networks with transshipments A Software Architecture for a Transportation Control Tower Small traditional retailers in emerging markets Defining line replaceable units Inventories and the Credit Crisis: A Chicken and Egg Situation An Exact Approach for the Pollution-Routing Problem Fleet readiness: stocking spare parts and high- tech assets

Konstantinos Traganos, Paul Grefen, Aafke den Hollander, Oktay Türetken, Rik Eshuis Tarkan Tan, Astrid Koomen Said Dabia, Stefan Ropke, Tom Van Woensel Rob J.B. Vanwersch, Luise Pufahl, Irene Vanderfeesten, Hajo A. Reijers A.J.M. Goossens, R.J.I. Basten D. van den Berg, M.C. van der Heijden, P.C. Schuur W.J.A. van Heeswijk, M.R.K. Mes, J.M.J. Schutten, W.H.M. Zijm Anne Baumgrass, Remco Dijkman, Paul Grefen,Shaya Pourmirza, Hagen Völzer, Mathias Weske Youssef Boulaksil, Jan C. Fransoo, Edgar E. Blanco, Sallem Koubida J.E. Parada Puig, R.J.I. Basten Maximiliano Udenio, Vishal Gaur, Jan C. Fransoo Said Dabia, Emrah Demir, Tom Van Woensel Rob J.I. Basten, Joachim J. Arts

455 454 453 452 451 450 449 448 447 446 445 444 443 442

2014 2014 2014 2014 2014 2014 2014 2014 2014 2014 2014 2014 2014 2013

Competitive Solutions for Cooperating Logistics Providers Simulation Framework to Analyse Operating Room Release Mechanisms A Unified Race Algorithm for Offline Parameter Tuning Cost, carbon emissions and modal shift in intermodal network design decisions Transportation Cost and CO2 Emissions in Location Decision Models Tracebook: A Dynamic Checklist Support System Intermodal hinterland network design with multiple actors The Share-a-Ride Problem: People and Parcels Sharing Taxis Stochastic inventory models for a single item at a single location Optimal and heuristic repairable stocking and expediting in a fluctuating demand environment Connecting inventory control and repair shop control: a differentiated control structure for repairable spare parts A survey on design and usage of Software Reference Architectures Extending and Adapting the Architecture Tradeoff Analysis Method for the Evaluation of Software Reference Architectures A multimodal network flow problem with product Quality preservation, transshipment, and asset management

Behzad Hezarkhani, Marco Slikker, Tom Van Woensel Rimmert van der Kooij, Martijn Mes, Erwin Hans Tim van Dijk, Martijn Mes, Marco Schutten, Joaquim Gromicho Yann Bouchery, Jan Fransoo Josue C. Vélazquez-Martínez, Jan C. Fransoo, Edgar E. Blanco, Jaime Mora- Vargas Shan Nan, Pieter Van Gorp, Hendrikus H.M. Korsten, Richard Vdovjak, Uzay Kaymak Yann Bouchery, Jan Fransoo Baoxiang Li, Dmitry Krushinsky, Hajo A. Reijers, Tom Van Woensel K.H. van Donselaar, R.A.C.M. Broekmeulen Joachim Arts, Rob Basten, Geert-Jan van Houtum M.A. Driessen, W.D. Rustenburg, G.J. van Houtum, V.C.S. Wiers Samuil Angelov, Jos Trienekens, Rob Kusters Samuil Angelov, Jos J.M. Trienekens, Paul Grefen Maryam SteadieSeifi, Nico Dellaert, Tom Van Woensel

441 440 439 438 437 436 435 434 433 432 431 430

2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013

Integrating passenger and freight transportation: Model formulation and insights The Price of Payment Delay On Characterization of the Core of Lane Covering Games via Dual Solutions Destocking, the Bullwhip Effect, and the Credit Crisis: Empirical Modeling of Supply Chain Dynamics Methodological support for business process Redesign in healthcare: a systematic literature review Dynamics and equilibria under incremental Horizontal differentiation on the Salop circle Analyzing Conformance to Clinical Protocols Involving Advanced Synchronizations Models for Ambulance Planning on the Strategic and the Tactical Level Mode Allocation and Scheduling of Inland Container Transportation: A Case-Study in the Netherlands Socially responsible transportation and lot sizing: Insights from multiobjective optimization Inventory routing for dynamic waste collection Simulation and Logistics Optimization of an Integrated Emergency Post

Veaceslav Ghilas, Emrah Demir, Tom Van Woensel K. van der Vliet, M.J. Reindorp, J.C. Fransoo Behzad Hezarkhani, Marco Slikker, Tom van Woensel Maximiliano Udenio, Jan C. Fransoo, Robert Peels Rob J.B. Vanwersch, Khurram Shahzad, Irene Vanderfeesten, Kris Vanhaecht, Paul Grefen, Liliane Pintelon, Jan Mendling, Geofridus G. Van Merode, Hajo A. Reijers B. Vermeulen, J.A. La Poutré, A.G. de Kok Hui Yan, Pieter Van Gorp, Uzay Kaymak, Xudong Lu, Richard Vdovjak, Hendriks H.M. Korsten, Huilong Duan J. Theresia van Essen, Johann L. Hurink, Stefan Nickel, Melanie Reuter Stefano Fazi, Tom Van Woensel, Jan C. Fransoo Yann Bouchery, Asma Ghaffari, Zied Jemai, Jan Fransoo Martijn Mes, Marco Schutten, Arturo Pérez Rivera N.J. Borgman, M.R.K. Mes, I.M.H. Vliegen, E.W. Hans

429 428 427 426 425 424 423 422 421 420 419 418

2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013

Last Time Buy and Repair Decisions for Spare Parts A Review of Recent Research on Green Road Freight Transportation Typology of Repair Shops for Maintenance Spare Parts A value network development model and Implications for innovation and production network management Single Vehicle Routing with Stochastic Demands: Approximate Dynamic Programming Influence of Spillback Effect on Dynamic Shortest Path Problems with Travel-Time-Dependent Network Disruptions Dynamic Shortest Path Problem with Travel-Time-Dependent Stochastic Disruptions: Hybrid Approximate Dynamic Programming Algorithms with a Clustering Approach System-oriented inventory models for spare parts Lost Sales Inventory Models with Batch Ordering And Handling Costs Response speed and the bullwhip Anticipatory Routing of Police Helicopters Supply Chain Finance: research challenges ahead

S. Behfard, M.C. van der Heijden, A. Al Hanbali, W.H.M. Zijm Emrah Demir, Tolga Bektas, Gilbert Laporte M.A. Driessen, V.C.S. Wiers, G.J. van Houtum, W.D. Rustenburg B. Vermeulen, A.G. de Kok C. Zhang, N.P. Dellaert, L. Zhao, T. Van Woensel, D. Sever Derya Sever, Nico Dellaert, Tom Van Woensel, Ton de Kok Derya Sever, Lei Zhao, Nico Dellaert, Tom Van Woensel, Ton de Kok R.J.I. Basten, G.J. van Houtum T. Van Woensel, N. Erkip, A. Curseu, J.C. Fransoo Maximiliano Udenio, Jan C. Fransoo, Eleni Vatamidou, Nico Dellaert Rick van Urk, Martijn R.K. Mes, Erwin W. Hans Kasper van der Vliet, Matthew J. Reindorp, Jan C. Fransoo

417 416 415 414 413 412 411 410 409 408 407 406

2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013 2013

Improving the Performance of Sorter Systems By Scheduling Inbound Containers Regional logistics land allocation policies: Stimulating spatial concentration of logistics firms The development of measures of process harmonization BASE/X. Business Agility through Cross- Organizational Service Engineering The Time-Dependent Vehicle Routing Problem with Soft Time Windows and Stochastic Travel Times Clearing the Sky - Understanding SLA Elements in Cloud Computing Approximations for the waiting time distribution In an M/G/c priority queue To co-locate or not? Location decisions and logistics concentration areas The Time-Dependent Pollution-Routing Problem Scheduling the scheduling task: A time Management perspective on scheduling Clustering Clinical Departments for Wards to Achieve a Prespecified Blocking Probability MyPHRMachines: Personal Health Desktops in the Cloud

S.W.A. Haneyah, J.M.J. Schutten, K. Fikse Frank P. van den Heuvel, Peter W. de Langen, Karel H. van Donselaar, Jan C. Fransoo Heidi L. Romero, Remco M. Dijkman, Paul W.P.J. Grefen, Arjan van Weele Paul Grefen, Egon Lüftenegger, Eric van der Linden, Caren Weisleder Duygu Tas, Nico Dellaert, Tom van Woensel, Ton de Kok Marco Comuzzi, Guus Jacobs, Paul Grefen A. Al Hanbali, E.M. Alvarez, M.C. van der van der Heijden Frank P. van den Heuvel, Karel H. van Donselaar, Rob A.C.M. Broekmeulen, Jan C. Fransoo, Peter W. de Langen Anna Franceschetti, Dorothée Honhon,Tom van Woensel, Tolga Bektas, GilbertLaporte. J.A. Larco, V. Wiers, J. Fransoo J. Theresia van Essen, Mark van Houdenhoven, Johann L. Hurink Pieter Van Gorp, Marco Comuzzi

405 404 403 402 401 400 399 398 397 396 395

2013 2012 2012 2012 2012 2012 2012 2012 2012 2012

Maximising the Value of Supply Chain Finance Reaching 50 million nanostores: retail distribution in emerging megacities A Vehicle Routing Problem with Flexible Time Windows The Service Dominant Business Model: A Service Focused Conceptualization Relationship between freight accessibility and Logistics employment in US counties A Condition-Based Maintenance Policy for Multi-Component Systems with a High Maintenance Setup Cost A flexible iterative improvement heuristic to Support creation of feasible shift rosters in Self-rostering Scheduled Service Network Design with Synchronization and Transshipment Constraints For Intermodal Container Transportation Networks Destocking, the bullwhip effect, and the credit Crisis: empirical modeling of supply chain Dynamics Vehicle routing with restricted loading capacities Service differentiation through selective lateral transshipments

Kasper van der Vliet, Matthew J. Reindorp, Jan C. Fransoo Edgar E. Blanco, Jan C. Fransoo Duygu Tas, Ola Jabali, Tom van Woensel Egon Lüftenegger, Marco Comuzzi, Paul Grefen, Caren Weisleder Frank P. van den Heuvel, Liliana Rivera,Karel H. van Donselaar, Ad de Jong,Yossi Sheffi, Peter W. de Langen, Jan C.Fransoo Qiushi Zhu, Hao Peng, Geert-Jan van Houtum E. van der Veen, J.L. Hurink, J.M.J. Schutten, S.T. Uijland K. Sharypova, T.G. Crainic, T. van Woensel, J.C. Fransoo Maximiliano Udenio, Jan C. Fransoo, Robert Peels J. Gromicho, J.J. van Hoorn, A.L. Kok J.M.J. Schutten E.M. Alvarez, M.C. van der Heijden, I.M.H. Vliegen, W.H.M. Zijm

394 393 392 391 390 389 388 387 386 385

2012 2012 2012 2012 2012 2012 2012 2012 2012 2012 2012 2012

A Generalized Simulation Model of an Integrated Emergency Post Business Process Technology and the Cloud: Defining a Business Process Cloud Platform Vehicle Routing with Soft Time Windows and Stochastic Travel Times: A Column Generation And Branch-and-Price Solution Approach Improve OR-Schedule to Reduce Number of Required Beds How does development lead time affect performance over the ramp-up lifecycle? Evidence from the consumer electronics industry The Impact of Product Complexity on Ramp- Up Performance Co-location synergies: specialized versus diverse logistics concentration areas Proximity matters: Synergies through co-location of logistics establishments Spatial concentration and location dynamics in logistics:the case of a Dutch province FNet: An Index for Advanced Business Process Querying

Martijn Mes, Manon Bruens Vasil Stoitsev, Paul Grefen D. Tas, M. Gendreau, N. Dellaert, T. van Woensel, A.G. de Kok J.T. v. Essen, J.M. Bosch, E.W. Hans, M. v. Houdenhoven, J.L. Hurink Andres Pufall, Jan C. Fransoo, Ad de Jong Andreas Pufall, Jan C. Fransoo, Ad de Jong, Ton de Kok Frank P.v.d. Heuvel, Peter W.de Langen, Karel H. v. Donselaar, Jan C. Fransoo Frank P.v.d. Heuvel, Peter W.de Langen, Karel H. v.Donselaar, Jan C. Fransoo Frank P. v.d.Heuvel, Peter W.de Langen, Karel H.v. Donselaar, Jan C. Fransoo Zhiqiang Yan, Remco Dijkman, Paul Grefen W.R. Dalinghaus, P.M.E. Van Gorp

384 383 382 381 380 379 378 377 375 374 373 372 371

2012 2012 2012 2012 2012 2012 2012 2012 2012 2012 2012 2011

Defining Various Pathway Terms The Service Dominant Strategy Canvas: Defining and Visualizing a Service Dominant Strategy through the Traditional Strategic Lens A Stochastic Variable Size Bin Packing Problem With Time Constraints Coordination and Analysis of Barge Container Hinterland Networks Proximity matters: Synergies through co-location of logistics establishments A literature review in process harmonization: a conceptual framework A Generic Material Flow Control Model for Two Different Industries Improving the performance of sorter systems by scheduling inbound containers Strategies for dynamic appointment making by container terminals MyPHRMachines: Lifelong Personal Health Records in the Cloud Service differentiation in spare parts supply through dedicated stocks Spare parts inventory pooling: how to share the benefits

Egon Lüftenegger, Paul Grefen, Caren Weisleder Stefano Fazi, Tom van Woensel, Jan C. Fransoo K. Sharypova, T. van Woensel, J.C. Fransoo Frank P. van den Heuvel, Peter W. de Langen, Karel H. van Donselaar, Jan C. Fransoo Heidi Romero, Remco Dijkman, Paul Grefen, Arjan van Weele S.W.A. Haneya, J.M.J. Schutten, P.C. Schuur, W.H.M. Zijm H.G.H. Tiemessen, M. Fleischmann, G.J. van Houtum, J.A.E.E. van Nunen, E. Pratsini Albert Douma, Martijn Mes Pieter van Gorp, Marco Comuzzi E.M. Alvarez, M.C. van der Heijden, W.H.M. Zijm Frank Karsten, Rob Basten X.Lin, R.J.I. Basten, A.A. Kranenburg, G.J. van Houtum

370 369 368 367 366 365 364 363 362 361 360 359 358

2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2011

Condition based spare parts supply Using Simulation to Assess the Opportunities of Dynamic Waste Collection Aggregate overhaul and supply chain planning for rotables Operating Room Rescheduling Switching Transport Modes to Meet Voluntary Carbon Emission Targets On two-echelon inventory systems with Poisson demand and lost sales Minimizing the Waiting Time for Emergency Surgery Vehicle Routing Problem with Stochastic Travel Times Including Soft Time Windows and Service Costs A New Approximate Evaluation Method for Two-Echelon Inventory Systems with Emergency Shipments Approximating Multi-Objective Time-Dependent Optimization Problems Branch and Cut and Price for the Time Dependent Vehicle Routing Problem with Time Window Analysis of an Assemble-to-Order System with Different Review Periods Interval Availability Analysis of a Two-Echelon, Multi-Item System Carbon-Optimal and Carbon-Neutral Supply Chains

Martijn Mes J. Arts, S.D. Flapper, K. Vernooij J.T. van Essen, J.L. Hurink, W. Hartholt, B.J. van den Akker Kristel M.R. Hoen, Tarkan Tan, Jan C. Fransoo, Geert-Jan van Houtum Elisa Alvarez, Matthieu van der Heijden J.T. van Essen, E.W. Hans, J.L. Hurink, A. Oversberg Duygu Tas, Nico Dellaert, Tom van Woensel, Ton de Kok Erhun Özkan, Geert-Jan van Houtum, Yasemin Serin Said Dabia, El-Ghazali Talbi, Tom Van Woensel, Ton de Kok Said Dabia, Stefan Röpke, Tom Van Woensel, Ton de Kok A.G. Karaarslan, G.P. Kiesmüller, A.G. de Kok Ahmad Al Hanbali, Matthieu van der Heijden Felipe Caro, Charles J. Corbett, Tarkan Tan, Rob Zuidwijk Sameh Haneyah, Henk Zijm, Marco Schutten, Peter Schuur

357 356 355 354 353 352 351 350 349 348 347 346 345 344

2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2011 2010 2010

Generic Planning and Control of Automated Material Handling Systems: Practical Requirements Versus Existing Theory Last time buy decisions for products sold under warranty Spatial concentration and location dynamics in logistics: the case of a Dutch provence Identification of Employment Concentration Areas BOMN 2.0 Execution Semantics Formalized as Graph Rewrite Rules: extended version Resource pooling and cost allocation among independent service providers A Framework for Business Innovation Directions The Road to a Business Process Architecture: An Overview of Approaches and their Use Effect of carbon emission regulations on transport mode selection under stochastic demand An improved MIP-based combinatorial approach for a multi-skill workforce scheduling problem An approximate approach for the joint problem of level of repair analysis and spare parts stocking Joint optimization of level of repair analysis and spare parts stocks Inventory control with manufacturing lead time flexibility Analysis of resource pooling games via a new extenstion of the Erlang loss function

M. van der Heijden, B. Iskandar Frank P. van den Heuvel, Peter W. de Langen, Karel H. van Donselaar, Jan C. Fransoo Frank P. van den Heuvel, Peter W. de Langen, Karel H. van Donselaar, Jan C. Fransoo Pieter van Gorp, Remco Dijkman Frank Karsten, Marco Slikker, Geert-Jan van Houtum E. Lüftenegger, S. Angelov, P. Grefen Remco Dijkman, Irene Vanderfeesten, Hajo A. Reijers K.M.R. Hoen, T. Tan, J.C. Fransoo G.J. van Houtum Murat Firat, Cor Hurkens R.J.I. Basten, M.C. van der Heijden, J.M.J. Schutten R.J.I. Basten, M.C. van der Heijden, J.M.J. Schutten Ton G. de Kok Frank Karsten, Marco Slikker, Geert-Jan van Houtum Murat Firat, C.A.J. Hurkens, Gerhard J. Woeginger

343 342 341 339 338 335 334 333 332 331 330 329 328 327

2010 2010 2010 2010 2010 2010 2010 2010 2010 2010 2010 2010 2010

Vehicle refueling with limited resources Optimal Inventory Policies with Non-stationary Supply Disruptions and Advance Supply Information Redundancy Optimization for Critical Components in High-Availability Capital Goods Analysis of a two-echelon inventory system with two supply modes Analysis of the dial-a-ride problem of Hunsaker and Savelsbergh Attaining stability in multi-skill workforce scheduling Flexible Heuristics Miner (FHM) An exact approach for relating recovering surgical patient workload to the master surgical schedule Efficiency evaluation for pooling resources in health care The Effect of Workload Constraints in Mathematical Programming Models for Production Planning Using pipeline information in a multi-echelon spare parts inventory system Reducing costs of repairable spare parts supply systems via dynamic scheduling Identification of Employment Concentration and Specialization Areas: Theory and Application

Bilge Atasoy, Refik Güllü, TarkanTan Kurtulus Baris Öner, Alan Scheller-Wolf Geert-Jan van Houtum Joachim Arts, Gudrun Kiesmüller Murat Firat, Gerhard J. Woeginger Murat Firat, Cor Hurkens A.J.M.M. Weijters, J.T.S. Ribeiro P.T. Vanberkel, R.J. Boucherie, E.W. Hans, J.L. Hurink, W.A.M. van Lent, W.H. van Harten Peter T. Vanberkel, Richard J. Boucherie, Erwin W. Hans, Johann L. Hurink, Nelly Litvak M.M. Jansen, A.G. de Kok, I.J.B.F. Adan Christian Howard, Ingrid Reijnen, Johan Marklund, Tarkan Tan H.G.H. Tiemessen, G.J. van Houtum F.P. van den Heuvel, P.W. de Langen, K.H. van Donselaar, J.C. Fransoo Murat Firat, Cor Hurkens

326 325 324 323 322 321 320 319 318 317 316 315 314

2010 2010 2010 2010 2010 2010 2010 2010 2010 2010 2010

A combinatorial approach to multi-skill workforce scheduling Stability in multi-skill workforce scheduling Maintenance spare parts planning and control: A framework for control and agenda for future research Near-optimal heuristics to set base stock levels in a two-echelon distribution network Inventory reduction in spare part networks by selective throughput time reduction The selective use of emergency shipments for service-contract differentiation Heuristics for Multi-Item Two-Echelon Spare Parts Inventory Control Problem with Batch Ordering in the Central Warehouse Preventing or escaping the suppression mechanism: intervention conditions Hospital admission planning to optimize major resources utilization under uncertainty Minimal Protocol Adaptors for Interacting Services Teaching Retail Operations in Business and Engineering Schools Design for Availability: Creating Value for Manufacturers and Customers Transforming Process Models: executable rewrite rules versus a formalized Java program Getting trapped in the suppression of exploration: A simulation model

Murat Firat, Cor Hurkens, Alexandre Laugier M.A. Driessen, J.J. Arts, G.J. v. Houtum, W.D. Rustenburg, B. Huisman R.J.I. Basten, G.J. van Houtum M.C. van der Heijden, E.M. Alvarez, J.M.J. Schutten E.M. Alvarez, M.C. van der Heijden, W.H. Zijm B. Walrave, K. v. Oorschot, A.G.L. Romme Nico Dellaert, Jully Jeunet. R. Seguel, R. Eshuis, P. Grefen. Tom Van Woensel, Marshall L. Fisher, Jan C. Fransoo. Lydie P.M. Smets, Geert-Jan van Houtum, Fred Langerak. Pieter van Gorp, Rik Eshuis. Bob Walrave, Kim E. van Oorschot, A. Georges L. Romme S. Dabia, T. van Woensel, A.G. de Kok

313 A Dynamic Programming Approach to Multi-Objective Time-Dependent Capacitated Single Vehicle Routing Problems with Time Windows

312 2010 Tales of a So(u)rcerer: Optimal Sourcing Decisions Under Alternative Capacitated Suppliers and General Cost Structures

Osman Alp, Tarkan Tan

311 2010 In-store replenishment procedures for perishable inventory in a retail environment with handling costs and storage constraints

R.A.C.M. Broekmeulen, C.H.M. Bakx

310 2010 The state of the art of innovation-driven business models in the financial services industry

E. Lüftenegger, S. Angelov, E. van der Linden, P. Grefen

309 2010 Design of Complex Architectures Using a Three Dimension Approach: the CrossWork Case R. Seguel, P. Grefen, R. Eshuis

308 2010 Effect of carbon emission regulations on transport mode selection in supply chains

K.M.R. Hoen, T. Tan, J.C. Fransoo, G.J. van Houtum

307 2010 Interaction between intelligent agent strategies for real-time transportation planning

Martijn Mes, Matthieu van der Heijden, Peter Schuur

306 2010 Internal Slackening Scoring Methods Marco Slikker, Peter Borm, René van den Brink

305 2010 Vehicle Routing with Traffic Congestion and Drivers' Driving and Working Rules

A.L. Kok, E.W. Hans, J.M.J. Schutten, W.H.M. Zijm

304 2010 Practical extensions to the level of repair analysis R.J.I. Basten, M.C. van der Heijden, J.M.J. Schutten

303 2010 Ocean Container Transport: An Underestimated and Critical Link in Global Supply Chain Performance

Jan C. Fransoo, Chung-Yee Lee

302 2010 Capacity reservation and utilization for a manufacturer with uncertain capacity and demand Y. Boulaksil; J.C. Fransoo; T. Tan

300 2009 Spare parts inventory pooling games F.J.P. Karsten; M. Slikker; G.J. van Houtum

299 2009 Capacity flexibility allocation in an outsourced supply chain with reservation Y. Boulaksil, M. Grunow, J.C. Fransoo

298

2010

An optimal approach for the joint problem of level of repair analysis and spare parts stocking

R.J.I. Basten, M.C. van der Heijden, J.M.J. Schutten

297 2009 Responding to the Lehman Wave: Sales Forecasting and Supply Management during the Credit Crisis

Robert Peels, Maximiliano Udenio, Jan C. Fransoo, Marcel Wolfs, Tom Hendrikx

296 2009 An exact approach for relating recovering surgical patient workload to the master surgical schedule

Peter T. Vanberkel, Richard J. Boucherie, Erwin W. Hans, Johann L. Hurink, Wineke A.M. van Lent, Wim H. van Harten

295

2009

An iterative method for the simultaneous optimization of repair decisions and spare parts stocks

R.J.I. Basten, M.C. van der Heijden, J.M.J. Schutten

294 2009 Fujaba hits the Wall(-e) Pieter van Gorp, Ruben Jubeh, Bernhard Grusie, Anne Keller

http://beta.ieis.tue.nl/node/1523


































293 2009 Implementation of a Healthcare Process in Four Different Workflow Systems

R.S. Mans, W.M.P. van der Aalst, N.C. Russell, P.J.M. Bakker

292 2009 Business Process Model Repositories - Framework and Survey

Zhiqiang Yan, Remco Dijkman, Paul Grefen

291 2009 Efficient Optimization of the Dual-Index Policy Using Markov Chains

Joachim Arts, Marcel van Vuuren, Gudrun Kiesmuller

290 2009 Hierarchical Knowledge-Gradient for Sequential Sampling

Martijn R.K. Mes; Warren B. Powell; Peter I. Frazier

289 2009 Analyzing combined vehicle routing and break scheduling from a distributed decision making perspective

C.M. Meyer; A.L. Kok; H. Kopfer; J.M.J. Schutten

288 2009 Anticipation of lead time performance in Supply Chain Operations Planning

Michiel Jansen; Ton G. de Kok; Jan C. Fransoo

287 2009 Inventory Models with Lateral Transshipments: A Review

Colin Paterson; Gudrun Kiesmuller; Ruud Teunter; Kevin Glazebrook

286 2009 Efficiency evaluation for pooling resources in health care

P.T. Vanberkel; R.J. Boucherie; E.W. Hans; J.L. Hurink; N. Litvak

285 2009 A Survey of Health Care Models that Encompass Multiple Departments

P.T. Vanberkel; R.J. Boucherie; E.W. Hans; J.L. Hurink; N. Litvak

284 2009 Supporting Process Control in Business Collaborations

S. Angelov; K. Vidyasankar; J. Vonk; P. Grefen

283 2009 Inventory Control with Partial Batch Ordering O. Alp; W.T. Huh; T. Tan

282 2009 Translating Safe Petri Nets to Statecharts in a Structure-Preserving Way R. Eshuis

281 2009 The link between product data model and process model J.J.C.L. Vogelaar; H.A. Reijers

280 2009 Inventory planning for spare parts networks with delivery time requirements I.C. Reijnen; T. Tan; G.J. van Houtum

279 2009 Co-Evolution of Demand and Supply under Competition B. Vermeulen; A.G. de Kok

278 277

2010 2009

Toward Meso-level Product-Market Network Indices for Strategic Product Selection and (Re)Design Guidelines over the Product Life-Cycle An Efficient Method to Construct Minimal Protocol Adaptors

B. Vermeulen, A.G. de Kok R. Seguel, R. Eshuis, P. Grefen

276 2009 Coordinating Supply Chains: a Bilevel Programming Approach Ton G. de Kok, Gabriella Muratore

275 2009 Inventory redistribution for fashion products under demand parameter update G.P. Kiesmuller, S. Minner

274 2009 Comparing Markov chains: Combining aggregation and precedence relations applied to sets of states

A. Busic, I.M.H. Vliegen, A. Scheller-Wolf

273 2009 Separate tools or tool kits: an exploratory study of engineers' preferences

I.M.H. Vliegen, P.A.M. Kleingeld, G.J. van Houtum









































272 2009 An Exact Solution Procedure for Multi-Item Two-Echelon Spare Parts Inventory Control Problem with Batch Ordering

Engin Topan, Z. Pelin Bayindir, Tarkan Tan

271 2009 Distributed Decision Making in Combined Vehicle Routing and Break Scheduling

C.M. Meyer, H. Kopfer, A.L. Kok, M. Schutten

270 2009 Dynamic Programming Algorithm for the Vehicle Routing Problem with Time Windows and EC Social Legislation

A.L. Kok, C.M. Meyer, H. Kopfer, J.M.J. Schutten

269 2009 Similarity of Business Process Models: Metics and Evaluation

Remco Dijkman, Marlon Dumas, Boudewijn van Dongen, Reina Kaarik, Jan Mendling

267 2009 Vehicle routing under time-dependent travel times: the impact of congestion avoidance A.L. Kok, E.W. Hans, J.M.J. Schutten

266 2009 Restricted dynamic programming: a flexible framework for solving realistic VRPs

J. Gromicho; J.J. van Hoorn; A.L. Kok; J.M.J. Schutten;

Working Papers published before 2009 see: http://beta.ieis.tue.nl















http://beta.ieis.tue.nl/

Business model prototyping for intelligent transport systems: a … · Business Model Prototyping...

Documents

Transcript of Business model prototyping for intelligent transport systems: a … · Business Model Prototyping...