Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

De innovatie-paradox van de mobiele app

Mobile Convention Amsterdam 2016

Op de Mobile Convention Amsterdam waren veel verschillende verhalen te horen. Een interessant verhaal werd gehouden door Ton van Dijk (KPMG) en Arco van der Velde (BLiS) over het ontwikkelen van mobiele applicaties voor KPMG. Hun stelregel was eigenlijk dat alleen door mislukkingen je leert iets succesvol te maken. Hun verhaal beschreef de samenwerking van de afgelopen paar jaar en de verschillende apps die samen zijn ontwikkeld.

Ton van Dijk (KPMG) en Arco van der Velde (BLiS) presenteerden hun verhaal als een tweepersoons stand-up comedy. Met een lach en een traan werd verteld over hun gezamenlijke ervaringen. KPMG is een grote wereldwijde organisatie die de behoefte heeft om een aantal zaken voor medewerkers en klanten te vereenvoudigen. Mobiele apps zijn ontwikkeld om in die behoeften te voorzien. BLiS is een kleine partij die goed is in het ontwikkelen van apps. Maar het is niet eenvoudig om als grote multinational een contract te sluiten met een kleine developer.
De lessen die daarbij werden gegeven:
*    Een partnership kost tijd en
*    Een partner moet je kunnen vertrouwen

Een van de eerste projecten was niet op tijd klaar. Het leerpunt daar was: De noodzakelijke koppeling met de back-end en de infrastructuur zijn sterk bepalend voor het gereed zijn van de mobiele app.

Een volgend project betrof de KPMG One app, waarbij gebruikers nieuwscontent kunnen personaliseren, waarmee kennis en inzicht makkelijk gedeeld kunnen worden. De app geeft informatie die uit allerlei bronnen worden gehaald. Het leerpunt hier was: De kwaliteit van de app is sterk afhankelijk van de content managers, de app is slechts een framework voor de informatie.

Een volgend leerpunt betrof project uitvoering: Agile werkt goed als methodiek, maar je weet van te voren niet wat je krijgt. Neem iedereen mee in het proces en neem er de tijd voor. Een project dat gestart is met een vaste prijs en een vaste scope gaat niet samen met een Agile-uitvoering!

Klein werd viraal

In de afgelopen jaren is ook gewerkt aan een app om samenwerking te bevorderen en review te vereenvoudigen. Dat was klein begonnen maar werd als snel een viraal project. Het is door twintig landen binnen KPMG getoetst. Uiteindelijke zou de app vijftig verschillende talen moeten ondersteunen en aan hoge security eisen moeten voldoen. Het leerpunt was hier: Een app kan steeds groter en groter worden tot het nagenoeg onwerkbaar is. Je loopt het risico op een app uit te komen die misschien beter door Microsoft of Adobe geleverd kan worden.

Een ander leerpunt was: Bij de start is iedereen enthousiast, maar het kan toch maanden duren om de beslissing genomen te krijgen. Een jaar verder was er nog geen go voor het budget. Het lijkt daarmee op een marathon lopen. Het advies was: hou vol, soms is het gewoon bijzonder lastig.

Bij een volgende app werd besloten om de ontwikkeling anders te doen: Als je wil innoveren, moet je soms buiten de hokjes durven kleuren en onder de radar blijven

Bij innovatie gaat niet alles goed, je gaat vaak op je bek. Het is belangrijk om samen op pad te gaan en je boerenverstand te gebruiken. Blijf goed nadenken, je kunt niet alles voorzien.

Tot slot een wijze les: Wees jezelf, heel veel innovaties lukken niet, maar blijf het doen! We leven in een gave tijd met veel mogelijkheden.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5767925). © Jaarbeurs IT Media.
5,8

 

Reacties

Ik zie een reeks van .... lees hier, les daar....

Het bouwen van een app verschilt in niets van het bouwen van software. Requirements en proces zijn namelijk volkomen dezelfde en heb je die niet op een rij, dan krijg je .... een geleerde les?

Leerpunt een back-end en die sterk bepalend zijn voor het gereed zijn van je app?
Dan schud ik mijn hoofd. Immers, in de meest basale denkbare keten iets te produceren ga je na wat je requirements zijn en als je back-end en infrastructuur hier naar voren komen als showstopper, zeg ik zelfs, wat doe je in de app bizz?

