LoopbaanApp Rijk. Haalbaarheidsonderzoek. In opdracht van: Versie 1.0

LoopbaanApp Rijk Haalbaarheidsonderzoek

In opdracht van:

Versie Status Datum

1.0 definitief 27 juni 2013

Management samenvatting In opdracht van het ministerie van BZK heeft ICTU een haalbaarheidsonderzoek uitgevoerd naar de ontwikkeling van een mobiele loopbaanapp voor het Rijk. Centraal stond de vraag of het haalbaar is om bestaande mobiliteitsinformatie van de Rijksoverheid via een mobiele applicatie (‘App’) op een smartphone of tablet aan te bieden. De haalbaarheid is getoetst aan de hand van een drietal scenario’s voor de positionering van één of meer Apps. De scenario’s zijn bepaald aan de hand van: (1) beschikbare content; (2) technische mogelijkheden voor het ontsluiten van die content in een App; (3) behoeften bij contentaanbieders en (4) de mate waarin met die content een aantrekkelijk App kan worden geboden. De drie scenario’s zijn: - Scenario 1 - mobiele vacature site voor Rijksmedewerkers - Scenario 2 - Vacature Alert App voor Rijksmedewerkers - Scenario 3 – HRM-App portfolio met Vacature Alert App als eerste stap Aan de hand van deze 3 scenario ‘s zijn de eisen en randvoorwaarden voor het ontwikkelen en aanbieden van een mobiele site of App in kaart gebracht. Gekeken is naar techniek, grafische user interface, distributie, samenwerkingspartners, beheer en kosten. De conclusie is dat het prima mogelijk is om vacatureen stageinformatie uit de mobiliteitsbank voor Rijksmedewerkers te ontsluiten via een mobiele website of een App. De meerwaarde van zo’n App ten opzichte van een doorontwikkelde mobiele website is te vinden in de mogelijkheden van het gebruik van Push messaging om de doelgroep te wijzen op mogelijk interessante vacatures. Het zwaartepunt van zo’n App zou dan ook bij de persoonlijke alert functie moeten liggen. Voor het raadplegen van gedetailleerde informatie uit het gehele CSO platform (Carrière Sites Overheid Platform ) en de mogelijkheid om te solliciteren valt de gebruiker dan in eerste instantie terug op de daarvoor bestaande kanalen. In vervolgtrajecten kan dan bekeken worden welke onderdelen daarvan eveneens in App vorm aangeboden kunnen worden in aanvulling op de Vacature Alert App. In de aanbevelingen worden twee mogelijkheden geschetst om invulling te geven aan de doorvertaling van (delen van) het CSO platform naar mobiel: 1. Ontwikkel een mobiele site waarmee de toegang tot vacatures uit de mobiliteitsbank wordt verbeterd (scenario 1). Dit kan snel en met een relatief beperkte investering. Het is een doorontwikkeling en aanvulling op reeds de bestaande mobiele websites m.werkenvoornederland.nl en m.werkenbijdeoverheid.nl. 2. Ontwikkel een App met een Vacature Alert als eerste stap in de ontwikkeling van een HRM-App portfolio (scenario 3). Met de pushfunctionaliteit van een App kunnen vacatures beter onder de aandacht gebracht worden van Rijksmedewerkers. Er is echter (nog) geen duidelijke business case voor een App met alléén vacature-informatie. Daarom adviseren we deze eenvoudige ‘alert-App’ voor vacatures te ontwikkelen als onderdeel van een breder traject om loopbaaninformatie mobiel te ontsluiten voor Rijksmedewerkers. De App met een vacature-alert is dan geen doel op zich, maar een eerste stap in de richting van een breder aanbod aan loopbaan Apps. Hiermee wordt een nieuw (mobiel) kanaal

20130627_Haalbaarheid_Loopbaanapp_Rijk_v1 def

2 van 33

gepresenteerd richting de doelgroep en start een ontwikkeling om hier verder invulling aan te geven door middel van een HRM-App portfolio. Scenario 2 wordt niet aanbevolen. Hierin wordt een Vacature Alert App voor Rijksmedewerkers gerealiseerd zonder parallel daaraan een strategie te ontwikkelen voor verdere doorontwikkeling. Uit de gesprekken die zijn gevoerd in het kader van dit onderzoek komt geen duidelijke business case naar voren komt voor een App met alléén vacature-informatie. Om een Vacature Alert App als zelfstandig project uit te voeren, zou ons inziens eerst een business case gevonden moeten worden.


3 van 33

Inhoudsopgave Management samenvatting ........................................................................................................... 2 1. Documenthistorie.................................................................................................................... 5 2. Opdracht................................................................................................................................. 6 2.1. Achtergrond ..................................................................................................................... 6 2.2. Scope............................................................................................................................... 6 2.3. Vraagstelling .................................................................................................................... 6 3. Aanpak ................................................................................................................................... 7 4. Positionering ........................................................................................................................... 7 4.1. Beschikbare mobiliteitsinformatie ..................................................................................... 8 4.2. Behoeften bij aanbieders van mobiliteitsinformatie ......................................................... 10 4.3. Technische mogelijkheden en beperkingen.................................................................... 10 4.4. Wat maakt een App aantrekkelijk voor eindgebruikers? ................................................. 11 4.5. Scenario’s voor een App met mobiliteitsinfo van het Rijk ............................................... 12 5. Eisen en randvoorwaarden ................................................................................................... 15 5.1. Techniek ........................................................................................................................ 15 5.2. Grafische user interface ................................................................................................. 19 5.3. Distributie ....................................................................................................................... 20 5.4. Beheer ........................................................................................................................... 22 5.5. Samenwerkingspartners................................................................................................. 22 5.6. Budgetindicatie .............................................................................................................. 23 5.7. Samenvatting ................................................................................................................. 24 6. Conclusies en aanbevelingen ............................................................................................... 26 Bijlage 1: Richtlijnen voor Apps ................................................................................................... 27 Bijlage 2: Input voor roadmap ...................................................................................................... 29 Bijlage 3: Lijst van geïnterviewden .............................................................................................. 32 Bijlage 4: Lijst van afkortingen ..................................................................................................... 33


4 van 33

1. Documenthistorie Versie 0.1 0.2 0.3 0.4 0.5 0.8 0.9 1.0

Datum

Status concept concept concept Concept Concept Concept Concept Definitief

Auteur Paul Francissen Paul Francissen Paul Francissen Paul Francissen Paul Francissen Paul Francissen Paul Francissen Paul Francissen


5 van 33

Opmerkingen Initiële versie Aanvullingen o.b.v. gesprek Ronald en Erik. Verwerking input Ronald, Erik, Paul Verwerking input Ronald, Erik, Bastiaan Verwerking input Ronald Ter bespreking met BZK Verwerking input uit het overleg met BZK Verwerking na laatste review

2. Opdracht In opdracht van het ministerie van BZK heeft ICTU een haalbaarheidsonderzoek uitgevoerd naar de ontwikkeling van een mobiele loopbaanapp voor het Rijk.

2.1. Achtergrond Aanleiding voor het onderzoek is dat bestaande tools en instrumenten van het Rijk op het terrein van loopbaanbegeleiding nog niet altijd de doelgroep bereiken. Tegelijkertijd ontvangen de doelgroepen veel informatie via mobiele applicaties op smartphones of tablets. Het ministerie van BZK heeft daarom laten onderzoeken of het haalbaar is om deze tools en instrumenten ook te ontsluiten via (een) mobiele applicatie(s). Dit onderzoek maakt onderdeel uit van de werkgeversprojecten die gefinancierd worden door het A+O fonds Rijk in het kader van “Van werk naar werk & Arbeidsmarkt”.

2.2. Scope De scope van dit onderzoek beperkt zich tot bestaande mobiliteitsinformatie van de Rijksoverheid die momenteel beschikbaar is voor rijksambtenaren en/of externe kandidaten. Het gaat daarbij om mobiliteitsinformatie die aangeboden wordt via de volgende tools en instrumenten (zie voor een volledig overzicht schema 1 op pagina 9): • Mobiliteitsbank.nl en werkenvoornederland.nl (CSO-platform) • Project Digitaal Transparante Arbeidsmarkt1 • Loopbaaninformatie op het Rijkstalentencentrum (CSO-platform) • Instrumenten van het A+O fonds Rijk • Informatie op het Rijksportaal

2.3. Vraagstelling Centrale vraagstelling van dit onderzoek is: Is het haalbaar om (een deel van) de bestaande mobiliteitsinformatie van de Rijksoverheid via (een) mobiele applicatie(s) op een smartphone of tablet aan te bieden? Deelvragen: 1. Doelstelling; Wat zijn mogelijke doelstellingen om bestaande mobiliteitsinformatie aan te bieden via een mobiele App? 2. Concept; Per doelstelling is gekeken naar mogelijke ingrediënten voor het concept teneinde de doelstelling te behalen. 3. Distributie; Hoe kunnen de verschillende doelgroepen bereikt worden met een App?

1

Dit project is opgegaan in het project TOP (tijdelijke opdrachten project) binnen het bestaande CSO platform


6 van 33

4. Technische eisen en voorwaarden; Welke technische eisen en randvoorwaarden worden gesteld aan een loopbaanapp voor het Rijk? 5. Eisen aan aansluiting bij werkenvoornederland.nl en mobiliteitsbank.nl; Hoe kan een App aansluiten op de site van werkenvoornederland.nl 6. Eisen aan design; Welke eisen worden gesteld aan de look en feel? En aan welke gebruikersrichtlijnen moet worden voldaan? 7. Omgevingsanalyse; Welke partners binnen het Rijk dienen betrokken te worden en welke partijen kunnen als content leverancier worden beschouwd 8. Kosten; Wat is een indicatie van de kosten van de ontwikkeling van een App (gezien de verschillende scenario’s)? Welke kosten kunnen jaarlijks terugkomen? 9. Beheer; Welke vormen van beheer worden onderscheiden en welke partij(en) zouden dit op zich kunnen nemen?

