Mobiele touch-based devices vaker inzetbaar dan je denkt

In een workshop vroeg ik laatst „Wanneer kun je een mobiel touch-based mobiel device inzetten?”, en verschillende deelnemers riepen toen „Altijd!”. Dat geeft in ieder geval goed de sfeer weer, maar de werkelijkheid is natuurlijk iets genuanceerder.
 
Mobiele touch-based devices, zoals smartphones en tablets, zijn uitermate geschikt voor iedere situatie waarin je niet uitgebreid hoeft te typen. De nadruk ligt dan natuurlijk op allerlei gegevens raadplegen. Maar ook gegevens invoeren is best mogelijk, al moet dat wel zo makkelijk mogelijk zijn: via grote (simulaties) van druk- of draaiknoppen, kiezen uit voorkeuzelijsten, of bevestigen van vooringevulde gegevens.
 
Kopieer niet rücksichtslos een bestaande applicatie- of webdialoog bij dit soort toepassingen. Zo zag ik vorig jaar nog een servicemonteur zijn werkbon invullen op een laptop: hij keek op een briefje wie ik ook alweer was, en zocht mijn gegevens er vervolgens op de laptop met de hand bij. Daarna begon hij uit een popup scherm werkzaamheden te selecteren en op de lege werkbon te zetten. Uiteindelijk vulde hij dat aan met de tijd die hij besteed had, en zocht via een nieuw popup scherm nog een gebruikt onderdeel toe. 
 
Op een mobiel touch-based device, zoals een tablet, kan dat ook anders: via de GPS functie weet de tablet waar de monteur is, en zoekend op postcode en kijkend in de agenda-afspraken selecteert de tablet mijn klantgegevens alvast voor. Mochten er meerdere mogelijkheden zijn, dan wordt de meest waarschijnlijke klant voorgesorteerd en de rest staat in een snelle selectielijst. De tablet kan ook een voorzet doen voor de werkzaamheden, want ik heb immers een probleem gemeld toen ik de afspraak maakte. Bij bepaalde werkzaamheden staan de standaardonderdelen al opgevoerd. Alle items die voorgeselecteerd staan, hebben natuurlijk een verwijderkruisje, zodat de monteur ze snel kan wegtikken als ze niet van toepassing zijn. Selectie van nieuwe activiteiten of onderdelen gaat via snelle scrolllijsten. De gewerkte tijd kan de tablet ook voor-invullen: hij weet immers sinds wanneer hij op deze locatie is. Dat is in de meeste gevallen de begintijd. Een klein wieltje naast de tijd zorgt er voor dat je snel een nieuwe tijd kunt draaien. De eindtijd is natuurlijk „nu”.
 
Zo’n app kan dus al veel meer gegevens vooraf invullen dan je op het eerste gezicht zou denken. Creatief naar de situatie kijken, kan heel veel gebruiksgemak opleveren! Hou daarnaast ook rekening met het feit dat tablet gebruikers misschien niet rustig zitten. Maak bedieningselementen dus groter dan je op een gewone webdialoog zou doen.
 
Denk ook eens aan toepassingen waarbij er minder afstand tussen twee personen prettig overkomt. Bij het gebruik van een laptop of PC, is er altijd afstand tussen de gebruiker van de computer en de ander. Vaak is er zelfs een balie of tafel nodig. Bij een tablet, kun je naar de ander toelopen, naast elkaar gaan zitten, samen op het scherm iets aanwijzen. Vaak komt dit veel (klant)vriendelijker over.
 
Kortom, mobile touch-based devices zijn vaker inzetbaar dan je denkt. Ook in situaties waarin een gewone laptop of computer niet echt voor de hand ligt.

Een raamwerk voor gebruikersvriendelijkheid

„Zen and the art of motorcycle maintenance” is één groot pleidooi voor kwaliteit. En dat kwaliteit niet achteraf toegevoegd kan worden. Het ontstaat op talloze plekken tijdens het werk zelf. Zo is gebruikersvriendelijk ook nauwelijks achteraf toe te voegen. Dat is vaak wel het idee: „laten we nog even de veldjes en knoppen goed op het scherm zetten”, wordt er dan aan het einde van het project gezegd. Zo werkt het natuurlijk niet. Echte gebruikersvriendelijkheid ontstaat al veel eerder. Is in mijn ogen zelfs onderdeel van de cultuur van de organisatie. Daarom een eerste aanzet tot mijn raamwerk om hierover te discussiëren.

 
Gebruikersvriendelijkheid heeft aspecten die op verschillende niveaus in de organisatie een rol spelen, danwel daardoor beïnvloed worden. Vanuit enterprise architectuur is de volgende driedeling gebruikelijk:  business - informatievoorziening - infrastructuur.
 