De wetmatigheden en de ketens zijn namelijk geheel en al dezelfde als die voor IT en telefonie. Als de klant dit soort triviale zaken mag betalen dan is dit tekenend voor je naam en reputatie.

Er zijn wat zaken die een app een succes maken.
- Het werkt
- Het werkt
- Het werkt
- Het smoelt goed
- Heeft op de ene of andere manier toevoegende waarde
- Is voor gebruikers aantrekkelijk
- Gebruiks en installatie gemak
- Hij word gehyped en wordt in korte tijd heel populair
- Hadden we al genoemd dat het moest w.... oh ja....

Kortom, een app is een eenvoudig stukje software met toevoegende waarde voor de gebruiker en niet iedereen hoeft die toevoegende waarde te zien natuurlijk, daarom is het een app. Niet iedereen hoeft hem te willen zien.

Ga je een stuk software maken dat feitelijk niet als app is geschikt omdat het daar te groot voor is? Dan begrijp ik deze stelling wel, Had ik overigens ook vermeld dat mijn vermoeden is dat men tijdens de bouw en ontwikkeling hoogstwaarschijnlijk zaken aan het toevoegen is geweest?

René, ja een app bouwen is software, maar een app bouwen voor een mobiele telefoon is niet zoals je schrijft ("Kortom, een app is een eenvoudig stukje software") een eenvoudig stukje software.

Wie dat schrijft.... heeft *geen* *clue*.

"De wetmatigheden en de ketens zijn namelijk geheel en al dezelfde als die voor IT en telefonie"

Je simplicificeert extreem. Het is alsof je zegt "Oh, software, uiteindelijk zijn dat gewoon nullen en eenen."

Om je een paar hints te geven waarom app ontwikkeling rocket science is.

- Background processes.
- Offline / online data opslag
- multulingual en zoiets simpels als tijdzones
- security

Maak jij maar eens een mooie app die ook nog goed met beacons kan praten en liefst zonder de stroom van een batterij op te eten tijdens background processes. Good luck with that.

Als mensen zo simpel over software en apps praten dan klinkt dat in mijn oren hetzelfde als Ton Elias die niet weet wat een IP adres is.

Ik vind dit een heel leuk artikel!

En wat je hier hoort lijkt ook op een typisch geval van "Valley of death innovation"
Een innovatie omzetten naar een marktproduct is een pittige reis die het product vaak niet overleefd.

Innovatieve Apps zijn een stuk complexer dan hun desktop counterparts. Laat de beperkte scope je niet van de wijs brengen.

@Henri
Sec, er is heel eenvoudig een keten die je het beste volgt, maar die klaarblijkelijk door mensen niet word gevolgd met als gevolg publicaties als deze. Ik vind dat natuurlijk heel erg prima, ik hoef namelijk de rekeningen niet te betalen maar het is telkens weer verrassend herhalend.

Het maakt mij feitelijk niet uit hoe jij aan kijkt tegen dit gegeven en telkens weer de diepte in duikt, feit blijft dat dat proces en de wetmatigheden die daar mee gepaard gaan gewoon onveranderd dezelfde blijft, wat het dan weer, wat mij betreft voorspelbaar blijft houden.

Simpel gesteld, sla je een stap over in dat proces, hou je je niet aan dat proces, heb je geen idee van dat proces, krijg je dit soort publicaties en dito heel veel rekeningen. Ik weet niet hoe jij daar tegen aan wil kijken maar voor mij is automatiseren/mechaniseren nog steeds een zaak van proces versnellen en daar je winst uit halen. Niet lessen leren die je feitelijk nu niet meer zou hoeven leren.

Om even jouw voorbeeld aan te halen wat Ton Elias betreft, Ton had het 'jargon' aardig op zijn netvlies, maar weet niets van een proces. Uitkomst, wederom zeer voorspelbaar, vijf mensen, geen idee van IT, ruim een jaar en enkele miljoenen verder, komen met een dik boekwerk die aan een dame word gegeven die die ochtend toch nog even moest googlen wat ICT toch ook alweer niet was.

Uitkomst van dat onderzoek, BIT, ofwel heel eenvoudig IT Change management standaard uit het boekje en de kast.