3. Aanpak Het onderzoek is opgesplitst in 3 onderdelen, die in de volgende hoofdstukken worden uitgewerkt: 1. Positionering Er is een drietal scenario’s ontwikkeld m.b.t. de positionering van één of meer mobiele apps. De drie scenario’s zijn ontstaan door te kijken naar informatie die potentieel ontsloten kan worden, doelgroepen, distributie, beoogd effect en overheidsrol. Dit is gedaan aan de hand van: • desk research waarbij onderzocht is welke informatie aangeboden wordt via de bestaande instrumenten en aan welke doelgroepen; • interviews met: A+O fonds Rijk, ECO&P, Aanbodplatform Mobiliteit, ICTU (zie bijlage 3 voor een overzicht van de geïnterviewden). 2. Eisen en randvoorwaarden De eisen en randvoorwaarden voor een mobiele App met mobiliteitsinformatie van het Rijk zijn in kaart gebracht, aan de hand van de scenario’s uit onderdeel 1. Hierbij is gekeken naar techniek, user interface, distributie, beheer, samenwerkingspartners en kosten. Dit is gedaan door: • interviews met SSC-ICT (RijksAppStore), ICTU, Rhinofly, ECO&P; • afstemming met de beheerders van de afzonderlijke loopbaaninstrumenten over de specificaties van de koppelvlakken; • bureau-expertise op het terrein van App ontwikkeling en beheer. 3. Advies voor vervolg Er is een advies opgesteld voor het ontwikkelen van een mobiele App.

4. Positionering De bestaande mobiliteitsinformatie (‘content’) van het Rijk kan op diverse manieren ontsloten worden via een mobiele App. Om de haalbaarheid te kunnen onderzoeken is een drietal


7 van 33

scenario’s ontwikkeld m.b.t. de positionering een dergelijke App. Daarbij is gekeken naar de volgende aspecten: 1. Content (binnen de bestaande mobiliteitsinstrumenten van het Rijk) die geschikt is voor een mobiele App (zie 4.1). 2. Technische mogelijkheden en beperkingen om die content te ontsluiten t.b.v een mobiele App (zie 4.3). 3. Behoeften en wensen bij aanbieders van mobiliteitscontent als het gaat om inzet van een mobiele App (zie 4.2 en bijlage 3voor een overzicht van de geïnterviewden). 4. Wat maakt een App aantrekkelijk voor eindgebruikers? (zie 4.4). Deze aspecten komen aan de orde in de paragrafen hierna. In paragraaf 4.5 zijn de scenario’s geschetst voor het aanbieden van een mobiele App met mobiliteitsinformatie van het Rijk. In het vervolg van het rapport wordt gekeken naar de haalbaarheid van deze drie scenario’s.

4.1.

Beschikbare mobiliteitsinformatie

Er is een quick scan uitgevoerd naar de belangrijkste mobiliteitscontent van het Rijk die beschikbaar is binnen de bestaande omgevingen/instrumenten. De uitkomsten zijn weergeven in het schema op de volgende pagina (niet uitputtend). Statisch karakter Wat opvalt is dat de meeste content een statisch karakter heeft; het wordt niet met grote regelmaat (dagelijks) vernieuwd. Uitzonderingen zijn vacatures, stages, nieuws- en agendafeeds en blogs. Voor een gebruiker van een mobiele App is juist dynamische content interessant (zie bijlage 1). Content elders Het schema beperkt zich tot content die binnen de scope valt van dit onderzoek valt. Uit gesprekken en desk-research in het kader van dit onderzoek is ook andere content naar voren gekomen die relevant kan zijn voor een mobiele App met mobiliteitsinformatie van het Rijk: - content m.b.t. tijdelijk werk (‘klussen’). Hiervan is geen inventarisatie gemaakt. Door het dynamische karakter is deze informatie bij uitstek geschikt voor een App; - P-Directportaal: SAP-portaal voor online aanvragen en registreren van personele zaken door medewerkers.


8 van 33

Schema 1 - Bestaande mobiliteitsinformatie van het Rijk (niet uitputtend) Bestaande mobiliteitsinformatie van het Rijk vacatures

Wat is het?

Doelgroepen

stages

Overzicht van afstudeerstages bij de Rijksoverheid.

Overzicht van alle vacatures van de medewerkers rijk, verschillende Rijksoverheid extern organisaties. Je kunt de vacatures filteren op vakgebied, niveau en regio. Vacaturezoekprofiel aanmaken.

Kanalen

Statisch/ dynamisch

www.werkenvoornederland.nl Dynamisch www.werkenbijdeoverheid.nl mobi.rijkstalentencentrum.nl m.werkenbijdeoverheid.nl m.werkenvoornederland.nl

medewerkers rijk, www.werkenvoornederland.nl Dynamisch extern www.werkenbijdeoverheid.nl mobi.rijkstalentencentrum.nl inschrijven rijkstraineeTekstuele uitleg over het programma. medewerkers rijk, www.werkenvoornederland.nl Statisch programma Tussen 2 en 15 april mogelijkheid om extern in te schrijven via de site (momenteel niet actief). persoonlijk dossier Ontvang vacatures op maat en medewerkers rijk, www.werkenvoornederland.nl Statisch verzamel alle gegevens die je nodig extern www.werkenbijdeoverheid.nl hebt om snel en doelgericht te mobi.rijkstalentencentrum.nl solliciteren. fgr.rijkstalentencentrum.nl informatie voor starters en Artikels gericht op starters en medewerkers rijk, www.werkenvoornederland.nl Statisch professionals professionals extern beschrijving van werkgevers Korte beschrijving van organisaties. In medewerkers rijk, www.werkenvoornederland.nl Statisch beeld hoeveel vacatures er zijn per extern rtc.rijkstalentencentrum.nl organisatie beschrijving arbeidsartikels met arbeidsvoorwaarden medewerkers rijk, www.werkenvoornederland.nl Statisch voorwaarden extern rtc.rijkstalentencentrum.nl agenda en nieuws van interne nieuwsfeed (rss), nieuwsoverzicht, medewerkers rijk mobi.rijkstalentencentrum.nl/ Dynamisch vacaturebank eventoverzicht (weinig actueel) blog mogelijkheid om blog te schrijven, medewerkers rijk www.werkenvoornederland.nl Dynamisch blogs op werken voor nederland mobi.rijkstalentencentrum.nl/ aanvraag scholingsubsidie uitleg + aanvraagformulier voor medewerkers rijk www.blikvooruit.aofondsrijk.nl Statisch scholingssubsidie voor rijksmedewerkers aanvraag loopbaanadvies uitleg + aanvraagformulier voor medewerkers rijk www.loopbaanadvies.aofondsri Statisch loopbaanadvies jk.nl ondersteuning loopbaanprofiel ondersteuning bij maken van medewerkers rijk rtc.rijkstalentencentrum.nl Statisch loopbaanprofiel (tests, spellen, oefeningen, artikels) loopbaan-begeleiding artikels over loopbaanbegeileiding medewerkers rijk rtc.rijkstalentencentrum.nl Statisch vanuit het rijk opstellen loopbaanplan ondersteuning bij opstellen van een medewerkers rijk rtc.rijkstalentencentrum.nl Statisch loopbaanplan (tests, artikels) functiegebouw rijksoverheid inzicht in functies binnen het rijk medewerkers rijk rtc.rijkstalentencentrum.nl Statisch (resultaten, functioneringsgesprek, loopbaanstappen, beschikbare vacature, salarisniveaus vergelijken) informatie van A&O Fonds rijk artikels met informatie van/over A&O medewerkers rijk, www.aofondsrijk.nl Statisch fonds rijk (subsidies, nieuws, agenda, extern thema-informatie, links) app (in ontwikkeling) van A&O app (in ontwikkeling) ter medewerkers rijk nog niet beschikbaar Dynamisch? Fonds rijk ondersteuning van het voeren van functioneringsgesprekken (voorbereidingstips, agenda, animaties, begeleiding bij het voeren van het gesprek). personeelsinformatie artikels met informatie over medewerkers rijk portal.rp.rijksweb.nl Statisch rijksportaal (muv p-direct) dienstverband, financien, aan-en afwezigheid, functie en loopbaan, gezondheid en veiligheid, inspraak, etc.


9 van 33

4.2.

Behoeften bij aanbieders van mobiliteitsinformatie

Uit gesprekken met aanbieders van mobiliteitsinformatie blijkt dat er interesse bestaat in een App als extra kanaal voor het ontsluiten van mobiliteitsinformatie. In de gesprekken komen vele ideeën naar voren voor mogelijke functionaliteiten. Echter, voor een op korte termijn te realiseren App zijn de ambities beperkt. Geen nieuwe content en functionaliteiten Er is op korte termijn geen wens/behoefte om nieuwe content en/of functionaliteiten te ontwikkelen ten behoeve van een App. Liever wil men uitgaan van wat er op dit moment aangeboden wordt via de bestaande kanalen van het rijk. Uitgaan van bestaande processen De nadrukkelijke wens bestaat om op korte termijn geen nieuwe werkprocessen te introduceren of bestaande processen aan te passen. Focus intern rijk Bij de geïnterviewden is behoefte om te starten met doelgroepen binnen het rijk. Dit impliceert in eerste instantie geen App gericht op externe informatie. Geen business case Uit de gesprekken komt geen input voor een business case naar voren in de zin van dat kosten en baten al bekend zijn. De toegevoegde waarde van het aanbieden van vacatures via een mobiele App zou zijn dat vacatures naar medewerkers gepusht kunnen worden.

4.3.

Technische mogelijkheden en beperkingen