Op businessniveau kan gebruikersvriendelijkheid vertaald worden naar de wens om een product of dienst neer te zetten met waarde voor de klant. Dus niet de marge van, of het uitvoeringsgemak voor de organisatie staat centraal. Dit is een cultuur waarin woekerpolissen niet bedacht worden. Je denkt eerder aan een betaalrekening die geen debetrente kent als je rood staat, maar bij de bank nog wel tegoed hebt op spaar- of beleggingsrekeningen. Het betekent ook dat je het proces organiseert rondom de klant. En niet, zoals in ziekenhuizen, rondom de specialist. Daarnaast zal ook het proces voor het bedenken en uitwerken van nieuwe producten en diensten anders in elkaar zitten. Gebaseerd  op de Service Design methode.
 
Op informatievoorzieningsniveau wordt gebruikersvriendelijkheid vaak gezien als veldjes en knoppen op de juiste plek zetten op het scherm. Dat is er inderdaad een onderdeel van, maar wel ongeveer het laatste. Je begint namelijk met de verdeling van taken tussen applicatie en de mens, waarbij je beide laat doen waar ze goed in zijn. Vervolgens kijk je naar interactie design (of UX, de Engelstalige afkorting), waar de optimale schermvolgorde wordt bepaald. Je voegt nog wat zaken toe die het altijd goed doen, zoals vrijheidsgraden om het gebruik te configureren naar eigen wensen. Dit leidt ook tot extra gegevens die een applicatie bewaard, zoals de opties die de gebruiker heeft ingesteld, maar ook zaken die hij of zij onbewust heeft gedaan. Zoals het venster rechtsonder op het scherm zetten, of de kolommen in een andere volgorde zetten, of een speciale sorteervolgorde instellen. Al dit soort zaken zullen in het ontwerp- en realisatieproces meegenomen moeten worden. En getoetst via prototyping. Erg veel werk… Is dat allemaal wel de moeite waard?
 
Op infrastructuurniveau leidt aandacht voor gebruikersvriendelijkheid tot keuze van gebruiksvriendelijke apparaten. In de jaren ’90 was een PC met Windows en een muis nog je-van-het. Tegenwoordig kun je niet om touch-based apparaten heen, zoals iPhones en iPads, of Android-gebaseerde devices. Daarnaast zul je moeten kijken naar een bring-your-own-device inrichting van de infrastructuur, een gastnetwerk voor (privé-)devices van medewerkers, bezoekers en externe inhuur. En natuurlijk voldoende bandbreedte voor alle multi-media die tegenwoordig gebruikelijk is.
 
Levert dat ook nog wat op? Met kleine gebruikersgroepen is het moeilijker aan te tonen, maar bij grote aantallen gebruikers is de business case makkelijk te maken. Minder clicks betekent meer doen in minder tijd. En denk eens aan alle klanten die niet afhaken omdat ze te veel gegevens moeten invullen op de website. Denk überhaupt aan alle klanten die aan vrienden en bekenden vertellen dat ze nu iets hebben meegemaakt waarbij ze echt in het middelpunt van de aandacht stonden…

Mobiele site is een remix van de gewone website, maar wel met een twist

In de muziekwereld weten ze wel hoe je voldoende aandacht krijgt voor een liedje: het moet iets hebben wat het interessant maakt. En soms heb je liedjes op een album staan die niet zo interessant zijn. Daar moet je wat mee als ze tot single gebombardeerd worden; oftewel, je maakt een remix. 

Een remix maakt een nummer interessanter doordat de remixer het tempo opvoert, het nummer meer breaks geeft, een nieuw en interessant geluid toevoegt, of een combinatie van die dingen verwerkt. Het eerste nummer dat ik ken waarbij deze truc succes werd toegepast is The Reflex van Duran Duran (albumversie, single remix). Recentere toepassingen zijn Mesmerized van Faith Evans (albumversie, single remix), of de herinterpretatie van Britney Spear’s Circus door Dirty Loops.
 
Websites hebben de afgelopen 15 jaar een soortgelijke ontwikkeling doorgemaakt: van vrij simpele, tekstgebaseerde pagina’s, zijn ze geëvolueerd naar ingewikkelde sites met veel kleuren, plaatjes, filmpjes en een grote hoeveelheid functies. Een ontwikkeling die gelijk opliep met de groei van de schermafmetingen en het aantal pixels op die schermen.
 