Even terug naar dat procesje mijn beste Henri, volkomen los van wat jij vanuit jouw kennis en expertise respectvol aan brengt, aan dat proces ben ook jij gebonden en hou jij je niet aan dat proces, dan krijg je daarvoor gegarandeerd tijdverlies en hoge rekeningen terug. Tenminste, als je dat voor een opdrachtgever doet.

Software
Jij vult hier iets in voor mij dat je mij niet hebt zien plaatsen. De werkende apps die ik heb getest, dat zijn er best wel wat in die tussentijd, zijn relatief eenvoudig, zitten goed doordacht in elkaar en werken omdat het doel helder was. Gemene deler daar, meisjes/jongens die een leuk idee hadden en daarmee stoeiden en daar iets leuks uit kregen dat vervolgens een soort van viraal gaat. Goh, als ik dan kijk naar de succesvolle andere apps.....

De benadering en proces van software en app zijn gelijk Henri, volkomen gelijk, like it or not.

Henri,
Zie opmerking van René over toegevoegde waarde voor de gebruiker, factorisatie-probleem in de keten komt uiteindelijk neer op P ≠ NP die stelt dat je snel ziet of duizend stukjes van een puzzel op de juiste wijze gelegd zijn maar vice versa zegt het niets over de moeilijkheid van de puzzel (proces?) zelf. Ontwikkelen van software of apps is in wezen niet verschillend, de wijze van testen helaas wel.

Ewout, en testen van software is geen onderdeel van het maken van apps?

René verwart IT met project processen.

Ewout; laat ik het naar jouw wereld vertalen. Storage is niets anders als input/output. Dus storage leveren is altijd hetzelfde, of is dat nu Rene zijn verhaal? Als iemand zoiets roept weet jij toch ook wel beter?

Wat is in hemelsnaam nu de definitie van "Het werkt"? Dat is net zo onzinnig als "Het is veilig". Of IT is 100% voorspelbaar.

Het verhaal en de argumenten van dit artikel zijn gewoon valide. Er is niet zoiets als zekerheid over het succes van een software (of app) project.

Oh Jee . . .
"Ontwikkelen van software of apps"
laat ik nu toch gedacht hebben dat "apps" en "software" precies het zelfde zijn.

Om met Rene te spreken, is dat een "les": een "app" is volgens Guru Ewout geen Software!

Interessant!

Henri,
Mijn wereld is Enterprise Architectuur en vanuit het software perspectief is met name de Enterprise Lifecycle hierin interessant. Storage is trouwens heel wat meer dan I/O als we kijken naar CIA principe hierin, digitale residu van apps in de vorm van data moet vaak heel wat langer bewaard worden dan de app zelf. De P ≠ NP van ongestructureerde data en alle
beloften van moderne datasynthese levert weer prachtige puzzels op;-)

Lezen kost niets maar schrijven daarentegen.....

Een app is gewoon een C/S oplossing op een ander apparaat, ontwikkeling ervan is exact
hetzelfde als eerdere desktop software. De lifecycle (Consumerization of IT?) van devices is echter geheel anders wat een andere manier van testen (CI) vraagt. Onderhoudbaarheid van een app wordt dan ook grotendeels bepaald door de modulariteit ervan. Hints die je geeft over de complexiteit zijn al lang opgelost met architectuur lagen zoals middleware.

P.S.
Veel apps zijn afhankelijk van een framewerk (Domino?) welke uiteindelijk ook weer legacy wordt als we kijken naar het probleem van lifecycles,

Ondanks mijn geintje, super samengevat.
Vooral "digitale residu" is een ijzersterk punt.
Bij de korte levensduur van vele "apps" wordt de toekomst spannend, kun je in 5, 10, 15 jaar die data nog op een zinvolle manier lezen/gebruiken?

Typisch geval van "doelgerichtheid van techniek in ruimte en tijd". Techniek kent de begrippen doelgericht, ruimte en tijd niet. Voor ons mensen heel gewoon (?), voor softwareontwikkelaars dus ook.