Het aanbieden van bestaande mobiliteitsinformatie in een mobiele App vergt een technische koppeling tussen de bestaande omgevingen en het mobiele platform. De belangrijkste omgeving voor mobiliteitsinformatie van het Rijk en gerelateerde vacatures en stages is het CSO-platform (Carrière Sites Overheid). Dit platform omvat een centrale vacatureen stagedatabase, onderhoudssoftware, gebruikersinformatie en een aantal websites die doelgroep gerichte vacatures tonen. De vacature database bevat zowel interne vacatures, herplaatsers, interdepartementale vacatures en (binnenkort) tijdelijke opdrachten cq. klussen. Deze omgeving wordt beheerd en onderhouden door Rhinofly. Het CSO-platform ‘voedt’ meerdere kanalen, waaronder: - mobiliteitsbank (mobi.rijkstalentencentrum.nl) - werkenbijdeoverheid (www.werkenbijdeoverheid.nl - werkenvoornederland (www.werkenvoornederland.nl - rijkstalentencentrum (rtc.rijkstalentencentrum.nl) - functiegebouwrijk (fgr.rijkstalentencentrum.nl)


10 van 33

- m.werkenbijdeoverheid.nl (mobiele website) - m.werkenvoornederland.nl (mobiele website)

Beschikbare koppelvlakken Het CSO-platform biedt webservices voor derde partijen (waaronder marktpartijen) om vacatureinformatie op te halen en op een externe site te tonen. Voor andere gerelateerde informatie en/of processen zijn dergelijke koppelvlakken (nog) niet beschikbaar. Dit betekent dat vacatureinformatie relatief eenvoudig aangeroepen kan worden in een mobiele App. Om andere informatie te ontsluiten zijn extra inspanningen nodig. De vacature en stage database wordt ontsloten via SOAP gebaseerde webservices. In principe kunnen deze services ook al gebruikt worden door mobiele toepassingen. SOAP services zijn echter niet ideaal voor de prestaties van mobiele apparaten. Rhinofly werkt aan de omzetting van deze SOAP services naar een JSON/REST gebaseerde interface, waardoor de vacature informatie beter bruikbaar is voor mobiele toepassingen. Toegangsbeveiliging De beschikbare services zijn momenteel alleen geschikt voor het tonen van openbare vacatures. Voor toegang tot vacatures die alleen beschikbaar zijn voor overheidsmedewerkers moeten er voorziening getroffen worden om de identiteit en departement van deze medewerkers te valideren. Op de websites kan dit al, op basis van Departement en SAP personeelsnummer. Voor mobiele toepassingen moet hiervoor een koppelvlak functie toegevoegd worden. Mobiele websites en mobiele applicaties De vacature-informatie uit het CSO-platform wordt ontsloten via twee mobiele websites (m.werkenvoornederland.nl en m.werkenbijdeoverheid.nl). Er zijn nog geen mobiele apps waarmee informatie wordt aangeboden.

4.4.

Wat maakt een App aantrekkelijk voor eindgebruikers?

Het aanbieden van mobiliteitsinformatie via een App stelt de gebruiker in staat om die informatie onderweg en thuis te raadplegen. Vermoedelijk zal het zwaartepunt bij een smartphone App liggen op gebruik in het openbaar vervoer of tijdens ‘ten minutes to kill’ tijdens het werk. Een tablet App zal vooral thuis op de bank gebruikt worden. Om meerwaarde te bieden aan de eindgebruiker, is het van belang dat de juiste informatie op de juiste manier wordt aangeboden in een App. Statische informatie is over het algemeen niet erg geschikt voor mobiele apps, terwijl dynamische informatie dat wel is. Daarnaast is actualiteit van belang. In bijlage 1 zijn tien richtlijnen uitgewerkt voor ‘aantrekkelijke’ apps, te weten: 1. Houd rekening met de context van de gebruiker 2. Maak de App persoonlijk 3. Houd rekening met het gebruik van diensten via meerdere kanalen en gebruik het ‘input once’ principe.


11 van 33

4. Wees dynamisch 5. Wees actueel 6. Zorg voor een ‘snappy’ ervaring 7. Maak het delen van informatie en statussen zeer laagdrempelig 8. Respecteer privacy 9. Blijf ‘top of mind’ 10. Update de App regelmatig Een App die laag scoort op bovenstaande punten zal doorgaans minder aantrekkelijk zijn voor de eindgebruiker. Specifiek lijkt in dit geval de meerwaarde van een App ten opzichte van een mobiele site te vinden in het feit dat een App push messaging mogelijk maakt. Daarmee kan het initiatief voor de interactie tussen aanbieder (het Rijk) en App gebruiker bij de aanbieder gelegd worden. Elke installatie van een App levert een blijvende relatie op, die mede door de aanbieder geactiveerd kan worden. Het web biedt deze mogelijkheden op zichzelf niet. Uiteraard bestaat op het web weer de mogelijkheid tot het aanbieden van een nieuwsbrief via e-mail, maar de attentiewaarde daarvan is veel kleiner dan die van push messaging.

4.5.

Scenario’s voor een App met mobiliteitsinfo van het Rijk

Om te komen tot een drietal scenario’s voor een App waarvan de haalbaarheid kan worden getoetst, zijn de aspecten uit de voorgaande paragrafen afgezet tegen de beschikbare mobiliteitsinformatie van het Rijk. De uitkomsten zijn weergeven in het schema hierna.


12 van 33

Schema 2 – Welke mobiliteitsinformatie is het meest geschikt voor een mobiele App?

Bestaande mobiliteitsinformatie van het Rijk vacatures stages inschrijven rijkstraineeprogramma persoonlijk dossier informatie voor starters en professionals beschrijving van werkgevers beschrijving arbeidsvoorwaarden agenda en nieuws van interne vacaturebank blog aanvraag scholingsubsidie aanvraag loopbaanadvies ondersteuning loopbaanprofiel loopbaan-begeleiding opstellen loopbaanplan functiegebouw rijksoverheid informatie van A&O Fonds rijk app (in ontwikkeling) van A&O Fonds rijk personeelsinformatie rijksportaal (muv p-direct)

Technische mogelijkheden t.b.v. app + +

Aantrekkelijkheid voor eindgebruikers van app? +/+/-

Vergt het ontwikkeling nieuwe functionaliteit Overall score t.b.v. app? nee + nee +

-

-

ja

-

-

+/-

ja

-

-

-

nee

-

-

-

nee

-

-

-

nee

-

-

-

ja

-

? ?

+/+/+/0 ?

ja ja ja ja nee ja ja nee ?

?

?

-

?

-

Geconcludeerd kan worden dat de vacatureen stage-informatie uit het CSO-platform geschikt is voor een mobiele App; de overige informatie is minder geschikt. Waarom vacatureen stage-informatie? De vacatureen stage informatie kan technisch gezien redelijk eenvoudig worden ontsloten via de bestaande koppelvlakken van het CSO-platform. Wel moet er een voorziening worden getroffen om de identiteit van de Rijksmedewerkers te kunnen vaststellen. Bovendien is de vacatureen stage-informatie relatief aantrekkelijk voor eindgebruikers omdat het dynamische informatie is, die men verwacht in een App. Tenslotte, voor het aanbieden van vacature-en stage-informatie in een App hoeft geen nieuwe functionaliteit te worden ontwikkeld. Kanttekening daarbij is dat een alerten pushfunctie een App wel aantrekkelijker maken. Daarvoor dient een voorziening te worden ontwikkeld. Verdere overwegingen Bij het bepalen van de scenario’s voor een mobiele App is verder een aantal overwegingen relevant: - De externe vacatures en stages zijn beschikbaar als ‘open data’. Het betreffende CSOkoppelvlak is open voor partijen die daarmee zelf mobiele apps willen ontwikkelen. Men dient hiervoor wel vooraf contact op te nemen met ECO&P.


13 van 33

-

-

-

De externe vacatures zijn reeds ontsloten via mobiele websites. Zonder extra content/functionaliteiten voegt een mobiele App inhoudelijk weinig toe voor de eindgebruiker. De aanbieders van mobiliteitsinformatie hebben de voorkeur om een mobiele App in eerste instantie te richten op de doelgroep Rijksmedewerkers. Dit betekent dat de focus komt te liggen op vacatures die getoond worden in de mobiliteitsbank. Uit de gevoerde gesprekken komt naar voren dat het niet de voorkeur heeft om -op korte termijn- nieuwe functionaliteiten te ontwikkelen t.b.v. een mobiele App.

Scenario’s voor een App Op basis van het voorgaande zijn hieronder 3 scenario’s weergegeven voor het ontwikkelen van een mobiele website/App met vacature-informatie en eventueel stage-informatie. Scenario 1 – Mobiele vacature site voor Rijksmedewerkers Een mobiele website met vacatures uit de mobiliteitsbank. Dit is een ‘low cost’ optie om de informatie beschikbaar te krijgen op een smartphone of tablet. De vacatures uit de mobiliteitsbank kunnen worden ontsloten via een mobiele website, vergelijkbaar met m.werkenvoornederland.nl en m.werkenbijdeoverheid.nl. De mobiele website biedt toegang tot bestaande functionaliteiten, geen nieuwe functionaliteiten. Doelgroep zijn medewerkers binnen het Rijk. Let wel: in dit scenario wordt dus geen App ontwikkeld maar een mobiele website (te raadplegen via een browser op een smartphone of tablet). In dit scenario is het hoofddoel om de vacatures uit de mobiliteitsbank mobiel toegankelijk te maken voor Rijksmedewerkers. Scenario 2 – Vacature Alert App voor Rijksmedewerkers In dit scenario wordt een eenvoudige App ontwikkeld voor smartphones2 waarmee Rijksmedewerkers geattendeerd worden op nieuwe vacatures, in eerste instantie uit de mobiliteitsbank (later wellicht ook uit andere bronnen wanneer deze geïntegreerd zijn met het CSO-platform). Het raadplegen en opvolgen van vacatures kan gebeuren via bestaande kanalen. Centraal staat een persoonlijke alertfunctie op basis van push messaging. Hiermee kunnen medewerkers van het Rijk gericht worden geïnformeerd over nieuwe vacatures, stages en in de toekomst mogelijk ook klussen. Dit vergroot de attentiewaarde van mobiliteitsinformatie. Voor het inzien van gedetailleerde vacatureen aanvullende informatie en het opvolgen daarvan wordt dan vanuit de App verwezen naar de bestaande kanalen. Dit scenario is primair gericht op het mobiel aanbieden van vacatures uit de mobiliteitsbank. Het laat de mogelijkheid open voor verdere doorontwikkeling richting een breder aanbod aan HRMapps, maar hiervoor wordt geen strategie ontwikkeld; of en hoe doorontwikkeling plaatsvindt, kan later bekeken worden. Scenario 3 – HRM-App portfolio, met Vacature Alert App als eerste stap In dit scenario wordt dezelfde App ontwikkeld als in scenario 2, maar met een ander doel; namelijk om te komen tot een HRM-App portfolio dat in de toekomst naast vacatures ook andere informatie en functionaliteiten gaat bieden. In dit scenario is het ontwikkelen van een portfolio 2

De keuze om de App in eerste intstantie te ontwikkelen voor smartphones, en niet voor tablets, heeft te maken met mobiel gebruik in het openbaar vervoer.


14 van 33

even belangrijk als het ontwikkelen van een eerste App (Vacature Alert). De eerste App kan gepositioneerd worden als de eerste stap in de ontwikkeling van een nieuw HRM-App portfolio. De beoogde doelgroep voor de korte termijn zijn de Rijksmedewerkers, maar op langere termijn is het denkbaar dat de HRM-Apps ook (deels) toegankelijk worden voor externen. Daarbij kan de ambitie zijn om dit in de komende jaren verder uit te bouwen. Samen met partners kan een roadmap voor een HRM-App porfolio ontwikkeld worden en een releaseplanning.

5. Eisen en randvoorwaarden Aan de hand van de drie hiervoor geschetste scenario’s zijn de eisen en randvoorwaarden voor het ontwikkelen en aanbieden van een App in kaart gebracht. Voor de afzonderlijke scenario’s is gekeken naar eisen en randvoorwaarden ten aanzien van: - Techniek; - Grafische user interface; - Distributie; - Beheer; - Samenwerkingspartners; - Kosten.

5.1.

Techniek

Eisen en richtlijnen vanuit het rijk Voor zover bekend zijn er vanuit het Rijk geen technische eisen en richtlijnen voor Apps. Er zijn ook geen eisen en richtlijnen bekend ten aanzien van te ondersteunen operating systemen. Op mobiele websites (Scenario 1) zijn de Webrichtlijnen van toepassing (zie paragraaf 6.2). Operating systemen Een complicerende factor bij het ontwikkelen van Apps is dat de te ontwikkelen dienst moet werken op verschillende operating systemen (OS) van mobiele platformen (smartphones, tablets) en versies daarvan. Bij mobiele websites (scenario 1) is dit geen issue omdat deze gebruikt maakt van de webbrowser van mobiele apparaten. Met Android en iOS kan een groot deel van de particuliere gebruikers bereikt worden. Recente cijfers van Gartner laten zien dat het marktaandeel van Android en iOS op dit moment samen ongeveer 95% bedraagt. Binnen het Rijk kan deze verhouding anders liggen omdat Blackberry de standaard is bij sommige departementen. Ontwikkeling voor Blackberry (OS6 of 7) brengt extra kosten met zich mee door de fragmentatie van verschijningsvormen binnen het OS en de hoeveelheid testwerk die dat met zich meebrengt. Elk OS heeft een eigen set richtlijnen waar ontwikkelaars zich aan behoren te houden. Het verschilt per platform hoe streng de eisen gehandhaafd worden. Bijvoorbeeld Apple heeft een strenge toelatingsprocedure voor de App store, terwijl Android de App ontwikkelaar vrij laat. Over het algemeen stelt een OS eisen en richtlijnen op een aantal gebieden: - gebruikers ervaring (look & feel); - gebruik van processor en bandbreedte;


15 van 33

-

beveiliging; gebruik van beeld en video.

Hardware Naast diverse operating systemen moet een App werken op een grote verscheidenheid aan devices met verschillende input- en output mogelijkheden en sensoren (van een klein liggend scherm met fysieke toetsen tot een groot staand scherm met slechts virtuele toetsen). De hardware kan per mobiel apparaat nogal verschillen. Elke App moet in staat zijn de mogelijkheden van een toestel te ondersteunen, anders kan de App niet voor een bepaald type toestel geïnstalleerd worden. Bij mobiele websites (scenario 1) is dit minder een issue omdat deze gebruikt maakt van de (veel meer gestandaardiseerde) webbrowser van mobiele apparaten. Ontwikkelplatform Bij het ontwikkelen en aanbieden van een mobiele applicatie is van belang te bepalen of er een opzichzelfstaande App wordt ontwikkeld of er een platform wordt opgezet dat meerdere apps (voor meerdere operating systemen) ondersteunt. Er bestaan diverse strategieën voor het ontwikkelen van apps (zoals Native, multiplatform, hybride, HTML5). In het schema hieronder worden de verschillende strategieën toegelicht. De mobiele markt is versnipperd in diverse operating systemen, apparaten en schermgroottes en –oriëntaties. Ook nu Android en iOS samen gezamenlijk 95% marktaandeel hebben blijft de ontwikkeling van een App voor iedere combinatie van bovenstaande factoren kostbaar en slecht onderhoudbaar. Wanneer de wens bestaat om meerdere operating systemen (OS) te ondersteunen en ook om verschillende schermgroottes te adresseren, is het te overwegen om naar een platform-oplossing te kijken als alternatief voor native ontwikkeling voor elk OS en scherm.


16 van 33

Schema 3 - Strategieën voor het ontwikkelen van apps Native

Multi platform

Hybride

HTML5

De App wordt ontwikkeld in de standaard programmeertaal van het OS; voor elk ondersteund OS wordt een aparte App gemaakt + geeft meestal de beste gebruikers-ervaring en prestaties + mogelijkheid te profiteren van distributie via App stores + mogelijkheid gericht te distribueren binnen een selecte doelgroep hoge kosten voor ontwikkeling en onderhoud De App wordt ontwikkeld in een OS onafhankelijke taal, waarna hieruit per OS een App wordt gegenereerd + kennis van slechts 1 ontwikkelomgeving noodzakelijk + mogelijkheid te profiteren van distributie via App stores + mogelijkheid gericht te distribueren binnen een selecte doelgroep + kostenbesparing in het onderhoud, want wijzigingen hoeven maar 1 maal doorgevoerd te worden Raadzaam om van gebruik van OS specifieke features af te zien De schermen voor de App worden in HTML5/CSS ontwikkeld, en de programmacode in Javascript. Via een generator wordt er per OS een App gegenereerd + kennis van HTML5/CSS/Javascript breed beschikbaar + kostenbesparing in het onderhoud, want wijzigingen hoeven maar 1 maal doorgevoerd te worden + mogelijkheid te profiteren van distributie via App stores + mogelijkheid gericht te distribueren binnen een selecte doelgroep relatief veel meer inspanning nodig om de look & feel voor elk OS te optimaliseren problemen met performance te verwachten verspreiding via de betrokken App stores noodzakelijk (behalve bij Android) De schermen voor de App worden in HTML5/CSS ontwikkeld, en de programmacode in Javascript. De web App wordt uitgevoerd in de browser van het mobiele apparaat; + in principe is de App hiermee op elk mobiel platform beschikbaar dat HTML5 ondersteunt + In dit geval kan functionaliteit gebouwd worden voor het herkennen van het browsertype, zodat standaard de juiste versie van de site op het juiste apparaat getoond wordt (WebApp op mobiel, volledige site op PC). Daarbij is het raadzaam wel cross links tussen de sites aan te brengen zodat de gebruiker eventueel handmatig over kan schakelen naar een andere vorm indien gewenst. + kostenbesparing in het onderhoud, want wijzigingen hoeven maar 1 maal doorgevoerd te worden + kennis van HTML5/CSS/Javascript breed beschikbaar relatief veel meer inspanning nodig om de look & feel voor elk platform te optimaliseren sterke beperkingen in toegang tot apparaat specifieke functies (camera, GPS etc) problemen met performance en off-line gedrag te verwachten geen verspreiding via de App stores, waardoor de App moeilijker gevonden wordt

Het is op voorhand moeilijk een optimale strategie te bepalen. De beste keus hangt af van de kosten, de gewenste verspreiding, beveiligingseisen, toekomstige uitbreidingen etc. Een business case voor een specifiek te ontwikkelen toepassing is draagt bij om richting te geven in deze keuze. Als de scope van een te ontwikkelen App beperkt is tot de Vacature Alert App kan mogelijk gebruik gemaakt worden van een Hybride oplossing. Voor uitgebreidere functionaliteit schiet deze oplossing nog vaak te kort en resulteert het gebruik ervan al gauw in een mindere of onacceptabele gebruikservaring.


17 van 33

Gebruik RijksAppStore De RijksAppStore is ontwikkeld door SSC-ICT Den Haag, het Shared Service Centre ICT voor de rijksoverheid. Hierin werken momenteel 4 departementen samen aan ontwikkeling en beheer van ICT-faciliteiten. Daarnaast is het SSC-ICT dienstverlener voor Rijksbrede diensten. De AppStore is naar verwachting eind 2013 beschikbaar voor de vier aangesloten departementen. De RijksAppStore kan een rol spelen bij de beschikbaarstelling en bij de beveiliging van een mobiele App voor Rijksmedewerkers: • Er moet vastgesteld worden door de ontwikkelaar van een App of deze toegankelijk is voor het publiek (evt. met inlog) of dat de App alleen beschikbaar is voor medewerkers van de betorkken departementen. De RijksAppStore kan vervolgens verwijzingen naar de App in een publieke App store bevatten, of de App zelf kan in de RijksAppStore opgenomen zijn. In het laatste geval is de App niet toegankelijk voor het publiek. • Bij gebruik van de strikte beveiliging van de RijksAppStore (eg. dataprotectie) moet de App samenwerken met de beveiligingssoftware die op een apparaat geladen moet zijn (de zogenaamde container). In dat geval kan de data beheerd worden vanuit de RijksAppStore, en eventueel zelfs gewist worden. Op dit moment is niet bekend wat de kosten zijn voor opname in en distributie via de RijksAppStore. Toegangsbeveiliging De vacatures op de mobiliteitsbank zitten nu achter een inlog. Deze inlog kan in een App gerealiseerd worden via een JSON/REST functie in het CSO koppelvlak. Hiermee kan de App de inloggegevens van de gebruiker laten controleren door het CSO. Deze functie is op dit moment niet beschikbaar en moet toegevoegd worden. Dit geldt ook wanneer een mobiele website wordt ontwikkeld. Voorinstallatie Een App kan desgewenst voorgeïnstalleerd worden op mobiele apparaten van het Rijk (smartphones en tablets). Voor het gebruik van persoonlijke apparaten naast die van het Rijk (Bring Your Own Device en distributie buiten de medewerkers van het Rijk) is dan nog steeds distributie via een App store of een andere route noodzakelijk. Voorinstallatie brengt voor de aanbieder veel logistiek en organisatie met zich mee en voor de gebruiker beperkte voordelen. Het installeren van een App is voor de gebruiker namelijk zeer eenvoudig. Dit wordt dus niet aangeraden, tenzij het doel is distributie uitsluitend op devices van het Rijk toe te staan en geheel in handen van de aanbieder te houden. Dat zou bij de ontwikkeling van een HRM App portfolio waarin ook meer vertrouwelijke informatie ontsloten wordt het geval kunnen zijn. In dat geval is het raadzaam om Mobile Device Management (MDM) software te overwegen als dat niet al in gebruik is. Met deze software is het mogelijk Apps op afstand te installeren, te beheren en te verwijderen. Daarnaast is het bijvoorbeeld mogelijk de inhoud van een apparaat op afstand te wissen bij verlies of diefstal, zodat persoonlijke gegevens niet in handen van derden vallen. Back-office Wanneer bestaande vacature-informatie wordt aangeboden in een mobiele applicatie, stelt dit vrijwel gelijke eisen aan een back-office als de huidige websites. Er moet vlot op gebruikers


18 van 33

vragen en sollicitaties gereageerd worden, zodat aan de 24/7 verwachtingen tegemoet gekomen wordt. Als de App ook redactionele content of push messaging bevat, zal voor de publicatie daarvan een proces ingericht moeten worden. Ook dit is goed in deeltijd te combineren met het functioneel beheer van het CSO Web/App portfolio. Het technisch beheer van de App blijft beperkt tot versie management en het uitbrengen van noodzakelijke updates bij wijzigingen van het OS of bugfixes. Deze kleine aanpassingen kunnen het best afgedekt worden in een SLA met de App leverancier. Koppeling aan werkenvoornederland.nl en mobiliteitsbank Via het bestaande koppelvlak van het CSO-platform is het mogelijk om de vacatureen stageinformatie die momenteel getoond worden op werkenvoornederland.nl en de mobiliteitsbank, te ontsluiten in een mobiele App via een bestaand API. Zoals toegelicht in paragraaf 5.3 vergt dit nog wel enige doorontwikkeling: - De bestaande SOAP services zijn niet ideaal voor de prestaties van mobiele apparaten. Rhinofly werkt aan de omzetting van deze SOAP services naar een JSON/REST gebaseerde interface, waardoor de vacature informatie beter bruikbaar is voor mobiele toepassingen. Rhinofly verwacht de JSON interface na de zomer op te leveren. - De beschikbare services zijn momenteel alleen geschikt voor het tonen van openbare vacatures. Voor toegang tot vacatures die alleen beschikbaar zijn voor overheidsmedewerkers moeten er voorziening getroffen worden om de identiteit en departement van deze medewerkers te valideren.

5.2.

Grafische user interface

Bij het ontwerp van de grafische user interface (GUI) van een mobiele applicatie vanuit het Rijk dient rekening gehouden te worden met eisen en richtlijnen vanuit de Rijkshuisstijl en met de Webrichtlijnen voor toegankelijkheid en bouwkwaliteit. Rijkshuisstijl De Rijkshuisstijl wordt breed toegepast voor communicatie-uitingen vanuit het Rijk. Dit draagt bij aan een herkenbare overheid. Het ligt voor de hand om in een mobiele website of een mobiele App de huisstijl toe te passen. In de bestaande mobiele website m.werkenvoornederland.nl is hier dan ook rekening mee gehouden. De wijze waarop dit is gedaan zou als uitgangspunt kunnen dienen voor het ontwerp van een mobiele App. Webrichtlijnen Wat betreft eisen en richtlijnen vanuit Webrichtlijnen/toegankelijkheid dient onderscheid gemaakt te worden naar mobiele websites en mobiele apps: - Mobiele websites: Bij het ontwikkelen van een mobiele website dient rekening gehouden te worden met de Webrichtlijnen. Deze stellen eisen aan het ontwerp, de bouw en het beheer van een (mobiele) website. Ze zijn gebaseerd op internationale standaarden voor kwaliteit en toegankelijkheid, en op in de praktijk beproefde oplossingen van professionals. De richtlijnen


19 van 33

-

dragen bij aan bouwkwaliteit en toegankelijkheid van een website. Dit zorgt er onder meer voor dat de websites goed werken op verschillende platformen en dat de sites toegankelijk zijn voor mensen met een functiebeperking. De richtlijnen worden toegelicht op www.webrichtlijnen.nl Mobiele apps: De Webrichtlijnen zijn niet van toepassing op mobiele applicaties. Hiervoor geldt echter wel dat toegankelijkheid zoveel mogelijk gewaarborgd dient te zijn. De webrichtlijnen kunnen daarbij het uitgangspunt vormen. Mobiele platformen (zoals Android en iOS) bieden mogelijkheden om de toegankelijkheid te vergroten. Zo maken veel slechtzienden en blinden gebruik van de iPhone omdat die goed toegankelijk is. De iPhone biedt voor mensen die blind zijn volledige spraak uitvoer waardoor alle tekst ook direct als synthetische spraak beschikbaar is. Die moet echter door de App wel goed worden aangestuurd. Hier dient rekening gehouden te worden bij het ontwerp van een mobiele App. De eisen die gesteld worden aan een mobiele App verschillen per platform. De organisatie Accessibility (erkende inspectie-instantie voor de Webrichtlijnen) biedt een AppsTest aan waarmee de toegankelijkheid van een mobiele applicatie kan worden getest (zii www.accessibility.nl/ inspecties/testen-van-mobiele-apps). Hier zijn kosten aan verbonden.

5.3.

Distributie

Deze paragraaf gaat in op de vraag hoe de verschillende doelgroepen bereikt kunnen worden. We besteden vooral aandacht aan het distribueren van een App (scenario’s 2 en 3). De distributie van een mobiele website (scenario 1) verloopt via eenvoudig via een browser in een smartphone of tablet en vergt geen bijzondere aandacht. De distributie van een mobiele App met mobiliteitsinformatie voor Rijksmedewerkers kan op twee manieren worden ingericht: - via publieke App stores - via interne distributie binnen het Rijk Beide mogelijkheden worden hieronder toegelicht. Publieke App stores De App kan gedistribueerd worden via bestaande, algemene en publieke App stores. Meestal zijn deze van de provider van het operating system (OS) van het apparaat waar de gebruiker de App op wil installeren. Zo is er de Apple App store voor iOS devices en en Google Play voor Android devices. In deze stores is het mogelijk een App te uploaden zodat deze aangeboden kan worden aan geïnteresseerden. De eindgebruiker moet inloggen in de betreffende App store, zodat deze een lijst van geïnstalleerde Apps kan bijhouden en de gebruiker kan attenderen op het verschijnen van updates van de App. Uploaden van een App in de store is gratis en er wordt basis management informatie verstrekt t.a.v. het aantal downloads. Bij Apple en Microsoft is een review door de App store onderdeel van het publicatieproces, maar er is geen aanleiding te denken dat een App met mobiliteitsinformatie daar geblokkeerd zou worden. Iedereen kan de App vinden en downloaden.


20 van 33

Interne distributie binnen het Rijk Het is ook mogelijk de App te distribueren in besloten kring, bijvoorbeeld binnen het Rijk of een departement. Dat is mogelijk gewenst bij een App die uitsluitend voor intern gebruik bedoeld is, ook al zijn er voldoende mogelijkheden om het gebruik van een App of delen er van na distributie middels een inlogprocedure voor te behouden aan een specifieke doelgroep. Distributie van Apps buiten de publieke store brengt enkele eisen met zich mee, maar is in principe onbeperkt mogelijk als daaraan eenmaal voldaan is. Er zijn drie mogelijkheden voor interne distributie: 1. E-mail 2. Website (+evt. e-mail) 3. RijksAppStore Ad 1) E-mail De meest eenvoudige manier van distribueren is dan via e-mail. De gebruiker ontvangt dan een bestandje (op zijn telefoon) dat hij kan installeren. Deze methode zou eventueel aangeboden kunnen worden vanaf het intranet zodat een gebruiker het bestand kan opvragen door zijn e-mail adres in te geven. Dit werkt echter niet op alle operating systemen gelijk en brengt naar verwachting veel druk op ondersteuning met zich mee. Ad 2) Website Een elegantere manier van distribueren gaat uit van een mobiele website vanwaar de App door het aanklikken van een link geïnstalleerd kan worden. Dit is gebruiksvriendelijker. De website kan eventueel zelf detecteren om welk type operating system het gaat, zodat het aanbod daarop gefilterd kan worden. Uiteraard is het mogelijk om de URL van deze pagina te distribueren via mail of het intranet. Ad 3) RijkAppStore Tot slot kan een uitgebreide eigen App store gebouwd worden, inclusief user management en monitoring van Apps. Toegang tot de App store of delen ervan kan dan voorbehouden worden aan specifieke doelgroepen. Dit is eigenlijk de uitgebreide variant van de voorgaande optie. De RijksAppStore zou hiervoor het aangewezen middel zijn (zie p. 15 hiervoor). Deze is ten tijde van het schrijven van dit document nog niet beschikbaar en een harde lanceerdatum is nog niet bekend. Als de verwachting is dat de App binnen afzienbare termijn voor intern gebruik via een interne App store aangeboden zal worden, dan ligt het niet voor de hand om de App eerst via de publieke App stores te verspreiden. Dit leidt tot verwarring op het moment dat de App niet meer beschikbaar is via de publieke App stores. Marketing In alle voorgaande gevallen is de inzet van goede marketing van belang om een hoge penetratiegraad te bereiken. Daarbij kan gedacht worden aan (niet uitputtend): • E-mail campagnes • Campagnes en permanente verwijzing op het intranet • Campagnes en permanente verwijzing op relevante websites van de overheid (inclusief mobiele sites!) • Campagnes op het internet (bij vacaturesites bijvoorbeeld) 20130627_Haalbaarheid_Loopbaanapp_Rijk_v1 def