In de muziekindustrie zie je heel soms een ander soort remix. De versie waarin het nummer simpeler wordt gemaakt, meer mainstream. En daardoor wordt het nummer nu juist een hit. Sing It Back van Moloko (albumversie, single remix) is hier een goed voorbeeld van. Het origineel is nogal  barok gearrangeerd, terwijl de remix nu juist minder elementen gebruikt. 
 
Deze vorm van remixen is ook nodig bij het maken van een mobiele versie van je bedrijfswebsite. Je hebt een simpelere versie van je site nodig, met minder elementen, minder opsmuk en minder functies. Daarvoor zijn 3 reden te noemen:
  1. Een mobiel device zoals een smartphone heeft kleinere schermafmetingen en minder pixels dan een desktop- of laptopcomputer, de meeste tablets ook
  2. Moderne mobiele devices hebben een touch-based interface, en vingers hebben nu eenmaal grotere afmetingen dan de punt van een muiscursor. Daarnaast wil je minder typen, omdat dit onhandig is, zeker op touch-based smartphones
  3. Het mobiele device wordt gebruikt in een omgeving met veel „mentale” afleiding, en de gebruiker doet de bediening „er even bij”. Voor de bediening van een desktopcomputer ga je zitten achter een bureau. Zelfs bij een laptop is het voor iedereen duidelijk dat je met een computer bezig bent. Maar met je smartphone sta je midden in een drukke winkelstraat tijdens de Sinterklaasinkopen. Met een iPad zit je op de bank terwijl je zoon naast je op zijn elektrische gitaar staat te spelen.
Een mobiele website ontwerp je zodanig dat er maar één functie duidelijk in beeld is. Bij winkelsites is dat meestal de zoekfunctie. Kijk maar naar de mobiele sites van Amazon.com of Bol.com. Meer functies op het schermpje proppen heeft geen zin: of de bediening wordt moeilijker (denk aan te veel links en knoppen die je met je dikke vingers tegelijkertijd raakt), of de gebruiker wordt te veel afgeleid door de herrie om hem/haar heen om alle functies makkelijk te kunnen ontdekken. Naast de functie die primair in beeld is, heb je ook links of knoppen naar de overige functies nodig. Echter, te veel functies zorgt weer voor teveel links of knoppen in je bediening.
 
De belangrijkste ontwerpuitdaging is wat je op de homepage van je mobiele site zet. Heb je al een goedbezochte websites, dan biedt een analyse van het sitebezoek uitkomst: kijk wat de meeste bezoekers op je site doen. Heb je onvoldoende bezoekers, of ben je bezig met een nieuwe site? Pas dan Service Design en/of gebruikersinteractietechnieken toe. Wat is het belangrijkste doel waarmee de meeste bezoekers naar je mobiele site komen? Dat plaats je op de homepage.
 
Versimpelen is moeilijk, de meeste remixen van liedjes zijn ingewikkelder dan het origineel. Toch is versimpelen een cruciale vaardigheid voor goed ontwerp van mobiele sites. Ik wens ons daar veel succes mee.

Informatie-innovatie voor de kledingbranche?