De paradox ontstaat door de veranderingen in de samenleving. Middelen, bv informatie, zijn doelen geworden. Informatie is echter niet "los verkrijgbaar". Door er toch in te handelen is een informatiemarkt (aan het) ontstaan die qua omvang de geldmarkt zal overstijgen. ICT heeft de techniek geleverd waardoor een virtuele geldmarkt is ontstaan die ongeveer 25x zo groot is als de reële economie. De paradox van een aandeel"houder" is dat hij veranderd is tot aandeel"wisselaar" met een transactiekosten optimalisatie ipv een aandeel in de waarde van een bedrijf voor de samenleving.

"KPMG is een grote wereldwijde organisatie die de behoefte heeft om een aantal zaken voor medewerkers en klanten te vereenvoudigen". De paradox hiervan is dat de samenleving als geheel hier baat bij heeft. Maar dat is waarschijnlijk niet het doel van KPMG.

De vraag is derhalve: hoe kunnen we met ICT bijdragen aan een - mondiale - samenleving werken waarin we een aandeel hebben in elkaar? Of is dat doel ook al geframed in een verdienmodel?

@Jan
Noem mij eens een app die je na 5, 10, 15 jaar nog wilt lezen/gebruiken.
Je bent toch niet in het WordPerfect / AstonTate / Microsoft tijdperk blijven hangen?
Maakt 't uit was ook laat voor je gisteren... dan gebeuren zulke 'dingen'. ;D

Wij schrijven onze app's in Java - hoe moeilijk kan dat zijn?
Inderdaad, bijzonder is het Zeker niet, maar (intern) zeer bruikbaar.

@Henri
Laten we jouw idee dat ik IT met project proces zou verwarren even naar het rijk der fabelen verwijzen. Voldoet je project proces niet aan hetgeen je beoogt met je IT en wat de wetmatigheden zijn dan weet je nu meteen waarom het zo vaak mis gaat. Hebben we dat ook meteen even afgedekt. ;O)

Elke IT discipline, handeling, proces, project is gewoon gestoeld op dezelfde principes en gebonden aan dezelfde wetmatigheden Henri. Ook al vind jij vorm en kleur en richting, beredeneert vanuit je eigen ervaring en discipline 'je van het'. Ook die zijn aan dezelfde regels gebonden want jij blijft beredeneren vanuit je eigen ervaren en discipline.

Dat is precies wat ik allang los heb gelaten omdat de kleur, smaak, grootte, discipline hierin niet meer zo relevant zijn. Overigens mijn beste Henri, met alle respect van de wereld voor jou kennis en kunde, als jij nog steeds niet wil accepteren dat elk IT proces, stap, discipline, projectmatig of niet, niet in lijn zouden moeten zijn met elkaar, dan weet je waar die hoge rekeningen vandaan komen.

IT is nu eenmaal een exacte materie. Exact als in volkomen voorspelbaar. Mensen zijn dit niet, vandaar al die hoge rekeningen telkens weer. Als iets exact moet zijn om te kunnen werken, dan weet je toch van te voren hoe exact dat moet zijn? Dus als jij blijft stellen dat dat allemaal anders is, vind ik dat hardstikke prima. Ik hoef al die rekeningen niet te betalen.

Ik nodig je graag een keer uit voor een seminar als we weer zover zijn. ;O) In die tussentijd haal ik mijn schouders een beetje op over deze publicatie. Dat is namelijk precies mijn punt wanneer ik stel dat IT voor 100% voorspelbaar is, veel mensen die met IT bezig zijn weer niet.





De discussie René en Henri geeft aan waar de schoen wringt.

René: "IT is nu eenmaal een exacte materie. Exact als in volkomen voorspelbaar. Mensen zijn dit niet, vandaar al die hoge rekeningen telkens weer. Als iets exact moet zijn om te kunnen werken, dan weet je toch van te voren hoe exact dat moet zijn? Dus als jij blijft stellen dat dat allemaal anders is, vind ik dat hardstikke prima. Ik hoef al die rekeningen niet te betalen."

Henri: "René, ja een app bouwen is software, maar een app bouwen voor een mobiele telefoon is niet zoals je schrijft ("Kortom, een app is een eenvoudig stukje software") een eenvoudig stukje software."

ICT is een hulp-middel; niet een autonome entiteit. Het middel kan exact worden bepaald en dus ook exact worden berekend, uitgaande van een professionele organisatie die "het product maakt wat wordt gevraagd".