21 van 33

•

Campagnes in traditionele media

Ook referral mogelijkheden vanuit de App kunnen mogelijk veel bijdragen aan een goede marketing in relevante doelgroepen. Zo kan een mogelijkheid geboden worden om een vacature of algemene link door te sturen naar een door de gebruiker in te geven e-mail adres zodat een andere gebruiker de vacature en een link om de App te downloaden krijgt.

5.4.

Beheer

Na ontwikkeling dient de App of de mobiele site in beheer te worden genomen. Deze paragraaf gaat in op vormen van beheer en het beleggen daarvan bij een beheerpartij. Vormen van beheer Er kunnen drie vormen van beheer worden onderscheiden: - Functioneel beheer: omvat alle beheertaken die nodig zijn voor het dagelijks gebruik van de App en/of mobiele website (bijv. toekennen van autorisaties, ondersteunen van gebruikers) en de onderliggende gegevensinfrastructuur en wijziging in de specificaties daarvan. - Applicatiebeheer: omvat beheer van de oorspronkelijke applicatieprogrammatuur of gegevensbankstructuren (bijvoorbeeld het oplossen van programmafouten, uitbreiding van functionaliteit of gegevens) - Technisch beheer: alle beheertaken die nodig zijn voor het accepteren, installeren en operationeel maken en houden van informatiesystemen en technische infrastructuren. Beleggen van beheer Omdat het CSO-platform de belangrijkste leverancier is van gegevens voor een te ontwikkelen App en een groot deel van de instrumenten omvat waarmee mobiliteitsinformatie van het Rijk wordt aangeboden, ligt het in de lijn om het beheer van een App en/of een mobiele site te beleggen bij de partij die dit platform beheert. Dit is Rhinofly in Utrecht. Deze organisatie voert het beheer uit in opdracht van ECOP. Mogelijk dat ECOP het functioneel beheer geheel of gedeeltelijk binnen de eigen organisatie kan/wil beleggen.

