Next steps for the pan-european Mobility Portal public-services.eu

Transcription

1 Next steps for the pan-european Mobility Portal public-services.eu Discussion document Hans C. Arents Disclaimer: the information contained in this document is for informational purposes only. It contains the personal point of view of the author of the document. In no way does it represent an official standpoint of the Belgian delegation in the TAC, nor does the Belgian delegation necessarily endorse this point of view. It is intended solely as a starting point for further discussions. Page 1 of 25

2 TABLE OF CONTENTS 1 INTRODUCTION What pan-european e-government services do EU citizens and enterprises really want? What pan-european e-government services can Member States realistically provide? WHAT SHOULD THE PAN-EUROPEAN MOBILITY PORTAL OFFER? How does the portal user want to access information and services? I want information on I want to Examples of task-oriented portals How can task-oriented access to information and services be provided? Static listing Static task-oriented listing Dynamic task-oriented listing WHAT ARE THE NEXT STEPS FOR THE PAN-EUROPEAN MOBILITY PORTAL? Phase 1: from static listing to static task-oriented listing What does the EU Commission need to do? What do the Member States need to do? Phase 2: from static task-oriented listing to dynamic task-oriented listing What does the EU Commission need to do? What do the Member States need to do? HOW ABOUT THE MAIN ISSUES OF THE PORTAL IMPLEMENTATION STRATEGY?...23 Page 2 of 25