Wat blijkbaar niet exact kan worden bepaald is het doel; datgene wat gemaakt moet worden. Of, nog moeilijker, het doel is niet het werkelijke doel, maar een afgeleide. Dat procesgegeven levert een mismatch op met het product. Het "eeuwige" probleem (sinds 50 jaar) van de ontwikkeling van ICT. APS zijn meer proces gericht dan en daardoor complexer dan oude (administratieve) Applicaties zoals Henri terecht stelt.

In "Architecten terug naar de blokkendoos" (21 juli 2009 https://www.computable.nl/artikel/opinie/overheid/2998823/1509029/architecten-terug-naar-de-blokkendoos.html) gaf ik het verschil in procedurele en proces gerichte applicaties aan. Nu we meer operationele real-time-real-world aps proberen te bouwen komt de waarde van een "eerste orde (primair) proces" duidelijker dan ooit naar voren.

Met het oog op de toekomst kunnen René en Henri elkaar wellicht op en in de real-time-real-world toch nog vinden.

René,

Het gat tussen theorie en praktijk is in de praktijk vele malen groter dan dan in theorie. Dat IT voorspelbaar is, is theorie en een te grote simplificatie en in mijn ogen daarmee onbruikbaar.

All models are wrong. Some are useful.

IT als 100% voorspelbaar aanduiden is niet useful en in mijn ogen gewoon "wrong".

En aangenomen dat jij belasting betaald betaal je dus wel degelijk mee aan de hoge rekening van falende overheden.

IT voor 100% voorspelbaar... vertel dat aan Bill Gates voor zijn demonstratie van plug & play.
Ook IT projecten (of projecten in het algemeen) zijn 100% voorspelbaar. Dat is theoretische nonsens. Zijn er credentials om dat te onderbouwen?

Als we het dan weer even op dit artikel betrekken. Je hekelt KPMG en de schrijver dat er app projecten zijn die mislukten. Maar er zullen altijd mislukkingen plaatsvinden omdat succes nooit zeker is, welke methode of theoretisch model je ook hanteert.

En met apps is het bijzonder. Ja software is linksom of rechtsom altijd code, of dat it nu een app is, of een applicatie op server of PC. Maar niet alle soort code leent zich voor het beoogde doel. Zo kun je een stukje "Het werkt!" code schrijven die prima werkt op een mobiel, maar die bijvoorbeeld niet schaalt, heel inflexibel is, labiel (denk aan 1000 verschillende android versies of 1000 verschillende devices), en dat kan uiteindelijk dus invloed hebben op het succes van je app. Dus elke uitspraak die je doet over 100% zekerheid, voorspelbaarheid en slagingskans is per definitie onwaar.

"Dat is precies wat ik allang los heb gelaten omdat de kleur, smaak, grootte, discipline hierin niet meer zo relevant zijn. "
Dat zijn ze dus wel, alleen in een theoretisch niet op praktijk gestoelde "wetmatigheid" misschien niet.

IT is geen *exacte* materie. Hooguit in de theorie. Het is een schadelijke oversimplificatie om het te stellen en daar blijf ik me dan ook tegen verzetten....

De propositie 'IT is voorspelbaar' is uiteraard onzin. Het bekt misschien lekker, maar heeft niets met de werkelijkheid te maken.

Voor het gemak neem ik even aan dat de propositie betrekking heeft op het domein van ICT infrastructuren.
Dan gelden:
a) Er bestaat namelijk geen concreet middel dat in staat is om een dergelijke voorspelling te genereren.
b) deze propositie eenvoudig te falsifieren is door elke techneut die iets onvoorspelbaars heeft meegemaakt mbt. tot een ICT-infrastructuur.

Wellicht dat het merendeel van de events in een ICT infrastructuur rationeel te verklaren is, maar dat maakt een ICT infrastructuur niet 100% voorspelbaar. Ik heb in mijn leven al teveel bugs en storingen gezien die componenten, applicaties etc. lieten afwijken van het te verwachten gedrag.

Mijn beste ;-) KJ,
Rene heeft inmiddels ook niet zoveel meer met de werkelijkheid te maken. Wat hij er zelf over zegt : "Dat is precies wat ik allang los heb gelaten omdat de kleur, smaak, grootte, discipline hierin niet meer zo relevant zijn. "