5.5.

Samenwerkingspartners

Welke partners binnen het Rijk dienen betrokken te worden en welke partijen kunnen als content leverancier worden beschouwd? Scenario 1 en 2 – mobiele vacature site/app In scenario’s 1 en 2 wordt vacatureen stagecontent ontsloten via een mobiele website of een App met behulp van een bestaand koppelvlak van het CSO-platform. Het gaat om bestaande content en er worden geen nieuwe functionaliteiten ontwikkeld. Realisatie kan daardoor plaatvinden via een 1-op-1 afspraak met de partij die het CSO-platform beheert (ECO&P). Mogelijk volstaat een uitbreiding van de bestaande opdracht voor ontwikkeling en beheer van het CSO-platform.


22 van 33

Voor de realisatie van een mobiele site/App -in aanvulling op het bestaande CSO-platform- zal ECO&P waarschijnlijk kennis en expertise betrekken bij een externe ontwikkelen beheerpartij. Indien dit past binnen de bestaande ontwikkelen beheerafspraken (bijv. met Rhinofly) en binnen de geldende aanbestedingsregels dan vergt selectie en aanbesteding relatief weinig tijd en kan snel gestart worden met het ontwikkeltraject. Scenario 3 – HRM-App Portfolio In scenario 3 wordt parallel aan de ontwikkeling van een App met een vacature alert gewerkt aan de ontwikkeling van een HRM-App portfolio. Voor de ontwikkeling van dit portfolio is brede afstemming binnen het Rijk vereist. De partijen die in het kader van dit onderzoek zijn geconsulteerd hebben aangegeven hierbij betrokken te willen zijn (zie bijlage 3). Daarnaast ligt het in de lijn om partijen te betrekken die actief zijn bij mobiliteitsinitiatieven die buiten de scope van dit onderzoek vallen, zoals: • initiatieven rond tijdelijk werk (zoals TOPBank, tooling van de verschillende interimpools, Flexbee, Flexpool); • Rijksbrede bemiddelaars (zoals I-Interim Rijk, InterimManagement Rijk, ABD); • departementale initiatieven; • P-Directportaal.