Als echte man zou ik natuurlijk een hekel moeten hebben aan kleding kopen. Dat valt eigenlijk wel mee. Toch leek on-line kleding kopen mij wel wat: in plaats van een hele middag door de stad sjokken, laat ik de spullen thuisbezorgen om ze op mijn gemak te bekijken. Jammer genoeg blijkt dat gemak toch wat tegen te vallen. Het probleem: pasvorm.

 
De kledingbranche beschikt al jaren over een redelijk erkend maatstelsel in vorm van o.a. taillematen voor broeken (36 inch) en boordmaten voor overhemden (43). Voor overhemden aangevuld met kreten als Casual, Custom Fit en Slim Fit. Want een boordmaat zegt natuurlijk niet alles. Bij „nette” overhemden willen ze ook nog wel eens de mouwlengte vermelden, of zelfs het overhemd met verschillende mouwlengtes leveren (doe mij maar mouwlengte 7(*).
 
Werkt mooi, denk je. Iedereen tevreden. Jammer genoeg vinden de „hippere” merken dit soort maatstelsel wat te uitgebreid. Dus gebruiken die de, in mijn ogen, dramatische indeling in S, M, L, XL en XXL. En dat is niet het ergste. Stel je bestelt een overhemd in maat L, en het past. Dan heb je helemaal niet de zekerheid dat het volgende overhemd van hetzelfde merk in maat L ook past. Want ontworpen door een andere ontwerper, gemaakt door een andere onderaannemer, en van andere stof, die meer of minder meerekt.  Dus ik bestel bijna alles zowel in L en XL (oké, vaak XL en XXL), en stuur dus minstens de helft van de levering terug. Soms zelfs alles, omdat zelfs de XXL voor ultraslanke mannetjes gemaakt blijkt.
 
Kan dat niet anders? Volgens mij wel. Ieder kledingstuk is ontworpen, en dat is vast op een computer gedaan. Vervolgens worden er patronen gemaakt voor iedere maat. Met die patronen wordt stof geknipt, en in elkaar gezet. Aan het uiteindelijke kledingstuk wordt een label gehangen met een barcode erop. Als het ontwerp in de computer zit, en daar ook de patronen gemaakt worden, dan weten we dus hoe groot ieder kledingstuk is. Waarom geven we die gegevens niet door aan de webshops? Zodat ik als koper bij een kledingstuk niet alleen „XL” zie staan, maar ook een aantal essentiële maten in centimeters? Zoals boordmaat, borstomvang, taillemaat, mouwlengte en lengte van het rugpand.
 
Moeilijk? In de muziekbranche doen ze dat al jaren met cd-beschrijvingen (maar die hebben geen maat, inderdaad). Duur? Misschien wel, maar veel goedkoper dan 60% retouren verwerken en opnieuw aanbieden. En denk eens aan de milieuwinst, als we 50% minder goederen twee keer door het land rijden.
 
Laten we het wel direct goed doen: ieder merk mag zijn eigen online database neerzetten. Maar we gebruiken wel allemaal dezelfde servicedefinitie en gegevensstructuur.
 
(*) Waarom nou niet in centimeters? Weet ik veel dat een „normale” mouwlengte 6 is, en dat 7 langer is. Tijd voor nog een andere blog entry…

Eindgebruikers met de macht van tovenaars

Iedere keer als ik mijn iPhone gebruik, bekruipt me een gevoel van verbazing: het is zo mooi om te zien hoe het scherm direct mijn vingers volgt. Het is ook een gevoel van macht. Macht over het apparaat, en daarmee ook macht over de informatie die het toont. Ik kan inzoomen, selecteren, doorprikken, en bewerken. Allemaal in milliseconden. Ik tik door mijn Linked In uitnodigingen, bekijk met Layers welke huizen in de buurt te koop zijn, en vraag aan Iens of er in de buurt nog iets lekkers te eten is. Nou weet Linked In daarbij niet waar ik ben, maar Layers en Iens maken mij het leven een stuk gemakkelijker doordat ze weten waar ik ben. En daardoor alleen maar relevante informatie laten zien voor de plek waar ik nu ben. Hoe vet kun je het hebben?

 
Nou, ik zie nog wel wat voor me: ik bel het call center van mijn energiebedrijf. De medewerker ziet een realtime StreetView van mijn huis (De opvolger van het Europese Galileo-project is sinds 2 maanden live). Daarop wordt geprojecteerd waar de kabels lopen (de glasvezel ligt akelig dicht bij de gasleiding). Rechts ziet hij de factuurstatus grafisch weergegeven (een nette betaler). Met een Minority-Report-achtige handbeweging beweegt hij voorwaarts naar mijn pagina’s op Google+ en Facebook. Links is een gespreksanalyse gaande, die ook empathische vervolgvragen suggereert passend bij de communicatietheorie (verdikkeme, de juiste Krauthammer open vervolgvraag of de juiste Krauthammer afsluiter wordt voorgesteld), en op basis van mijn tweethistorie. Ik voel me begrepen...
 
Toekomstmuziek? Een beetje wel. Maar dichterbij dan je denkt. Google StreetView kan mij nu al een recente foto van de situatie laten zien. De iPad is daadwerkelijk een magical and revolutionary device. Rapportive vult e-mails aan met informatie uit sociaal media. En met Sixth Sense technologie (bekijk het filmpje!) wordt de werkelijkheid al aangevuld in het laboratorium. 
 
Nog even en eindgebruikers hebben daadwerkelijk de macht van tovenaars! 

Projecten en architecten gaan prima samen

Projecten en allerlei vormen van ICT-architecten vormen in de praktijk vaak een wat onhandige combinatie. Er wordt in ieder geval veel over geklaagd in mijn omgeving. Zou daar wat aan te doen zijn?

 
"Ben ik net lekker bezig met een project, komt er een architect langs die zegt dat het anders moet"
 
Je kent de situatie wel. Je hebt een idee voor een nieuwe dienst en weet dat daar veel behoefte voor is. Gelukkig denken meer mensen binnen je organisatie dat ook, en je start een project om de boel op te zetten. Er moet wel een nieuw stukje website ontwikkeld worden, maar niemand ziet daar veel problemen in. Eind goed, al goed. Alleen, een paar weken later krijg je een telefoontje. Van een architect die even wil bijpraten over je project. Tijdens dat gesprek blijkt dat je mooie webuitbreidingen eigenlijk helemaal niet kunnen. Dat het op deze manier niet binnen het huidige informatie- en ICT-beleid past.  Er moet nu fundamenteel opnieuw over het project nagedacht worden. Je staat perplex. Kan dit inderdaad zo maar gebeuren?  En kan het niet anders? 
 
Natuurlijk kan zoiets anders. Bovenstaand voorbeeld is een typisch geval van te weinig afstemming tussen de architectuurfunctie en de projectorganisatie. Vaak ontstaat dit hoog in de organisatie. Verschillende managers krijgen dan verschillende doelen mee, die niet op elkaar afgestemd worden. Zo zal de gemiddelde business manager gaan zorgen voor meer omzet, minder kosten of meer marge. En de CIO zorgt ondertussen voor meer kwaliteit in de informatievoorziening, tegen minder kosten. Iedereen blij, natuurlijk. 
 
In projecten blijken deze doelen regelmatig tegenstrijdig. Want meer omzet kan prima lukken met een nieuwe dienst. Die even snel via een nieuwe website in de markt wordt gezet. Als die website echter met nieuwe technologie wordt gemaakt, dan ziet de CIO plotseling extra licenties, extra beheer en extra diversiteit in zijn portfolio opduiken. Iets wat zijn of haar architecten zullen tegenhouden.
 
De uitweg uit deze impasse in tweeërlei. Zorg ten eerste dan in ieder businessproject zo snel mogelijk een architect betrokken is. Een dooddoener, denk je. Maar ik zie nog steeds legio projecten waar dit niet gebeurt. Aangezien architecten de bedrijfsbrede doelarchitectuur kennen, kunnen zij adviseren over een maakbare, en haalbare oplossing. Ten tweede: architecten mogen geen architectuuroplossingen inbrengen die niet binnen de looptijd van het project te realiseren zijn. Loopt het project een jaar? Dan kan het niet zo zijn dat projectresultaten moeten voldoen aan een doelarchitectuur die pas over drie jaar gaat gelden. Architecten zullen dus, of op projectbasis, of bedrijfsbreed, moeten toewerken naar aan realistisch architectuurdoel. Geen luchtkastelen waarbij alles tegelijkertijd op de schop moet, maar haalbare doelarchitecturen die de kwaliteit van de informatievoorziening telkens een stapje verbeteren.

Architect en architectuurdomeinen

Ieder zichzelf respecterend architectuuraamwerk kent architectuurdomeinen. TOGAF houdt het bij business, application, data en technology architecturen. DYA gebruik Product, Proces, Organisatie, Gegevens, Applicatie, Middleware, Platform en Netwerk. Zachman gebruikt Data, Function, Network, People, Time en Motivation.

Domeinen gebruik je om een probleem of oplossing inzichtelijk te kunnen vormgeven. De meeste problemen en oplossingen zijn niet triviaal. Daardoor zijn ze moeilijk in één plaat te presenteren (ook al denken veel managementguru’s dat iets niet bestaat als het niet in een 4-kwadranten model weer te geven is).
 
Kerncompetenties van een goede architect zijn om te kunnen bepalen welke domeinen nodig zijn het probleem inzichtelijk te presenteren (maak niet de fout om altijd alle domeinen te gebruiken), om te bepalen in welk domein de oplossing primair gevonden gaat worden (soms los je iets op met een betere applicatie, soms met een andere organisatie-inrichting, soms met een verandering van technologie), en hoe de oplossing vanuit haar primaire domein doorwerkt in de andere domeinen (een organisatie met kenniswerkerfuncties heeft niets aan een gedetailleerd werkend workflowmanagement systeem).

Informatieinnovatie bij de uitvoering van de WMO

De uitvoering van de WMO moet goedkoper. Dat kan natuurlijk op velerlei manieren gerealiseerd worden. Goedkopere middelen of minder middelen inzetten is bijvoorbeeld een methode. Maar, dergelijke maatregelen leiden vaak ook tot verschraling van de dienstverlening. Creatieve en innovatieve oplossingen zijn vaak goedkoper en zijn vaak kwalitatief beter van aard. 

De Kanteling
 
In het WMO-project De Kanteling van de Vereniging van Nederlandse Gemeenten wordt een model uitgewerkt dat aangeeft hoe gemeenten aan de wettelijke compensatieplicht kunnen voldoen. Gemeenten hebben binnen de WMO veel ruimte om hun eigen beleid te maken. In De Kanteling staat het te behalen resultaat voorop.
 
Een voorbeeld van een resultaat is: Iedere burger kan zich verplaatsen in, om en nabij het huis. Dit resultaat kan op verschillende manieren worden bereikt. Een cliënt kan bijvoorbeeld vragen om een bromscooter. Een gemeente kan er voor kiezen om simpelweg aan die vraag van de cliënt te voldoen. In De Kanteling wordt echter voorgesteld om in gesprek te gaan met de cliënt en om zodoende achter de vraag achter de vraag te komen. Wellicht blijkt uit het gesprek dat een cliënt bijvoorbeeld meer geholpen is met een aanvullend openbaar vervoer voorziening. Door op maat creatieve oplossingen te bieden en toch hetzelfde resultaat voor de cliënt te bereiken kan er kwalitatief een goede dienstverlening worden geleverd tegen lagere kosten.
 
De Kanteling wordt door veel gemeenten nu ingevuld door cliënten heel persoonlijk te benaderen bij een aanvraag. Vaak door bij de cliënt thuis langs te gaan en in gesprek te gaan met de cliënt. Voor veel gemeenten is dit een goede oplossing. Echter, opschaling naar grotere hoeveelheden aanvragen is voor een dergelijke oplossing een dure aangelegenheid. Voor grotere gemeenten zou het betekenen dat je een klein legertje ambtenaren nodig hebt om alle WMO aanvragen af te handelen. Automatisering kan helpen om grote hoeveelheden aanvragen met minder mensen af te handelen.
 
Automatisering van de uitvoering
 
Bij een grote gemeente als de gemeente Amsterdam blijkt dat 85% van de cliënten een enkelvoudige aanvraag doet. Door gebruik te maken van beslisbomen, geautomatiseerde processen en een sterke integratie met ketenpartners probeert de gemeente Amsterdam een cliënt zo snel als mogelijk te voorzien van de meest geschikte WMO voorziening. Een vervoerspas heeft een cliënt vaak al de volgende dag in huis en hulp bij het huishouden staat vaak al binnen 5 dagen bij de cliënt voor de deur. De overige cliënten hebben een meer complexe hulpvraag die door de gemeente Amsterdam minder geautomatiseerd wordt afgehandeld. Voor deze cliënten worden maatwerk voorzieningen geleverd. De gemeente Amsterdam heeft zo een proces ingericht dat eenvoudig is daar waar het kan en dat uitgebreid maatwerk levert daar waar nodig.
 
Geautomatiseerde processen bieden ook de mogelijkheid om over de verzamelde gegevens van geleverde voorzieningen analyses uit te voeren. Hierdoor kan er gericht naar mogelijkheden voor verbetering of kostenbesparing gezocht worden. 
 
Innovatie in de WMO uitvoering
 
Er is nog volop ruimte voor innovatie bij de uitvoering van de WMO. Gemeenten beginnen nog maar net de mogelijkheden te ontdekken van de ruimte die hen geboden wordt om de WMO uit te voeren. Zelf geef ik altijd als voorbeeld dat een gemeente bijvoorbeeld zou kunnen kijken naar hoe zij faciliterend kan zijn in het bij elkaar brengen van zorgvraag en zorgaanbod. Mensen zijn altruïstisch ingesteld en helpen elkaar graag. Wellicht is er iemand in de buurt die bereid is om iedere week een aantal mensen op te halen voor het wekelijkse bridge-avondje. Wellicht bespaart dit wel een aantal aanvragen voor aanvullend openbaar vervoer. Een gemeente kan bijvoorbeeld een marktplaats-achtige website inrichten waar zorgvraag en zorgaanbod bij elkaar kunnen worden gebracht. De gemeente faciliteert in dit geval slechts dat mensen elkaar kunnen helpen. Tegelijkertijd staat de gemeente door het aanbieden van een "zorg-marktplaats" midden in de WMO-samenleving. Door het vraag- en aanbodproces via de "zorg-marktplaats" te volgen kan een gemeente inspringen op trends en wellicht zelfs nieuwe voorzieningen in het leven roepen of beleidsaanpassingen doorvoeren.
 
De WMO biedt gemeenten veel ruimte om haar eigen WMO-beleid op te stellen. Dit biedt ruimte voor creatieve en innovatieve oplossingen passend bij de individuele situatie van de burger. Automatisering kan helpen om de kosten in de hand te houden en om regie te voeren. Daarbij is het de uitdaging om eenvoudig en snel te leveren daar waar het kan en uitgebreid maatwerk te leveren daar waar het moet. Caerleon denkt graag met u mee over creatieve en innovatie oplossingen om de WMO efficiënt uit te voeren.
 
Berry Groenendijk
Informatiearchitect
 
Disclaimer: Profict, net als Caerleon onderdeel van de Profict Groep, heeft voor de gemeente Amsterdam het administratieve systeem gebouwd dat de Dienst Wonen, Zorg en Samenleven ondersteunt bij het uitvoeren van de WMO.

Wat doet een architect?

Architect is in de digitale wereld een nogal „overloaded" begrip. Het betekent voor verschillende mensen verschillende dingen. Daarom hier mijn beeld.

Voor mij is een architect iemand die het globale ontwerp neerzet voor de oplossing. Dat ontwerp is wel precies, maar niet gedetailleerd. Bijvoorbeeld bij een software architect: het is de opdeling in componenten, de definitie van hun samenwerking (via provided en required interfaces) en de definitie van die interfaces. Het is niet de inhoud van componenten (class niveau). Het is dus niet gedetailleerd (geen klasse-opdeling), maar wel precies (interfacespecificaties). En ik zou via stubs de globale werking van het systeem kunnen prototypen. Software is echter maar een deel van de oplossing, en idealiter beschrijft het globale ontwerp de totale oplossing. 
 
In het globale ontwerp zitten beslissingen over hoe de oplossing in elkaar zit, zowel constructief (bv gebruik van één-loket gedachte, gebruik OO paradigma), als functioneel (denk aan de begrenzing van het probleem, maar ook aan XP's metafoor) als technisch (denk aan allerlei gekozen (outsourcing)partners en tools). Hiervoor is het begrip „enterprise architectuur” bedacht. Een enterprise architect is iemand die de oplossingsrichting vorm geeft over allerlei domeinen heen.
Verder geeft de globale oplossing aan, liefst expliciet (maar minstens impliciet) welke detailontwerpen toegestaan zijn (en welke uitgesloten worden). De globale oplossing is een leidraad naar een goede oplossing (eindproduct met vooraf gedefinieerde kwaliteit), en maakt het ook mogelijk om die goede oplossing op een goede manier te bereiken (het stuurt de proces-/projectinrichting). 
 
In de rol van architect zitten nog wel wat onduidelijkheden:
  • Het verschil tussen ontwerper en architect: is mijnerzijds een kwestie van schaal, zoals de RUP software architect ook gewoon een senior ontwerper genoemd zou kunnen worden.
  • Het verschil van aandachtsgebied: je kunt een probleem oplossen door een keten, een bedrijfsinrichting, een informatievoorziening of technologie te veranderen. En meestal verandert alles tegelijkertijd. Wie houdt er overzicht over of al die veranderingen passen binnen de gekozen globale oplossingsrichting? Is dat de enige echte architect??
  • Het verschil in scope: ben je al architect als je het globale ontwerp van een systeem neerzet, of ben je pas architect als je het globale ontwerp voor een familie van systemen neerzet?
  • De balans tussen abstract en concreet: hoe meer je architectuur iets generiekers moet zeggen, hoe minder concreet het wordt, en hoe minder makkelijk de architectuur te vertalen valt naar een concrete oplossing in een project. Vanuit de gegevensgerichte "wereld" spreken we over het "datamodel voor alles" probleem: er is een datamodel te maken met twee entiteiten en twee relaties waarin de hele wereld te modelleren valt. Alleen heb je daar dus niets meer aan, want het levert geen overzicht, samenhang, et cetera meer op.
 
Vervolgens zijn er een aantal uitdagingen die de architect aan mag gaan:
  • Veel mensen weten niet hoe een goed eisenpakket er uit ziet. Vaak wordt eisenpakket verward met functionele eisen. Maar niet-functionele eisen (zie bijvoorbeeld ISO 9126) en allerlei constraints (tijd, geld, kennis, capaciteit, middelen) bepalen ook hoe de oplossing er uit kan zien. Als je maar een deel van de eisen kent, kun je nooit tot een goede oplossing komen.
  • Veel mensen kunnen alleen maar concreet denken, en niet abstract. Dus een geïmplementeerde applicatie met zichtbare schermen snapt men, maar een domeinmodel van waar het in de organisatie om gaat snapt men niet. Denk bijvoorbeeld aan een opleidingsorganisatie waar de cursusadminstratie, de projectenadministratie, de financiële administratie en de agenda van trainers allemaal over dezelfde domeinconcepten gaan, maar deels verschillend geïmplementeerd zijn, (deels) niet-synchroon lopen, en in feite allemaal onbeheersbare kopieën bevatten van in essentie dezelfde domeinconcepten (cursist, factuur, cursusuitvoering, trainer, materiaal, budget, realisatie).
  • Veel mensen kunnen niet omgaan met onzekerheid en durven geen keuzes te maken op onvolledige informatie. Dit fenomeen wordt versterkt door het watervaldenken, waarachter de filosofie zit dat als je maar genoeg details hebt, je alles in één keer goed kunt doen. Een architect probeert wel zo snel mogelijk tot een oplossingsrichting te komen, maar zal onderweg moeten bijsturen. Dat laatste wordt a) meestal vergeten b) als onelegant beschouwd en c) dus liever niet gedaan want daar score je niet mee. En bij wijzigingen in je huidige implementatie, zouden alle bestaande implementaties ook gewijzigd moeten worden, om synchroon te blijven met het betere begrepen domeinmodel. 
 
