Blog van joost.lommers
Mobiele touch-based devices vaker inzetbaar dan je denkt
joost.lommers 19 Dec 2011In 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
joost.lommers 05 Dec 2011„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
joost.lommers 27 Nov 2011In 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:
- Een mobiel device zoals een smartphone heeft kleinere schermafmetingen en minder pixels dan een desktop- of laptopcomputer, de meeste tablets ook
- 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
- 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?
joost.lommers 08 Sep 2011Als 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
joost.lommers 28 Aug 2011Iedere 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
joost.lommers 07 Aug 2011Projecten 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
joost.lommers 31 Mei 2011Ieder 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).
Wat doet een architect?
joost.lommers 10 Apr 2011Architect 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....
Goede architecten zijn agile - en goede archituren zijn to-the-point
joost.lommers 09 Feb 2011Vorige week kwam ik weer in de geijkte discussie terecht: we hadden het over het maken van een doelarchitectuur, en direct was er iemand die "geen tijd wilde besteden aan het zinloos uitwerken van een hele architectuur". Ik snap zo'n reactie niet. Waarom zou een doelarchitectuur een "hele" architectuur zijn? Wat is "heel" eigenlijk? Het klinkt als veel werk, in ieder geval. En dat bedoelt de spreker ook vaak: architecturen kosten te veel werk! En dan is het uitwerken er van ook nog "zinloos"! Goh, denk ik dan, hoeveel architecten zouden graag veel tijd steken in iets wat door hun omgeving als zinloos wordt gezien?
Mensen die architectuur ervaren als veel werk, hebben ervaring met de verkeerde architecten. Beter geformuleerd: ze hebben ontwerpers of engineers mee mogen maken die zich voordeden als architect - die hebben behoefte aan (te veel) detail. Of ze zijn iemand tegengekomen die doel en middel niet uit elkaar weet te houden - het te leuk vindt om architectuur te maken om de architectuur zelf. Maar in de gemiddelde bedrijfssituatie is architectuur altijd een middel, en geen doel op zich.
Een goede architect is per definitie agile. Bedenkt niet meer dan nodig is. Op het moment dat het nodig is. Je hoeft geen architectuur van 400 pagina's te maken als je de informatievoorziening wilt laten groeien naar een servicegeoriënteerd applicatielandschap. In eerste instantie zijn 4 pagina's meer dan genoeg. Vervolgens zien we wel weer verder. Een goede architectuur is per definitie doelgericht. Een organisatie wil iets bereiken, een architectuur geeft richting aan hoe dat kan. Niet meer, maar ook niet minder.
Zoals Ruud van Vliet, Arjen Uittenbogaard en ik al schreven voor het Landelijk Architectuur Congres 2006: "Een architect is geen showstopper, geen boe-roeper, geen luchtfietser. Helaas komen we hem maar al te vaak in een of meer van die rollen tegen. Wij menen dat dit heeft te maken met gebrek aan ‘agility ’! Een agile architect weet dat een architectuur niet in beton gegoten is, dat standaarden aangepast kunnen worden en dat minder regels beter is dan veel regels. Een agile architect weet dat je de effectiviteit van een architectuur alleen maar kunt beoordelen tijdens de toepassing ervan."
Zie ook hoofdstuk 4, De Agile Architect, in het boek "Wendbaarheid door Architectuur".
Een architect is geen "business preventer". Hij of zij geeft juist inzicht in total cost of ownership en total (IT) risk of ownership. Waarna de opdrachtgever mag bepalen of deze kosten en risico's door de organisatie gedragen kunnen worden.
T-Mobile kan wel wat informatie innovatie gebruiken
joost.lommers 20 Jan 2011Het jaar 2010 ligt alweer achter ons. Voor T-Mobile een jaar om te vergeten: structurele problemen met het mobiele netwerk in mei en juni. Op de korrel genomen door Youp van het Hek voor hun slechte service. En sinds november geen alleenrecht meer op het verkopen van de Apple iPhone. Het zal je jaar maar zijn! Gelukkig werden ze daardoor wel genoemd in iedere oudejaarsconference.
Jammer genoeg heb ik dit jaar ook de "service" van T-Mobile voor het eerst mogen meemaken. En ik kan je vertellen: T-Mobile kan wel wat informatie innovatie gebruiken.
Youp stuurt vooral aan op het verbeteren van de klantenservice. Mijn beeld is dat T-Mobile in haar huidige situatie nooit in staat zal zijn tot een optimale klantenservice - hoe lief de call center medewerker of medewerkster mij ook vraagt "of mijn probleem hiermee is opgelost". Het call center wordt in haar klantenservice namelijk beperkt door het productmodel van T-Mobile, en daarvan afgeleid, haar informatiesystemen.
T-Mobile denkt namelijk helemaal niet in "klanten" - T-Mobile denkt in "contracten". En het zal je maar gebeuren dat je drie van die contracten hebt. Zoals ik dit jaar...
Het eerste dat je moet weten, is dat een prepaid-contract iets heel anders is dan een abonnement-contract. Dat blijkt als je een abonnement neemt, en je vervolgens je prepaid-nummer naar dat abonnement wil overzetten (nummerbehoud). Dit doe je via een belletje naar de klantenservice. Alleen, als je eenmaal hebt aangegeven dat je het prepaid-nummer wilt overzetten, kan de vriendelijke mevrouw je daarna niet verder helpen met andere vragen over je abonnement. Ze is namelijk van de "prepaid klantenservice", en om de "abonnementen klantenservice" te bereiken, mag ik opnieuw (hetzelfde) nummer van de T-Mobile klantenservice bellen. Dan zegt het voice response systeem: "de wachttijd bedraagt momenteel meer dan 5 minuten". Heel klantvriendelijk om mij zo te informeren. Jammer genoeg had ik nog geen 20 seconden geleden een medewerker van T-Mobile aan de lijn. En waarom zouden er niet genoeg medewerkers kunnen zijn om alle klanten te woord te staan? Of, waarom kan T-Mobile haar diensten niet gewoon in één keer goed uitvoeren? Dit is het eerste bedrijf waar ik als klant in de eerste 6 weken zeker twaalf keer met de klantenservice heb gebeld.
Vervolgens blijkt dat ik op My T-Mobile - de self-service website - een nieuwe loginnaam moet aanmaken. Want mijn bestaande loginnaam is gekoppeld aan het prepaid-contract. En daar kun je geen abonnement-contract aan koppelen. En als ik eenmaal een nieuwe loginnaam heb aangemaakt, krijg ik het loyalty-programma met spaarpunten niet geactiveerd. Zonder mijn aanmelding te accepteren, en zonder foutmeldingen, stuurt de site me telkens terug naar de beginpagina. Gelukkig kan de klantenservice het wel voor mij activeren. En vriendelijk dat ze dat doen. De mevrouw kan zelfs vertellen wat er aan de hand is: de site herkent mijn telefoonnummer automatisch als een prepaid-nummer. En daar kan het natuurlijk geen loyalty-programma voor abonnementen aan koppelen. Grrrrrrrrr.
Hier helpt alleen het verbeteren van de klantenservice al lang niet meer. T-Mobile moet uit het productgerichte tijdperk stappen, en fundamenteel vanuit haar klanten gaan denken. En haar productontwerp hierop modelleren. Want alleen dan kan de informatievoorziening, en daarmee de service, ook volledig rondom de klant en zijn of haar levenscyclus bij T-Mobile gemodelleerd worden. Dan pas zie je de "life events" van een klant die zijn prepaid telefoon wil omzetten naar een abonnement. En op dat moment geen enorme "disconnect" bij T-Mobile wil meemaken.
Hé Joost, je had toch drie contracten? Inderdaad! Dank je wel voor je aandacht. Ik had naast mijn prepaid-contract en mijn abonnement-contract ook nog een contract voor een prepaid Internet Stick. En ook daarvoor heb ik mijn gegevens, opnieuw, op de website van T-Mobile ingevoerd (want zo'n Stick kan ik natuurlijk niet toevoegen aan mijn bestaande loginnaam). Alleen... de installatie op mijn Mac liep niet lekker; en de klantenservice kwam er ook niet uit. Sindsdien gebruik ik 'm maar niet. En nu zit ik te wachten op een e-mailtje van T-Mobile. "Geachte heer Lommers, wij constateren dat u uw Internet Stick niet gebruikt. Wat is er aan de hand? Hoe kunnen wij u helpen om toch MB's bij ons te gebruiken en te betalen?". Ik hou ondertussen mijn adem niet in...