5.6.

Budgetindicatie

In dit stadium kan voor elk van de drie scenario’s slechts een ruwe schatting worden gegeven van het benodigde budget met een bandbreedte. In onderstaande tabel staan geschatte budgetten en doorlooptijden per scenario. Let wel: deze budgetindicaties zijn niet gebaseerd op kostenopgaven van leveranciers. Schema 4 – budgetindicaties en realisatietijd voor ontwikkeling en beheer van de App Scenario 1 Mobiele vacature site

Scenario 2 Vacature Alert App**

Budgetindicatie

10-20k€ ontwikkeling 10k€/jr beheer

Realisatietijd

1,5 mnd

50-150k€ ontwikkeling 10-30k€ /jr beheer* 0-12k/jr: Gebruik Push service*** 3 mnd

Scenario 3 HRM-App portfolio, met Vacature Alert App als eerste stap 50-150k€ ontwikkeling Vacature Alert App 10-30k€ /jr beheer* Vacature Alert App 50-80k€ begeleiding portfolio-ontwikkeling 6 mnd

*gebaseerd op rekenregel: jaarlijkse beheerkosten bedragen 20% van ontwikkelkosten **Er is bij scenario 2 en 3 uitgegaan van ontwikkeling van een smartphone App voor iOS en Android. Zijn Windows Phone of Blackberry (OS6 of 7) oververtegenwoordigd in de doelgroep dan moet rekening gehouden worden met een verhoging van de ontwikkelen beheerskosten met een factor 1,5 tot 2, mede door de fragmentatie van verschijningsvormen binnen het OS en de hoeveelheid testwerk die dat met zich meebrengt. *** Bij gebruik van een Multi OS Push oplossing hangen de kosten af van de gekozen oplossing. Er zijn flat fee services beschikbaar voor rond 500-1000 Euro per maand met ongelimiteerd gebruik. Bij gebruik van de native push services van OS aanbieders zijn er geen terugkerende kosten. De eenmalige integratiekosten zijn dan hoger.


23 van 33

5.7.

Samenvatting

Hieronder is voor de 3 scenario’s een samenvatting gegeven van kenmerken, technische eisen, GUI, distributie, beheer en kosten. Schema 5 – samenvatting Scenario 2: Smartphone App met vacatures uit mobiliteitsbank Bestaande vacatures mobiel ontsluiten (via App)

Doelgroep

Scenario 1: Mobiele website met vacatures uit mobiliteitsbank Bestaande vacatures mobiel ontsluiten (low cost) Rijksmedewerkers

Scope

-

-

Inloggen

-

Interesses aangeven Gerichte Pushberichten ontvangen o.b.v. interesses Vacatures doorzoeken (breedte / diepte n.t.b.) Vacatures kunnen opslaan in persoonlijk profiel

Doel

Uitgangspunten

Functionaliteiten

Bronnen

JSON/ REST implementatie van vacature API (buiten scope – lopend project) Realisatie van een externe inlog API op CSO Inlog mogelijkheid op mobiele website Tonen van intern beschikbare vacatures indien ingelogd Hergebruik van bestaande mobiele site, waarbij de vacatures uit de mobiliteitsbank achter een inlog worden geplaatst.

Bestaande functionaliteiten van het CSO-platform CSO-platform

Rijksmedewerkers

-

Gebruik van de bestaande vacature database, waarbij een inlog wordt gerealiseerd voor de App. Inclusief persoonlijke alert service bij nieuwe vacatures. Er wordt geen andere content ontsloten. Bestaande functionaliteiten van het CSO-platform CSO-platform

Koppelvlakken

SOAP-services. JSON/REST interface is in ontwikkeling

SOAP-services. JSON/REST interface is in ontwikkeling

Distributie Operating system Platform Beveiliging

n.v.t. n.v.t.

Nader te bepalen Android en iOS

n.v.t. Toevoegen JSON/REST

Nader te bepalen Toevoegen JSON/REST


24 van 33

Scenario 3: Roadmap voor LoopbaanApp van het rijk e

Ontwikkeling LoopbaanApp met als 1 stap bestaande vacatures mobiel ontsluiten (via App) e 1 stap: Rijksmedewerkers Vervolgstappen: afhankelijk van keuzes in roadmap Scenario 2 + roadmap ontwikkeling