Misschien toch wel een beetje een schaap-met-5-poten-rol, zo’n architect. Ik blijf dus dromen dat het nog eens echt goed wordt gedaan....

De cloud tegenbeweging

Cloud services kennen veel voordelen, vooral kostentechnische voordelen. Maar, ook nadelen. Zo zijn vele cloud services gebaseerd op open source software, maar is de cloud service zelf niet open source. Het gevaar bestaat dat er nieuw soort lock-in ontstaat. Kijk bij het afnemen van cloud services dan ook goed naar de juridische voorwaarden en hoe open de service is. Bijvoorbeeld: Heeft de service de mogelijkheid om uw eigen data weer uit het service op te halen?

Voor iedere beweging is er ook een tegenbeweging en zo ontstaat er inmiddels een beweging die streeft naar volledig gedistribueerde tegenhangers van bekende gecentraliseerde diensten als Facebook, Twitter, etc. 
 
Unhosted bijvoorbeeld streeft ernaar om webapplicaties te decentraliseren. In de Unhosted architectuur wordt dit bereikt door de data te ontkoppelen van de webapplicatie. De data wordt per gebruiker, volledig versleuteld opgeslagen in de cloud op een door de gebruiker gekozen plek. De webapplicatie waarmee de data kan worden bekeken en bewerkt draait volledig in de browser van de gebruiker. Bij traditionele webapplicaties, zoals Google Docs of Twitter, heeft de eigenaar van de website de (theoretische) mogelijkheid om de data van de gebruiker van de dienst, een document of een tweet, in te zien. In de opzet van Unhosted heeft de gebruiker cq. de eigenaar van de data te allen tijde volledige controle over zijn/haar gegevens en is het ongewild inzien van de data onmogelijk geworden. 
 