@ Henri,
Prima dat jij het 'wrong' vind, ik hoef jouw klanten niet te bedienen, ik hoef de discussies niet te voeren, ik hoef niet uit te leggen waar de schoen wringt. Dat doe ik mijn toehoorder(s) wel en doen ze er iets mee is dat mooi, ze gaan meteen IT inzetten waarvoor die is bedoeld. Doen ze het niet ook prima, ik hoef inderdaad hun rekeningen niet te betalen.

Als dat 'te simpel' in jouw ogen is, vind ik dat heel prima. Jij en ik in het verhaal zijn wat mij betreft weer niet zo heel belangrijk. De Klant is dat wat mij betreft weer wel. Zo eenvoudig zie ik dat.

@Dino
Als je focussed op het gegeven dat IT alleen maar werkt wanneer jij als professional exact bent in die materie, ongeacht de discipline, dan is dat wat mijn punt is. Programmeer je, software of ap, en je hebt geen duidelijk doel voor ogen omdat je toestaat dat wens/requirements van je klant telkens onderweg wijzigen, dan heb je als uitkomst bovenstaand artikel.

Technisch
Neem een server, pc, tablet, phablet, smartphone en jet 'toetst' zomaar wat in dan krijg je 'zomaar' wat op je display zonder dat het 'iets' constructiefs doet. Pas als je denkt, ik wil bellen, je geeft Exact het te bellen nummer in en drukt, op de voorgeprogrammeerde toets dat het toestel opdracht geeft te bellen, en het functioneert.

Technisch II
Je neemt een server, 19"rackmountable, je richt hem fan-tas-tisch in, had ik je hier al gezegd dat elke stap die jij daarbij voldoet exact, dus 100% voorspelbaar dient te zijn? Niet, bij deze. Maar in je 'procesje' had je vergeten te communiceren met de 'line' povider die geen line beschikbaar heeft voor jou.... tja, ook exact, prachtige server waar je niet zo heel erg veel aan hebt.

Als jij vind dat dit geen 'werkelijkheid' voor je is, hardstikke prima. Edoch, je blijft zowel procesmatig als uitvoerend, technisch en theoretisch, IT wise, gebonden aan het gegeven dat elke stap in en met IT exact moet zijn en dient te kloppen, ergo, gewoon voorspelbaar is.

Of je nu techneut bent of programmeert, een app maakt, er zijn gewoon een paar regeltjes die je het best in acht neemt. Doe je dat niet, prima, ik hoef die rekeningen niet te betalen maar leg 'Klanten' wel uit waarom meer dan 3/4 van app en software trajecten zo zwaar verlies leiden en waarom dat zo is.

Het gaat niet om het kleurtje of de vorm, het gaat om het gegeven dat je met een exacte materie werkt. Thats it.

In de realiteit is alles relevant. Werkelijkheid is niet IT wise ;-)
Agile is ontstaan omdat requirements wijzigen, onvoorspelbaar. Mensen willen dat, een half woord vinden ze genoeg en ze willen eigenlijk niet eens een sprint afwachten. Ze willen geen feedback, maar ook geen communicatieproblemen. Ze willen verder wel bellen, geen toetsen indrukken. Ze willen makkelijk, maar wel veilig. Eigenlijk willen ze geen specs, ze willen dat het gewoon werkt. Dynamisch maar beheersbaar. Bij hier en daar een bui, willen ze dat die daar valt. Ze willen complex maar ongecompliceerd. Cloud, maar wel controle. India, maar geen accent. Orde, maar geen regels. Snel, goed, maar wel wel goedkoop, door een jonge maar ervaren IT-er.

Heel computable bestaat eigenlijk bij de gratie dat IT onvoorspelbaar, niet lineair, niet rationeel, niet exact is.

Ja, Dino, er bestaat geen softwarepakket waar ik niet binnen 5 minuten functionaliteit kan demonstreren die hetzij anders dan verwacht, hetzij duidelijk foutief, hetzij helemaal niet werkt.

@Dino: juist dankzij die onvoorspelbaarheid in de IT hebben we alemaal een leuke baan.

Computable Expert
Eildert van Dijken

Eildert van Dijken
Principal Consultant, STRICT BV. Expert van Computable voor het topic Mobility.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×