Idem scenario 2. Daarnaast wordt een traject gestart om een portfolio te ontwikkelen.

e

1 stap: Bestaande functionaliteiten van het CSO-platform. Vervolgstappen: afhankelijk van keuzes in roadmap e 1 stap: CSO-platform Vervolgstappen: afh. van keuzes in roadmap e 1 stap: SOAP-services. JSON/REST interface is in ontwikkeling. Vervolgstappen: afh. van keuzes in roadmap Nader te bepalen Toevoegen JSON/REST functie in CSOkoppelvlak Nader te bepalen e 1 Stap: Toevoegen JSON/REST functie

Voorinstallatie

Eisen aan backoffice

functie in CSOkoppelvlak Nader te bepalen (icoon met link naar de site wordt dan op springboard geplaatst) Bestaande omgeving (CSO)

functie in CSO-koppelvlak Nader te bepalen

Bestaande omgeving (CSO)

Grafisch ontwerp

Rijkshuisstijl + webrichtlijnen

Rijkshuisstijl + toegankelijkheid waarborgen via mogelijkheden in het OS

Partners Beheer

ECO&P Bestaande omgeving (CSO)

ECOP Bestaande omgeving (CSO)

Budgetindicatie

10-20k€ ontwikkeling 10k€/jr beheer

50-150k€ ontwikkeling 10-30k€/jr beheer


25 van 33

in CSO-koppelvlak. Vervolgstappen: afh. van keuzes in roadmap Nader te bepalen

e

1 stap: Bestaande omgeving (CSO). Vervolgstappen: afh. van keuzes in roadmap e 1 stap: Rijkshuisstijl + toegankelijkheid waarborgen via mogelijkheden in het OS. Vervolgstappen: afh. van keuzes in roadmap Nader te bepalen e 1 stap: Bestaande omgeving (CSO). Vervolgstappen: afh. van keuzes in roadmap e 1 stap: 50-150k€ ontwikkeling 10-30k€/jr beheer Roadmap: 50k-80k€ begeleiding

6. Conclusies en aanbevelingen Conclusie Uit het onderzoek blijkt dat het prima mogelijk is om vacature en stage-informatie uit de mobiliteitsbank voor Rijksmedewerkers te ontsluiten via een mobiele website of een App. Uit de gesprekken en deskresearch komt geen duidelijke input voor een business case naar voren voor een App die toegang biedt tot loopbaan of vacature-informatie. Er bestaat al een mobiele website met externe vacatures. Deze zou relatief eenvoudig ingezet zou kunnen worden voor interne vacatures in combinatie met een inlog-mogelijkheid. Dit zou dan vrijwel dezelfde functionaliteit bieden als een eenvoudige App. Uitzondering hierop vormt de alertfunctie (met behulp van de pushfunctionaliteit van een App) welke vacatures en stages beter onder de aandacht zou kunnen brengen van de doelgroep. Aanbevelingen Op basis van het voorgaande adviseren wij te kiezen voor Scenario 1 of Scenario 3: -

-

In Scenario 1 wordt een mobiele website aangeboden waarmee de toegang tot vacatures uit de mobiliteitsbank wordt verbeterd. Dit kan met een relatief beperkte investering. De doorlooptijd hiervan is ca 1,5 maanden. Voor de websites www.werkenvoornederland.nl en www.werkenvoordeoverheid.nl wordt een dergelijke mogelijkheid al geboden. In feite wordt hiermee een ontbrekende schakel in het CSO-platform ingevuld. In Scenario 3 wordt een App met een Vacature Alert ontwikkeld, als eerste stap in de ontwikkeling van een HRM-App portfolio. Met de pushfunctionaliteit van een App kunnen vacatures beter onder de aandacht gebracht worden van Rijksmedewerkers. Geadviseerd wordt een dergelijke alert-App te ontwikkelen als onderdeel van een breder traject om loopbaaninformatie mobiel te ontsluiten voor Rijksmedewerkers. Een App met een vacature-alert is dan geen doel op zich, maar een eerste stap in de richting van een breder aanbod van loopbaan Apps. De investeringen worden dan niet alleen gedaan om op korte termijn de toegang tot vacature-informatie te vergemakkelijken voor de gebruiker maar ook om een nieuw (mobiel) kanaal te presenteren richting de doelgroep met een hoger potentieel voor de organisatie en een ontwikkeling te starten om hier verder invulling aan te geven door middel van een HRM-App portfolio. Een dergelijk portfolio kan zich naast instroom of doorstroom, ook richten op zaken als persoonlijke ontwikkeling, loyaliteit, uitstroom, etcetera. Dit vergt samenwerking met partijen die betrokken zijn bij het mobiliteitsbeleid van het Rijk.

Wij denken dat Scenario 2 niet de voorkeur heeft. Hierin wordt een Vacature Alert App voor Rijksmedewerkers gerealiseerd zonder parallel daaraan een strategie te ontwikkelen voor verdere doorontwikkeling. Uit de gesprekken die zijn gevoerd in het kader van dit onderzoek komt geen duidelijke business case naar voren komt voor een App met alleen vacature-informatie. Om een Vacature Alert App als zelfstandig project uit te voeren, zou ons inziens eerst een business case gevonden moeten worden.


26 van 33

Bijlage 1: Richtlijnen voor Apps Apps hebben een aantal unieke kenmerken. Ze bieden een sterke persoonlijke interactie met gebruikers. De installatie ervan is zeer eenvoudig en volgt een vast stramien. De omgeving biedt volop mogelijkheden om de App te promoten. Eenmaal geïnstalleerd heeft de gebruiker de App altijd bij zich. Helaas worden apps die niet aan verwachtingen voldoen (bijvoorbeeld doordat ze geen toegevoegde waarde bieden of onhandig zijn in het gebruik) ook even snel weer verwijderd door eindgebruikers. Mobiele consumenten zijn in zekere zin ‘verwend’. Zij hebben de keuze uit een breed aanbod aan kwalitatief hoogwaardige apps. Daardoor stellen eindgebruikers hoge (en steeds hogere) eisen aan de mobiele ervaring en daarmee aan de kwaliteit van apps. Tien richtlijnen bij het ontwikkelen van een mobiele strategie Een goede mobiele App benut de sterke eigenschappen van het mobiele platform om de beperkingen ervan te omzeilen. Er zijn 10 belangrijke richtlijnen bij het ontwikkelen van een mobiele strategie. 1. Houd rekening met de context van de gebruiker Mobiele media hebben over het algemeen beperkte input en output mogelijkheden, zeker wanneer we deze vergelijken met een desktop PC. Het is daarom van belang het aanbod van content en diensten specifiek te richten op mobiel gebruik. Daarbij is onder andere het volgende van belang: · Vermijd lange teksten · Vermijd te kleine ‘controls’ · Houd rekening met contrast en leesbaarheid · Filter het aanbod op relevantie in de (bedoelde en huidige) context. Wees selectief in het aanbod. Maak voor het bepalen van de context gebruik van de beschikbare sensoren op het device, waaronder GPS informatie · Houd rekening met het gebruik van bepaalde vormfactoren. Recent onderzoek[1] <#_ftn1> laat zien dat Tablet devices voornamelijk thuis (door 80% van de gebruikers) en op kantoor (door 15%) gebruikt worden, terwijl smartphones daarnaast ook veel (door 33%) in het openbaar vervoer gebruikt worden. 2. Maak de App persoonlijk Mobiele media zijn extreem persoonlijk. Gebruik kennis van de gebruiker, gebruikersvoorkeuren en navigatie historie om het aanbod zo gericht mogelijk te maken. 3.Houd rekening met het gebruik van diensten via meerdere kanalen en gebruik het ‘input once’ principe. Sla kennis van gebruikersprofiel, voorkeuren en navigatie historie centraal op zodat meerdere kanalen er na eenmalige invoer gebruik van kunnen maken om een zo gericht en efficient mogelijk aanbod te realiseren. 4.Wees dynamisch


27 van 33

Geef een gebruiker een reden om regelmatig terug te komen door steeds iets nieuws te bieden. 5. Wees actueel Mobiele media zijn 24/7 onder handbereik van de gebruiker. Ze blinken uit in snelheid, niet in diepgang. Distribueer nieuwe informatie eerst naar de gebruiker via mobiel. 6. Zorg voor een ‘snappy’ ervaring Laat de gebruiker niet wachten. Houd rekening met variaties in internet bandbreedte en device specificaties. 7. Maak het delen van informatie en statussen zeer laagdrempelig Social media zijn een uitstekend middel voor interactie en aanbeveling 8. Respecteer privacy Respecteer de privacy van de gebruiker, inclusief de enorme variatie in opvattingen rondom privacy. Onderzoek de opvattingen rondom deze speciale dienst. 9. Blijf ‘top of mind’ Gebruik push messaging, draai actieve (moderne) marketing campagnes, social marketing etc. om App gebruik te stimuleren. 10.Update de App regelmatig De verwachtingen van de gebruiker veranderen snel in een snel veranderende markt waarin er veel kapers op de kust zijn. Een App die stilstaat is vaak snel weer verdwenen.


28 van 33