De beweging naar volledig gedistribueerde applicaties is ook gaande voor microblogging services als Twitter. Identi.ca biedt dezelfde functionaliteit als Twitter, maar is een volledig gedistribueerde dienst op basis van open source software die niet door één organisatie of bedrijf wordt gecontroleerd.
 
Eén van de meest recente initiatieven is het Freedom Box concept van Eben Moglen. De Freedom Box bestaat uit software die draait op een zogenaamde plug-server. Een plug-server is een klein en goedkoop apparaat dat direct in een stopcontact wordt gestoken. De software in de Freedom Box maakt het mogelijk om veilig aan gedistribueerde sociale netwerken deel te nemen, anoniem informatie te publiceren, versleuteld te e-mailen en om volledig versleuteld met andere te kunnen bellen. De Freedom Box verzekert iedere burger ervan dat deze, ook in deze digitale wereld, gemakkelijk, veilig en zonodig anoniem kan communiceren en informatie kan delen met andere burgers.
 
Cloud services bieden bedrijven vele voordelen, maar zullen niet voor iedereen de juiste oplossing betekenen. Volledig gedistribueerde oplossingen kennen bijvoorbeeld vaak een betere bescherming ten aanzien van de eigendom en privacy van (persoonlijke) gegevens en data. De cloud tegenbeweging kent vaak innovatieve oplossingen ten aanzien van informatie- en databeheer die veelal tijd nodig hebben om gemeengoed te worden. Het is een beweging om in de gaten te houden en om van te leren.
 
Berry Groenendijk
Informatie architect