3 1 Introduction The stated aim of the pan-european Mobility Portal of the EU Administration is the provision to European citizens and enterprises of public online information and services with a cross-border dimension. The portal has to offer services to both EU citizens and enterprises in real-life situations (for example citizens wishing to work or study in another MS, or EU enterprises wanting to move or open a new branch in another MS). The portal therefore has to assist EU enterprises and citizens wishing to settle in another Member State or to perform their activity in a pan-european context. I believe the portal in its present version ( is a first and very important step towards the achievement of these goals, but still fails to address the real challenges of building such a portal: 1. determining what the essential pan-european e-government services (information, interaction, transaction) are that EU citizens and enterprises want / need to use in their cross-border activities 2. developing a technical and organisational framework that will allow Member States, together with IDA, to provide these pan-european e-government services in an efficient & cost-effective way This document tries to offer a number of ideas on how these challenges could be addressed, in order to define the steps we need to follow for the next version of the pan-european Mobility Portal. 1.1 What pan-european e-government services do EU citizens and enterprises really want? In 2001, under the auspices of the Swedish presidency of the European Union, IDA co-organised with the Swedish administration a conference egovernment in the service of European citizens and enterprises What is required at the European level. The conference concluded, inter alia, that the pan-european dimension of e-government services was at present very poorly addressed, and that the main obstacles were not exclusively related to technological problems. Following from this, and to assist in policy formation on the pan-european aspect of e-government, in April 2002 IDA issued a discussion document for a future policy paper on pan-european government e-services. This document was used during an on-line open consultation by the Enterprise Directorate General. While this was not a scientific survey or opinion poll, the consultation did offer some useful conclusions for policy makers in the field of e-government, particularly at the pan-european level. Of particular interest for the future of the pan-european Mobility Portal is the consultation s conclusion (amongst others) that The barriers to pan-european government e-services are not exclusively technological (although problems relating to interoperability and electronic certificates were identified), or language related. They mainly involve administrative procedures, lack of transparency, nonequivalence of procedures, etc. This conclusion seems to suggest that the goal of the pan-european Mobility Portal should be to: Help EU citizens and enterprises to understand and perform the administrative procedures that are required to perform a particular cross-border activity, i.e. help EU citizens and enterprises to find the correct e-government information and access the appropriate e-government services (when available) that will allow him or her to perform a particular cross-border activity. The challenge is then to precisely determine what those priority cross-border activities are, i.e. what are the cross-border activities that the EU citizens and enterprises most urgently want to able to perform using the pan-european Mobility Portal. The list of priority cross-border activities which was identified during the current pilot project (Moving to a Country, Setting up an Enterprise, ) is a good starting point for the implementation of next phase of the portal. However, I agree with the IDA team that it is necessary to follow a more rigorous 'demand-driven' approach to determine the correct Page 3 of 25

4 priority activities, based on the real needs of EU citizens and enterprises. The ex-ante evaluation of the next phase of the portal, planned by IDA, could be very useful in determining this list of priority cross-border activities. I would therefore suggest that the contractor for the ex-ante evaluation should focus its efforts on the prospective analysis step foreseen in their methodology and action plan for this evaluation, as this step would include interviews with intermediaries representing citizens and enterprises, resulting in an analysis of services of a cross-border portal and their prioritisation. 1.2 What pan-european e-government services can Member States realistically provide? In the eeurope benchmarks for e-government services, carried out by the DG Information Society, a distinction is made between 4 levels of online sophistication of these services: Level 1 Level 2 Level 3 Level 4 Information: access to information about government services One-way interaction: downloading of electronic forms, the government service is still completely done in a traditional paper-based way Two-way interaction: submission of electronic forms, the government service is still partially done in a traditional paper-based way Transaction: fully electronic delivery of the government service, i.e. the service is done completely electronically At level 4, an additional distinction can actually be made between: Level 4a Single-integration transaction: fully electronic delivery of the government service, i.e. the service is done completely electronically, based only on the integration of applications within one single government entity Level 4b Multi-integration transaction: fully electronic delivery of the government service, i.e. the service is done completely electronically, based on the integration of several applications across multiple government entities In order to provide truly integrated pan-european e-government services, i.e. e-government services where a high degree of integration and interoperability between the administrations of different Member States is achieved, these Member States will have to able to offer e-government services at Level 4b of sophistication. If Member States do not yet provide these kind of services, and have no experience with the challenges involved in integrating applications across multiple government entities it is difficult to imagine how they could participate in integrated pan-european e-government services. The April 2002 eeurope benchmark for e-government services ( Web-based Survey on Electronic Public Services ) for the 15 EU Member States, plus Iceland, Norway and Switzerland, concluded that the level of online availability of public services in the different countries is now 55%. However, there is a wide spread between the results of the different countries, going from 22% to 85%. Some countries have already reached Level 4, while others are still at Level 1 in their e-government efforts. Even those countries who have already reached Level 4 offer primarily transactional services involving very simple procedures, provided by just one single e-government service provider (i.e. single-integration transaction ). Most Member States do not yet have the technical infrastructure (e.g. a e-government service integration gateway, such as the UK s Government Gateway) or the organisational framework (e.g. interoperability standards, such as the UK s e-government Interoperability Framework) to offer transactional services involving complex procedures, provided by several different government service providers (i.e. multi-integration transaction ). One of the main challenges for the next IDA programme is indeed going to be how to further stimulate Member States to build out such a technical infrastructure and to set up such an organisational framework, so as to be able to achieve pan-european electronic integration and interoperability between the administrations of different Member States. Page 4 of 25

5 This state of affairs means that initially we should not be too ambitious when building a pan-european Mobility Portal: we should focus on building a central portal site which simply refers to the correct e- government information (Level 1) and the appropriate e-government services (Levels 2, 3 and 4) at the Member State level, rather than build a portal site which offers its own pan-european services, built by integrating existing e-government services made available by the Member States. Building pan-european e-government services by joining up existing national, regional or local e-government services requires a level of integration and interoperability between Member States that simply does not yet exist. This does not mean that this should not be a long-term goal of the pan-european Mobility Portal. However, at present the Member States should first focus on getting their own e-government back-end in order (so that they can indeed start building services at Level 4b of sophistication). Only when each Member State has a fully operational e-government back-end can we start with the construction of the pan-european e-government back-end that will be required for the Mobility Portal. 2 What should the pan-european Mobility Portal offer? 2.1 How does the portal user want to access information and services? The pan-european Mobility Portal pilot at present is essentially a sophisticated bookmark manager, offering a common navigational structure for citizens and enterprises based on the identification of around 30 to 40 common sub-topics, where each sub-topic contains a number of hyperlinks to the appropriate web sites at both the EU and the Member State level. In addition to these referrals to web sites, introductory texts are placed at each sub-topic, in order to properly introduce the hyperlinks. Although undoubtedly useful, this approach still offers little added value for the EU citizen or enterprise using the Mobility Portal. An EU citizen or enterprise faced with a particular cross-border question (e.g. I am a French citizen and I want to find out more about working in Germany or I am a Greek company and I want to apply in Germany for an export refund for my products ) still has to go and search for the correct information or the appropriate service all by himself, without any real help or guidance from the portal. Essentially, the portal user is looking for an answer to 2 types of questions: I want information on I want to which means he either simply wants to find the correct information, before deciding that he will perform a particular cross-border activity, or he wants to get direct access to the appropriate e-government service that will allow him to perform that particular cross-border activity. When looking for an answer to these 2 types of questions the user wants more however than just a list of hyperlinks to web sites at both the EU and the Member State level. He wants to know what to read first (or what to do first), what to read next (or what to do next), and he wants the portal to guide him during this process I want information on Initially, the portal user simply wants to find useful information, before deciding that he will perform a particular cross-border activity. But he wants more than just a bunch of hyperlinks to web sites with lots of hopefully relevant information. He wants to get the correct information, from the correct sites, sequenced in the correct order. E.g. dealing with the question I am a French citizen and I want to find out more about working in Germany, the portal should first refer him to a French site highlighting the issues to consider when moving from France to another country and should then refer him to a German site highlighting the issues to consider when entering Germany from another Member State. Page 5 of 25

6 2.1.2 I want to... Afterwards, the portal user simply wants access to the appropriate e-government service that will allow him to perform a particular cross-border activity. But he again wants more than just a bunch of links to web sites where he can find this e-government service amongst other, irrelevant services. He wants to access the appropriate e-government services, from the correct sites, sequenced in the correct order. E.g. dealing with the question I am a Greek company and I want to apply in Germany for an export refund for my products, the portal should first refer him to a Greek site where he can apply on-line for an export license, should then refer him to a German site where he can apply on-line for an export license and should finally refer him to a German site where he can apply on-line for a tax refund Examples of task-oriented portals The above examples illustrate that the Mobility Portal user is really looking for a task-oriented access ( I want ) to e-government information and services. A number of existing, successful US portals (see e.g. Figure 1) are already organized along a task-oriented access model. These portals still work with the familiar notion of life events/business episodes (at the level of citizens and enterprises) as the principal means of organizing their content, but inside each life event/business episode the user gets a clear and well-structured answer on how to fulfil a particular need for information or service access. Figure 1. Mass.gov, the portal of the Commonwealth of Massachusetts, which provides task-oriented access to e-government information and services ( Page 6 of 25

7 2.2 How can task-oriented access to information and services be provided? Offering a task-oriented access to pan-european e-government information and services requires a different architecture for the Mobility Portal than the one we have now. In their discussion document Proposition for the implementation of a pan-european Mobility Portal, the French delegation has suggested a very interesting new architecture for the portal that would allow EU citizens and enterprises to find the correct pan-european e-government information and services they need, based on their personal case and their personal plans. Their architecture involves building a Middle Office for the portal, that will use a Unified Data Model consisting of Elementary Information Blocks. These Information Blocks point to information or a service provided by an e-government site (maintained by a Member State or the EU Administration), so that a user, by going through the correct sequence of Information Blocks, can find the necessary e-government information and access the appropriate services to perform a particular cross-border activity. Determining the correct sequence of Information Blocks would be done by taking into account the user s profile (nationality, age, spoken language, marital status, ) and the user s information/service needs (regarding a situation the user is in, e.g. unemployed and living in France, or the transition the user wants to go through, e.g. moving from France to Germany to find work). These Information Blocks would be provided by the Member States, but would be managed by the EU Commission and be made available through the Mobility Portal. This idea of dynamically guiding the user through the information and services accessible via the Mobility Portal, based on their personal case and their personal plans, is not entirely new. In the CSC study Preliminary Study for the Implementation of a Portal for the EU Administration the study s authors already suggested using an answer wizard, where the user by answering a sequence of questions would be offered a checklist of information to read and services to use in order to perform a particular cross-border activity (e.g. go and work in another EU country, see Figure 2). Figure 2. Answer wizard, helping the user in finding the information to read and services to use in order to go and work in another EU member state. Page 7 of 25

8 But how can we provide this functionality of dynamically guiding the user through the information and services accessible via the Mobility Portal, based on his personal case and his personal plans? The French approach is certainly a very promising and novel approach, but it requires a degree of integration and interoperability between the e-government back-ends of the different Member States that, quite frankly, doesn t yet exist. It should however be possible to build an architecture that will allow us to evolve in incremental steps towards the goal of providing task-oriented access to pan-european e- government information and services, based on the user s personal case and his personal plans. I believe a new architecture should start from the idea of building a portal site which simply refers to the correct e-government information and the appropriate e-government services, but this pointing to (referral) should gradually become more task-oriented, going from the static listing of sites we have now in the portal towards a static task-oriented listing and finally a dynamic task-oriented listing Static listing At present, the Mobility Portal simply offers a list of hyperlinks to e-government information and services offered by a Member State, using a common navigational structure for citizens and enterprises based on the identification of common sub-topics. This list is static in the sense that the list of hyperlinks which is offered to the user is not adapted to the user s personal case or his personal plans, but is just a list of links pointing to information or services in the Member State which are probably useful for the user (Figure 3). The user still has to go to each of these sites, searching for the correct information or the appropriate service all by himself, without any guidance from the portal. The only added value offered by the portal is that the user can find in one single place hyperlinks to all the Member States sites which are potentially relevant to perform a particular cross-border activity, and the fact that this list of hyperlinks is typically accompanied by a small introductory text in his own spoken language. Figure 3. A static listing of hyperlinks to e-government information and services. Page 8 of 25

9 2.2.2 Static task-oriented listing In order to improve the usefulness of the portal, instead of simply referring to e-government information and services offered by a Member State, without telling the user what to do first and why, the portal should offer the user a script, telling him exactly what he has to read and what he has to do in order to perform particular cross-border activity. E.g. if the user is a French citizen and wants to find out more about working in Germany, the portal should offer him a script telling him step by step which German sites to visit to find out more about the challenges involved. Or e.g. if the user is from a Greek company and wants to apply in Germany for an export refund for his products, the portal should offer him a script telling him step by step which German sites with information to visit, and which German e- government services to use. The list of hyperlinks to e-government information and services offered by the portal is then still static, but is now task-oriented, since the user is now clearly told what to do first and why. The list of hyperlinks shown to the user is still not fully adapted to the user s personal case or his personal plans, but the user at least gets a far better idea of what to do first and why he has to do it (Figure 4). The script itself, and the short texts accompanying each of the steps in the script, should be available in the spoken language of the user, and the information or service being pointed to should be accessible in the native language of the Member State and at least 1 other official EU language. Figure 4. A static task-oriented listing of hyperlinks to e-government information and services, in the shape of a script, i.e. a sequence of steps the user has to follow in order to perform a particular cross-border activity. Note that such a static task-oriented listing (of the e-government information and services which are relevant for a particular cross-border activity) does not require that the underlying services be already fully integrated. The e-government services can still be stand-alone services, possibly requiring the Page 9 of 25

10 user to re-enter the same data over and over again. What is important however is that the user can now easily find out exactly which services he has to use and in what order. When an EU citizen or enterprise uses such a static task-oriented portal, the sites being pointed to in a script have to provide a landing page for the user (Figure 5). The portal cannot simply point the user to an external web site and drop him off at the home page of that external web site, leaving the user to find the rest by himself. The portal should point the user to a specific page on the external site, a landing page which is specifically written to welcome the user coming from the Mobility Portal and which contains information or services relevant to the task the user is trying to accomplish. E.g. this page could describe the range of information available at the web site, or could describe how to use the transactional e-government application offered by the web site. This landing page should be provided in the native language of the Member State and at least 1 other official EU language. It is up to the Member State to decide whether any further pages beyond this landing page are also offered in this other official EU language. E.g. a German site, welcoming a French user, can limit itself to providing a landing page describing in French how to use a particular e-government service offered at that site, or it can go through the additional effort of translating all of the pages of that service into French. It is clear that such additional translations would require a considerable amount of effort. Figure 5. A static task-oriented listing of hyperlinks to e-government information and services. When the user jumps to one of the web sites being pointed to, he arrives at a landing page, i.e. a page in the native language of the Member State and at least 1 other official EU language. As a Member State makes further progress in integrating the e-government services that it offers, it will become possible to combine some of the steps in the script into one single step (Figure 6). E.g. the user from the Greek company first has to apply on-line for an import license at a German web site and then has apply on-line for a tax refund at another German web site, typically having to re-enter the Page 10 of 25

11 same company data since the two sites are not yet integrated. However, when the two German e- government services do get integrated into one single service, the Greek company will have to enter its company data only once. The corresponding script on the portal can then be simplified, since what used to take two distinct steps can now be done in one single joined-up step. This means that as more and more e-government services inside a Member State get integrated, on the Mobility Portal the scripts that deal with the e-government services of that Member State will gradually become simpler. Figure 6. A static task-oriented listing of hyperlinks to e-government information and services, where two of the services have been integrated inside the Member State, resulting in a script which now has one step less than before. Some cross-border activities, particularly those where an activity has to be performed in which two (or even more) Member States are involved, will result in a script where steps have to be performed in two different Member States. In this case, the script will consist of a task-oriented listing of hyperlinks to e- government information and services inside two different Member States (Figure 7). Again the script itself, and the short texts accompanying each of the steps in the script, should be available in the spoken language of the user, and the information or service being pointed to should be accessible in the native language of the Member State and at least 1 other official EU language. Page 11 of 25

12 Figure 7. A static task-oriented listing of hyperlinks to e-government information and services, this time involving information and services which are offered by two Member States, resulting in a script which consists of steps to be undertaken in two different Member States. Note again that such a static task-oriented listing (of the e-government information and services in two different Member States which are relevant for a particular cross-border activity) does not require that the underlying services be already fully integrated. The e-government services can still be stand-alone services, possibly requiring the user to re-enter the same data over and over again. What is important however is that the user can now easily find out exactly which services in two different Member States he has to use and in what order. As the two Member States make progress in integrating the e-government services that they offer, it will become possible to combine some of the steps in the script into one single step (Figure 8). The corresponding script can then be simplified, since what used to take two distinct steps can now be done in one single joined-up step. This means that as e-government services between two Member States get integrated, on the Mobility Portal the scripts that deal with the e-government services in those Member States will gradually become simpler. Page 12 of 25

13 Figure 8. A static task-oriented listing of hyperlinks to e-government information and services, where two of the services have been integrated across two Member States, resulting in a script which now has one step less than before. It is clear that developing such cross-border integrated e-government services will require a very high degree of integration and interoperability between the e-government back-ends of the two Member States. Each of the Member States will have to be at Level 4b of sophistication (i.e. multi-integration transaction ), and both Member States will have to adhere to an interoperability framework for pan- European e-government services. Defining such an interoperability framework for pan-european e- government services (consisting of data exchange standards, application integration guidelines, jointly agreed upon service level agreements, etc.) will be the major challenge for the next IDA programme. Fortunately, a lot of very useful groundwork has already been done in Europe by e.g. France ( Cadre Commun d'interopérabilité ), Germany ( Standards und Architekturen für egovernment Anwendungen ) and the UK ( e-government Interoperability Framework ), and outside Europe by e.g. the USA ( Federal Enterprise Architecture Framework ) and Australia ( Interoperability Framework for the Commonwealth Government ). We should re-use and combine as much as possible these established interoperability frameworks, an effort that is already being done now as part of the IST project egov - An Integrated platform for Realising Online One-Stop Government (IST ). Page 13 of 25

14 2.2.3 Dynamic task-oriented listing In order to make the portal even more useful, the script (telling the user exactly what to read and what to do in order to perform particular cross-border activity) should take into account the user s profile (nationality, age, spoken language, marital status, ) and the user s information/service needs (regarding a situation the user is in, or the transition the user wants to go through). This means that the script should be dynamic, i.e. the precise steps in the script, and the precise sequence of those steps should depend upon the user s profile and the user s information/service needs (Figure 9). E.g. if the user is a Spanish university student, single mother with a child who wants to go and study in Italy, the script should include steps for applying for child support in Spain, for finding Italian universities that offer child care, and finally for applying for enrolment in courses at such an Italian university, etc. In order to be able to dynamically build such a script, consisting of the steps that are appropriate with respect to the user s profile and his information/service needs, the portal will have to be capable of determining who the user is and what his needs are. By asking the user a number of simple questions (e.g. What is your age? What is your marital status? What is your country of residence? Etc.) the backend of the portal should be capable of selecting the appropriate script steps from a library of generic pre-defined steps, and sequencing them in the correct order to build the correct script. The generated script itself, and the short texts accompanying each of the steps in the generated script, should be available in the spoken language of the user, and the information or service being pointed to should be accessible in the native language of the Member State and at least 1 other official EU language. Figure 9. A dynamic task-oriented listing of hyperlinks to e-government information and services, in the shape of a generated script, i.e. a sequence of steps the user has to follow in order to perform a particular cross-border activity, which is adapted to the user s profile and needs. Page 14 of 25

15 The same script will consist of very different steps, arranged in a different sequence, when another user with a different profile and different information/service needs accesses the same I want page on the Mobility Portal (Figure 10). By adapting each script to the user, based on his personal case and his personal plans, the portal should be able to dynamically guide the user through the rich offer of e-government information and services accessible via the Mobility Portal, Figure 10. The same generated script as in Figure 9, only this time a number of steps are no longer shown since they are not relevant with respect to the user s profile and his information/service needs. Note again that such a dynamic task-oriented listing (of the e-government information and services which are relevant for a particular cross-border activity) still does not require that the underlying services be already fully integrated. The e-government services can still be stand-alone services, possibly requiring the user to re-enter the same data over and over again. What is important however is that the user is now shown precisely which services he has to use and in what order, fully adapted to his profile and his information/service needs. There is one big difference with the scripts used in the static task-oriented listing however: the script steps must be defined in such a generic way that they can be re-used in different scripts, adapted to the user s profile and his information/service needs, i.e. the steps have to be able to be sequenced together into different scripts. A script step will have to contain additional meta-information that will allow a back-end reasoning engine to select the appropriate steps, and sequence them in the appropriate order, in order to generate on-the-fly a script that will perfectly satisfy the requirements of the user s profile and his information/service needs. When an EU citizen or enterprise uses such a dynamic task-oriented portal, the sites being pointed to in a script now have to provide several landing pages for the user (Figure 11). Instead of having one single landing page, adapted to the needs of a generic user arriving at the external site, ideally the Page 15 of 25

16 external site should offer several landing pages whose content is perfectly adapted to the incoming user s profile and his information/service needs. E.g. when landing at an external job offer site, the landing page offered to the user should be different depending on whether he is an unemployed student, an unemployed mother, an employed professional looking for another job, etc. These different landing pages should be provided in the native language of the Member State and at least 1 other official EU language. It is again up to the Member State to decide whether any further pages beyond these landing pages are also offered in this other official EU language. It is clear that such additional translations would require a considerable amount of effort. Figure 11. A dynamic task-oriented listing of hyperlinks to e-government information and services. When the user jumps to one of the web sites being pointed to, he arrives at a specific landing page, i.e. a landing page adapted to the user s profile and his information/service needs, written in the native language of the Member State and at least 1 other official EU language. As a Member State makes further progress in integrating the e-government services that it offers, it will again become possible to combine some of the steps into one single step (Figure 12). The dynamically generated scripts using those steps can then be simplified, since what used to take two distinct steps can now be done in one single joined-up step. This again means that as more and more e-government services inside a Member State get integrated, on the Mobility Portal the scripts that deal with the e-government services of that Member State will gradually become simpler. Page 16 of 25

17 Figure 12. A dynamic task-oriented listing of hyperlinks to e-government information and services, where two of the services have been integrated inside the Member State, resulting in a generated script which now has one step less than before. Some cross-border activities, particularly those where an activity has to be performed in which two (or even more) Member States are involved, will result in a generated script where steps have to be performed in two different Member States. In this case, the generated script will consist of a taskoriented listing of hyperlinks to e-government information and services inside two different Member States (Figure 13). Again the generated script itself, and the short texts accompanying each of the steps in the script, should be available in the spoken language of the user, and the information or service being pointed to should be accessible in the native language of the Member State and at least 1 other official EU language. Page 17 of 25

18 Figure 13. A dynamic task-oriented listing of hyperlinks to e-government information and services, this time involving information and services which are offered by two Member States, resulting in a generated script which consists of steps to be undertaken in two different Member States. Note again that such a dynamic task-oriented listing (of the e-government information and services in two different Member States which are relevant for a particular cross-border activity) still does not require that the underlying services be already fully integrated. The e-government services can still be stand-alone services, possibly requiring the user to re-enter the same data over and over again. What is important however is that the user is now shown precisely which services in two different Member States he has to use and in what order, fully adapted to his profile and his information/service needs. As the two Member States make progress in integrating the e-government services that they offer, it will again become possible to combine some of the steps into one single step (Figure 14). The dynamically generated scripts using those steps can then be simplified, since what used to take two distinct steps can now be done in one single joined-up step. This again means that as e-government services between two Member States get integrated, on the Mobility Portal the scripts that deal with the e-government services in those Member States will gradually become simpler. Page 18 of 25

19 Figure 14. A dynamic task-oriented listing of hyperlinks to e-government information and services, where two of the services have been integrated across two Member States, resulting in a generated script which now has one step less than before. It is again clear that developing such cross-border integrated e-government services will require a very high degree of integration and interoperability between the e-government back-ends of the two Member States. Each of the Member States will have to be at Level 4b of sophistication (i.e. multiintegration transaction ), and both Member States will have to adhere to an interoperability framework for pan-european e-government services. As I have already written above, defining such an interoperability framework for pan-european e-government services (consisting of data exchange standards, application integration guidelines, jointly agreed upon service level agreements, etc.) will be the major challenge for the next IDA programme. Page 19 of 25

20 3 What are the next steps for the pan-european Mobility Portal? As outlined in the Commission strategy document The strategy for the implementation of the Portal of the EU Administration - V.2.1, it is crucial that the user of the Mobility Portal user gets guidance on how to make use of the information and services available through the portal: it is important that links to these sites are properly introduced and that the user receives all information she/he needs to understand the basics of the administration of the Member State she/he is interested in. I hope to have shown above that by offering a task-oriented access to information and services, in a first phase by offering a static task-oriented listing, and in a later phase by offering a dynamic task-oriented listing, we can achieve these goals. The question is then: What does the EU Commission need to do and what do the MSs need to do to move from the present pilot portal to the desired task-oriented portal? 3.1 Phase 1: from static listing to static task-oriented listing In a first phase we should re-use as much as possible the work that has already been done in building the present pilot of the Mobility Portal. We can continue using the present common navigational structure for citizens and enterprises based on the identification of common life events/business episodes. Moving from a static listing of links to a static task-oriented listing of links requires however that what is shown underneath each event is quite different from what is shown now. Instead of just showing links to sites, we will have to determine for each event what are the typical cross-border tasks a user wants to perform, and for each of these tasks we will have to define a script, i.e. an outline of the different steps the user has to take (the information he has to read, the services he has to use) in order to accomplish that task. E.g. when the user wants to find employment in Iceland, instead of just pointing him to some relevant sites in Iceland, the user should get an overview of the different tasks he will need to perform ( Get a work permit, Contact the Icelandic employment service, Get a residence permit, etc.) and for each of these tasks he should get a short script, consisting of steps telling what information to read and what e-government services to use (if any are available). This means we will have the following structure for the content offered by the task-oriented Mobility Portal: Country E.g. Life events/business episodes Iceland Tasks Get a job Steps to achieve that task Get a work permit go read information at site X go use e-government service at site Y Contact the Icelandic employment service Find a place to live Page 20 of 25

21 In order to organize the content offered by the task-oriented Mobility Portal in the way described above we will have to determine what are the cross-border life events/business episodes that the user is most interested in, and for each of these cross-border life events/business episodes what are the tasks that the user is most interested in. Hopefully, the ex-ante evaluation will provide us with elements of prioritisation for the selection of cross-border life events/business episodes. In the Commission strategy document The strategy for the implementation of the Portal of the EU Administration - V.2.1 a number of criteria are already defined to determine whether an information/service is of relevant cross-border dimension. However, it is clear that there will a large number of potentially interesting life events/business episodes that can be covered by the task-oriented Mobility Portal. These relevant cross-border life events/business episodes will be of two types: 1. involving one Member State: a Member State citizen/enterprise who wants to find out, in his own language, how to do something in another Member State that only requires the use of information/services from that same Member State citizen/business of MS X, wanting to do something in MS Y involving only MS Y e.g. I am a German citizen already living in France, who wants to find a job in France 2. involving two Member States: a Member State citizen/enterprise who wants to find out, in his own language, how to do something in another Member State that requires the use of information/services from his own Member State and from that other Member State citizen/business of MS X, wanting to do something in MS Y involving both MS X and MS Y e.g. I am a German citizen still living in Germany, but I want to leave Germany and find a job in France There will be a very large number of such cross-border life events/business episodes, each with their own associated tasks to accomplish, and it is clear that it will be impossible to cover all cross-border life events/business episodes for all possible combinations of two Member States X and Y. It will be up to each Member State to decide which cross-border life event/business episode it wants to cover first, and for which other involved Member States first. E.g. if a Member State decides that it is most interested in getting Dutch and French workers to come and work, it will want to support the crossborder life events Getting a job and Finding a place to live first, and in these life events it will provide information and services for Dutch and French citizens first, in their native Dutch and French language. To conclude, the Member States can decide, together with the EU Commission, what will be the priority cross-border life events/business episodes, but is up to each Member State to decide with which other Member States they want to work together first in actually providing that cross-border service. The Mobility Portal will have to make very clear to its users that not all cross-border services are provided for all possible combinations of two Member States, but only for a selected subset of combinations of two Member States. The ultimate long-term goal should of course be to provide crossborder service coverage for the whole of the EU, but initially this will clearly have to be limited What does the EU Commission need to do? The EU Commission has to do the following: Identify the list of priority cross-border activities: using the results of the ex-ante evaluation, the EU Commission should specify, in concertation with the Member States, what are the priority cross-border activities that should be covered in a task-oriented manner, i.e. what are the priority life events/business episodes that need to be covered by the Mobility Portal, and what are the priority tasks inside each of these priority life events/business episodes that need to be covered Page 21 of 25

22 Translate the scripts and the steps in each script: as the Member States define the scripts to perform a particular task for a life event/business episode, and write the texts accompanying the different steps in each script, the EU Commission will have to translate each finalised script into the other official EU languages. The scripts can then be made available through the Mobility Portal. The EU Commission is only responsible for the accurate translation of the text of the scripts, it is not responsible for the correctness of the scripts, nor is it responsible for the correctness of the Member States external web sites that these scripts are pointing to What do the Member States need to do? Each participating Member State has to do the following: Implement some priority cross-border activities: using the list of priority cross-border activities as defined by the EU Commission, the Member States have to decide which cross-border activities they want to implement first. If such a cross-border activity only involves the Member State itself, no further co-ordination is required, if such a cross-border activity involves another Member State, the two Member States will have to co-ordinate that efforts, possibly under the supervision of the EU Commission. The number of steps in such a cross-border activity will depend on the level of integration of the information and services involved. If there is little integration, a lot of steps will possibly be involved. It is up to the Member State(s) involved to decide whether they want to integrate their e-government services before offering them through the portal. However, when they decide to do so they must use the standards and approaches as will be defined in the interoperability framework for pan-european e-government services. Doing so will make it easier for other Member States to integrate with these same e-government services when these other Member States are ready to do so. Define the scripts and provide the landing pages: for those cross-border activities that the Member State has decided to implement, the Member State has to define the scripts (outlining the different steps in the script and writing the texts briefly describing each of these steps) and has to develop the landing pages at the different external web sites participating in those scripts. This is a major effort, which will require a continuous, permanent follow-up by the Member State(s) involved 3.2 Phase 2: from static task-oriented listing to dynamic task-oriented listing In a second phase, when enough static scripts have been defined in the Mobility Portal, we can move towards a dynamic task-oriented portal. This can be done by analysing the static scripts, to see which script steps are occurring frequently enough to be considered generic, re-usable script steps. We can also analyse which script steps need to be further refined to better take into account the user s profile and his information/service needs. By defining a sufficiently simple (but still useful) model of the user s profile and his information/service needs (e.g. by only considering very broadly defined user characteristics such as nationality, age, spoken language, marital status, ), we can find out how we have to adapt the scripts to satisfy each different profile, and how we have to point to different pages on the external web sites depending on each different profile. Once we have enough re-usable script steps, adapted to the user s profile, we can generate dynamic scripts using those script steps. In order to be able to do this, the Mobility Portal will no longer offer static pages, but will offer dynamic pages, consisting of the appropriate scripts generated in response to what the portal knows about the user s profile. Determining the user s profile will be done by asking the user a number of simple questions whenever he visits the portal (e.g. What is your nationality?, What is your age?, ). The answers to these questions will not be permanently stored by the Mobility Portal, nor will they be linked in any Page 22 of 25

23 uniquely identifying way to the user of the portal. In this way it will be possible to avoid tricky privacy issues. If the user does need to uniquely identify himself, to be able to access information or use services provided by one of the external web sites of the Member States, it will be the responsibility of that external web site to take care of the privacy issues involved. The Mobility Portal itself is only a doorway to these external web sites, it does not (yet) handle cross-border identification issues What does the EU Commission need to do? The EU Commission has to do the following: Define a model of the user s profile: the EU Commission has to decide what will be the defining characteristics of the user that can be used to build a simple model of the user s profile and his information/service needs. The big challenge here will be to build a model that is rich enough to capture the real needs of the user, and at the same time is simple enough to be easily used in order to control the generation of dynamic scripts. Make the script steps more generic: by analysing the wide range of scripts available in the static task-oriented version of the portal, the EU Commission can define more generic script steps that can be re-used in dynamically generated scripts. Each generic script step will have to come in different versions (with a different accompanying text, and pointing to a different landing page at an external web site), so that it can be adapted to the user s profile and his information/service needs, and can be combined in different ways into different scripts Develop and make available a script engine: the Mobility Portal will need to have a script engine, i.e. an intelligent engine capable of generating dynamic scripts by combining the appropriate script steps from a library of generic script steps. By asking the user a number of simple questions, the script engine will have to be able to determine the user s profile, select the appropriate steps to accomplish a particular task with respect to a life event/business episode, and sequence those steps in the correct order to build a complete, user-adapted script What do the Member States need to do? Each participating Member State has to do the following: Make the script steps adapted to the user: when the EU Commission has defined the generic script steps, and has defined the characteristics of the user that will be taken into account to determine the user s profile and his information/service needs, the EU Commission can tell the Member States how existing script steps need to be refined in order to better adapt to the user, or how additional script steps need to be defined in order to service users which are not yet serviced. It is up to the Member States to decide whether they want to make this additional effort, and if so, for which particular class of users (only for young users? female users?, etc.). If they don t want to make this additional effort, the Mobility Portal will continue offering the same scripts as before, but they will of course not be adapted to the user s profile and his information/service needs. Make the landing pages adapted to the user: adapting the information and services offered by the Mobility Portal to the user s profile and his information/service needs not only involves the dynamic generation of appropriate scripts, it also involves providing appropriate landing pages at the external web sites being pointed to by these scripts. This means Member States will have to develop landing pages at those external web sites that are adapted to the profile of the incoming user. It is again up to the Member States to decide whether they want to make this additional effort, and if so, for which particular class of users (only for young users? female users?, etc.). Page 23 of 25