Bijlage 2: Input voor roadmap Tijdens de gesprekken in het kader van dit onderzoek kwamen vele ideeën naar voren voor functionaliteiten van een LoopbaanApp. Hieronder zijn deze opgesomd (in willekeurige volgorde). 1. Gebruik sensoren. Voor het bepalen van de context kan gebruik worden gemaakt van de beschikbare sensoren op een device, zoals GPS informatie. Dit maakt het bijvoorbeeld mogelijk om vacatures te tonen afhankelijk van de locatie van een gebruiker. 2. Kennis van gebruiker Gebruik kennis van de gebruiker, gebruikersvoorkeuren en navigatie historie om het aanbod zo gericht mogelijk te maken. 3. Reden om terug te keren. Geef een gebruiker een reden om regelmatig terug te komen door steeds iets nieuws te bieden. 4. Messaging. Gebruik push messaging, draai actieve (moderne) marketing campagnes, social marketing etc. om App gebruik te stimuleren. 5. Bijwerken persoonlijk profiel. Het aanmaken en bijhouden van een persoonlijk profiel kan onder druk staan van een gebrek aan privacy en tijd op kantoor. Toch is een bijgewerkt persoonlijk profiel van grote waarde in het HRM proces. Toegang tot het persoonlijke profiel op een App past uitstekend bij het persoonlijke karakter van mobiele toepassingen. • Feitelijke gegevens zoals leefttijd, dienstjaren, kennisgebieden e.d., kunnen uitstekend via een mobiele App beheerd worden. • Het inzien van het eigen CV gaat goed met een PDF viewer op een mobiel device. Het kan de gebruiker bewust maken van de status er van. • Het ligt niet voor de hand dat een gebruiker een CV gaat schrijven of uploaden op een smartphone. Vanaf een tablet zou dat kunnen, maar het is het meest waarschijnlijk dat er gebruik gemaakt zal worden van een desktop. • Koppeling met een professioneel sociaal netwerk zoals LinkedIn past goed bij een App. 6. Raadplegen vacatures. Het bekijken van vacatures op kantoor kan onder druk staan van een gebrek aan privacy en tijd. Een App die de mogelijkheid tot het bekijken van vacatures in een andere context (tijdens woon werk verkeer of thuis) biedt kan toegevoegde waarde bieden • Het vacature overzicht moet actueel zijn • Nieuwe vacatures moeten te onderscheiden zijn van andere vacatures • Push messaging leent zich zeer goed voor het melden van vacatures die van speciaal belang zijn voor de gebruiker, bijvoorbeeld omdat ze aan bepaalde zoekcriteria voldoen • Vacatures moeten zoveel mogelijk te filteren zijn op persoonlijk profiel en eerder surfgedrag (op App of elders). Denk daarbij aan ‘aanbevolen vacatures’, ‘favorieten’ en ‘laatst bekeken’. 7. Hulp bij sollicitaties. Een goede conversie tussen vacaturebank gebruik en daadwerkelijke sollicitaties zal sterk afhangen van de mogelijkheid om na het lezen van een vacature direct te kunnen solliciteren. Zonder (link naar een) sollicitatiemogelijkheid is de waarde van een vacaturedatabase beperkt. • Een directe sollicitatie op een vacature vereist meestal een korte toelichting. Vanwege het beperkte UI van een smartphone zijn de mogelijkheden tot het schrijven van een dergelijke belangrijke tekst daarop ontoereikend. Ook op een tablet is dat, zij het in mindere mate, het geval. In een eerste versie van de App kan de mogelijkheid gegeven worden een vacature te markeren voor opvolging op een ander device. Latere versies zouden deze functionaliteit desgewenst uit kunnen breiden, afhankelijk van user feedback


29 van 33

8. Integratie met functiegebouw rijk. Het functiegebouw Rijk bevat informatie die zowel voor interne als externe gebruikers van een App interessant kan zijn in combinatie met vacatures informatie. Op een desktop wordt het functiegebouw Rijk in een aantrekkelijke vorm aangeboden, die naast het vacature overzicht getoond kan worden. Wanneer deze informatie op een mobiel device aangeboden wordt zal onderzocht moeten worden welke vorm aansluit bij mobiel gebruik. Naar alle waarschijnlijkheid is dit een andere vorm en rijst de vraag of vorm en inhoud van de huidige web applicatie eenvoudig gescheiden kunnen worden. Is dat het geval dan zal nog een nieuwe vorm gedefinieerd moeten worden, waarbij gestreefd moet worden naar een voor de gebruiker eenvoudige integratie tussen vacatureaanbod en functiegebouw. Gezien de huidige onduidelijkheid over de benodigde inspanning en opbrengst verdient het aanbeveling dit item op de roadmap te zetten, voorafgegaan door meer onderzoek. 9. Rijkstalentencentrum. Dit onderdeel van het CSO platform is met name gericht op ontwikkeling van interne medewerkers. Dat kan ook in de mobiele context interessant zijn, omdat gebruiksmoment en –plaats goed aansluiten bij deze content. De diversiteit van het mogelijke aanbod resulteert wel in een potentieel omvangrijke toevoeging aan de ontwikkeling van een mobiele app. Daarvan is op dit moment niet bekend of en hoe deze bijdraagt aan het gebruik van de app en de achterliggende doelen. In de huidige conjunctuur is wellicht ook een uitbreiding van het aanbod van cursussen en evenementen gericht op uitstroom te overwegen. Zeker wanneer dit gekoppeld wordt aan het gebruikersprofiel en zaken als push messaging, zou de ontwikkeling van dit onderdeel voor mobiel een meer tactisch/strategisch karakter kunnen hebben, waarmee de benodigde investering te rechtvaardigen is. 10. Functioneringsgesprek. Het CAOP (Centrum voor Arbeidsverhoudingen bij Overheidspersoneel) biedt een uitgebreid dienstenpakket rondom arbeidsverhoudingen. Een van de diensten in ontwikkeling is een App ter voorbereiding een functioneringsgesprek. Het ligt in de lijn om, als onderdeel van een roadmaptraject voor een LoopbaanApp, te bezien op welke manier deze Apps elkaar kunnen versterken of samen kunnen gaan in één App. 11. Versie check. Het is raadzaam een automatische versie check in te bouwen zodat de App zelf kan vaststellen welke versie gebruikt wordt en of dit de laatste versie is. De aanbieder kan daarbij bepalen of eventueel verplicht een nieuwe versie geïnstalleerd moet worden. 12. Feedback. Mogelijkheid tot het geven van feedback op de App. Dit is in het kader van cocreation, waarbij de eindgebruiker mede bepaalt welke roadmap items ontwikkeld zullen worden van groot belang. 13. Nieuws. Het aanbieden van relevant nieuws, zeker wanneer dit gericht is, kan het gebruik en de gebruiksfrequentie van de App aanzienlijk vergroten. 14. Statistieken. Door statistieken ten aanzien van het gebruik en App navigatie te verzamelen kan de App en het aanbod verder verbeterd worden. 15. Gamification. Het gebruik van game-methodieken is een trend in App design die de betrokkenheid, gebruiksfrequentie en het waardeoordeel van een App verder kan versterken. Door het aanbieden van persoonlijke statistieken (12 vacatures bekenen, laatste sollicitatie 1 december), Completeness levels (je profiel is 80% compleet, ga naar 90% door je LinkedIn profiel te koppelen), Benchmark gegevens (anderen bezochten gemiddeld 17 sollicitaties en stuurden 2 sollicitaties uit deze maand), Badges (Certified SCRUM Master) en Brags (post status op social media) krijgt het gebruik van de App een spel achtig karakter. Dit kan de betrokkenheid met de App vergroten en aanzetten tot gewenst gedrag. 16. Persoonlijke checklist bij solliciteren. Het gebruik van mobiele media heeft er toe geleid dat de consument veel minder dan vroeger gewend is te plannen. Planningsinformatie en


30 van 33

inspiratie is immer altijd onder handbereik. In dat kader past een Checklist solliciteren ook heel goed bij een Loopbaan App. De gebruiker heeft zo een persoonlijk stappenplan en hulp bij het voorbereiden van een sollicitatie. 17. Beslishulp. Tot slot noemen we de App als beslishulp. Wat is het gevolg van een bepaalde beslissing? Wat als ik deze baan zou krijgen? Wat betekent dat voor mij persoonlijk. Door deze functionaliteit aan te bieden wint de App aan persoonlijk voordeel en daarmee wordt de kans vergroot dat de App geïnstalleerd blijft. Bovendien geeft dit, mits goed uitgevoerd, extra reden om het persoonlijke profiel goed bij te houden. Daar kan de organisatie van profiteren.


31 van 33

Bijlage 3: Lijst van geïnterviewden Roy Bakker

De Werkmaatschappij , Expertisecentrum Organisatie en Personeel (EC O&P)

Ellen Beenders

Rijkswaterstaat, personele mobiliteit (Aanbodplatform Mobiliteit)

Robert Bennis

Ministerie van BZK, SSC-ICT Den Haag

Annemarie Boonstra Ministerie van BZK (Aanbodplatform Mobiliteit) Cecile van de Brandt De Werkmaatschappij , Expertisecentrum Organisatie en Personeel (EC O&P) Marloes Droog

De Werkmaatschappij , Expertisecentrum Organisatie en Personeel (EC O&P)

Jules Ernst

ICTU (Webrichtlijnen)

Sam Hermans

Belastingdienst (Aanbodplatform Mobiliteit)

Jip op den Kamp

De Werkmaatschappij , EC O&P (Aanbodplatform Mobiliteit)

Truus Krenn

Ministerie voor V&J, DJI, Mobiliteit (Aanbodplatform Mobiliteit)

Michal Oppenheimer De Werkmaatschappij , EC O&P (Aanbodplatform Mobiliteit) Roy Pereira

Rhinofly

Debby Radoux

A+O fonds Rijk

Ineke Schop

ICTU (project Digitaal Transparante Arbeidsmarkt)

Annette Teeuwen

CAOP, A+O fonds Rijk


32 van 33

Bijlage 4: Lijst van afkortingen

HRM CSO SOAP JSON/REST OS SSC-ICT SLA API GUI

Human Resources Management Carrière Sites Overheid Simple Object Access Protocol JavaScript Object Notation/Representational state transfer Operating System Shared Service Centre ICT Den Haag Service Level Agreement Application programming interface Graphical User Interface


33 van 33

LoopbaanApp Rijk. Haalbaarheidsonderzoek. In opdracht van: Versie 1.0

Recommend Documents