rapport + aanbevelingen

Gebruikers Betrekken
Onderzoekspaper
In opdracht van: Sogeti Nederland
Peter Vermeulen
Pb7 Research
30 oktober 2014
[email protected]
Gebruikers Betrekken
Inhoud
Inhoud ............................................................................ 1
Inleiding .......................................................................... 2
1. Het Belang van Excellente Software........................... 3
2. Hoe worden gebruikers betrokken: perceptie
versus realiteit ................................................................ 6
3. Voordelen en valkuilen ............................................... 8
4. Aanbevelingen .......................................................... 11
13-10-2014
1
Gebruikers Betrekken
Inleiding
De vraag naar software onder Nederlandse organisaties neemt sterk toe. Zonder software
kan geen grote organisatie overleven. Software is nodig om primaire en secundaire
processen kosten-efficiënt uit te kunnen voeren, software is nodig om de klant te bereiken
en te verleiden, en software is nodig om nieuwe producten en diensten te ontwikkelen.
Software staat aan de basis van vrijwel alle grote sectortransformaties die we kunnen
waarnemen en voor de komende decennia verwachten.
Waar mogelijk gebruiken organisaties standaard software oplossingen, al dan niet uit de
cloud. Maar ook de rol van maatwerksoftware wordt alsmaar belangrijker. De grote
schaarste voor software ontwikkelaars met diverse specialisaties zoals Java is geen toeval.
Waar standaard software vooral uitblinkt in het automatiseren van gebaande paden op basis
van best practices en het bieden van standaard bouwblokken, biedt maatwerksoftware de
mogelijkheid om te differentiëren en snel in te springen op nieuwe kansen die om ons heen
ontstaan. Maatwerk software ontwikkeling is lang niet altijd, maar wel steeds meer een
tactische aangelegenheid. Het is dan ook logisch dat de traditionele watervalmethode in
veel gevallen vervangen wordt door “Agile” methoden van software ontwikkeling.
Software ontwikkeling is een uiterst bedrijfskritische bezigheid geworden waar fouten
verstrekkende gevolgen kunnen hebben. En terwijl we nog altijd moeite hebben om
softwareprojecten waar we jaren over mogen doen succesvol af te ronden, verlangen we nu
een steeds grotere snelheid. De software die wordt opgeleverd mag niet teveel technische
fouten bevatten en moet zo intuïtief zijn dat de gebruiker er snel en eenvoudig mee kan
werken. Het vergt wel een bijzonder knap ontwikkelteam om dat laatste te bewerkstelligen
zonder nauw samen te werken met diezelfde gebruiker. Maar het is lang niet voor ieder
duidelijk wanneer en op welke wijze de gebruiker betrokken moet worden.
Om meer zicht te krijgen op waar Nederlandse organisaties staan in het succesvol betrekken
van gebruikers, heeft Sogeti Nederland Pb7 Research gevraagd om in kaart te brengen wat
de impact is van technische en vooral ook functionele softwarefouten, op welke wijze
gebruikers betrokken worden en welke verbeteringen mogelijk zijn. Het onderzoek is
gebaseerd op een web panel gebaseerde survey in september/oktober 2014 onder ITbeslissers en IT-gebruikers (ook wel als “professionals” aangeduid) die werkzaam zijn bij
Nederlandse organisaties met 500 of meer medewerkers. Ook zijn enkele vragen vanuit een
consumentenperspectief aan deze IT-gebruikers gesteld en zijn deze vragen ook aan
willekeurige consumenten gesteld. De groepen zijn ten opzichte van elkaar gewogen om een
representatieve uitkomst te verkrijgen.
Tabel 1: Steekproefverdeling
IT-beslisser
Consumenten
waarvan professionals
Totaal
Totaal
150
301
209
451
Publieke sector
44
93
81
137
Bedrijfsleven
106
208
128
314
Bron: Pb7 Research, 2014
13-10-2014
2
Gebruikers Betrekken
1. Het Belang van Excellente Software
De kwaliteit van software is een belangrijke asset voor iedere grote Nederlandse organisatie.
De afhankelijkheid van software is dermate groot geworden dat softwarefalen al snel leidt
tot productiviteitsverlies en gederfde omzet of, in het geval van de publieke sector, het niet
kunnen voldoen aan rechten op hulp en zorg. Maar ook het geld dat wordt besteedt aan
applicaties die nooit in gebruik worden genomen, leidt tot loze IT-kosten en vormen een rem
op proces- en productinnovatie.
Om het concreter te maken, brengen we een onderscheid aan tussen technisch falen (het
werkt niet) en functioneel falen (we kunnen er niet mee werken). Technisch falen kan zich
op diverse wijzen uiten: zo kunnen berekeningen verkeerd worden uitgevoerd, transacties
onjuist worden verwerkt, of functioneert de applicatie simpelweg niet waardoor de
gebruikers niet langer is staat zijn om productief te zijn. Het laatste hebben we
gekwantificeerd.
Om een model te bouwen waarin we kunnen berekenen wat de kosten zijn van downtime
als gevolg van softwarefouten hebben we gevraagd voor welke doelgroepen software wordt
ontwikkeld, in welk deel van die gevallen werk stil kwam te vallen en hoe lang die storingen
duurden. Door dit met elkaar te vermenigvuldigen, kunnen we berekenen hoeveel uren een
organisatie gemiddeld kwijt is aan storingen die het gevolg zijn van softwarefouten.
Tabel 2: Uitval als gevolg van softwarefouten
Q3: Voor welke van de volgende doelgroepen wordt er binnen uw organisatie, door u zelf, dan wel door een
derde partij, software ontwikkeld?
Q4: In welke van de volgende doelgroepen heeft in de afgelopen maanden het werk (deels) stilgelegen als
gevolg van fouten in de software?
Q5: Hoe lang duurde deze storing(en) bij elkaar in deze 12 maanden?
Maatwerk
software
ontwikkeling
Werk stil door
maatwerk SWfouten
Hoe lang ligt
werk stil per
jaar?
44
59
26
34
47
47
36
35
22
16
17
24
Staf
Lijn
Ketenpartners
Consumenten
Uren uitval
gemiddeld per
Nederlandse
organisatie
4,5
4,3
1,6
2,8
Bron: Pb7 Research, 2014
We hebben ook professionals uit de staf en de lijn gevraagd met hoeveel uitval zij denken te
maken hebben gehad in de laatste 12 maanden als gevolg van softwarefouten en kwamen
uit op 4,4 uur, exact in overeenstemming met de inschatting van IT-beslissers. Door te
berekenen voor hoeveel Bruto Toegevoegde Waarde deze verloren uren verantwoordelijk
zijn, komen we op een totaal aan gederfde inkomsten van ruim EUR 1,5 Miljard. Ruim een
miljard Euro daarvan is toe te wijzen aan productiviteitsverlies (berekend als de totale
arbeidskosten van de verloren uren).
13-10-2014
3
Gebruikers Betrekken
Tabel 3: Directe kosten van softwarefouten
Productiviteit/omzet
waarvan productiviteit
B2C Ecommerce transacties
Totaal
EUR Mln
1542
1020
61
1603
Bron: Pb7 Research, 2014
Door op een vergelijkbare wijze de uitval van consumentenapplicaties door te rekenen in
verhouding tot de totale hoeveelheid online uitgaven door consumenten (volgens de Thuis
Winkel Monitor 2013), wordt er nog eens EUR 61 miljoen aan B2C ecommerce transacties
misgelopen op jaarbasis. Een deel hiervan zal alsnog plaatsvinden, vaak bij een alternatieve
leverancier.
Publieke sector kent meeste incidenten
In de onderzoeksuitkomsten vinden we één levensgroot verschil op het gebied van
technisch softwarefalen in de vergelijking van organisaties uit de publieke sector en
het bedrijfsleven. In de publieke sector vinden werkonderbrekingen als gevolg van
softwarefouten tot twee keer zo veel voor.
Figuur: Waar lag het werk stil als gevolg van software fouten?
Q4: In welke van de volgende doelgroepen heeft in de afgelopen maanden het werk (deels)
stilgelegen als gevolg van fouten in de software?
Back-office applicaties en andere software ten
behoeve van de staf
36%
Front-office, productie-applicaties en andere
software t.b.v. de lijn
38%
Ketenapplicaties
38%
33%
31%
Webapplicaties/ecommerce toepassingen
Nee, het werk heeft niet stilgelegen
30%
71%
64%
50%
51%
0% 10% 20% 30% 40% 50% 60% 70% 80%
Bedrijfsleven
Publieke sector
Bron: Pb7 Research, 2014
Consumenten, burgers en patiënten haken vaak af
De gevolgen van softwarefalen laat zich niet alleen uitdrukken in de kosten van downtime.
Er zijn gevolgen die veel meer verstrekkend kunnen zijn, zeker als we naar de relatie met
consumenten kijken. Bijna één op de drie respondenten heeft minimaal eens in het
afgelopen jaar een product uiteindelijk bij een concurrent gekocht. Indien 30% van die 30%
dat twee maal heeft gedaan, 30% van die groep drie maal, enzovoorts, dan betekent dit dat
13-10-2014
4
Gebruikers Betrekken
het uiteindelijk gaat om een bedrag van EUR 514 miljoen (4,8% van de totale online
bestedingen) dat leveranciers aan concurrent hebben gelaten, op het moment dat de
consument de credit card al in zijn hand had. Heel wat meer dus dan de 61 Miljoen die
veroorzaakt wordt door alleen de downtime als gevolg van softwarefouten. Vergeet dus niet
de kwaliteit van de keten te testen!
De beperkte loyaliteit van de consument zien we ook terug in de wereld van de app. Bijna
één op de twee consumenten heeft het afgelopen jaar één of meer apps vervangen door
een concurrerende app, omdat deze niet adequaat functioneerde. De consument is erg snel
weg. Hij kan zonder enige inspanning van de ene naar de andere leverancier switchen.
Klantloyaliteit biedt tegenwoordig vooral waarde voor de leverancier, maar nauwelijks voor
de consument.
Figuur: Onduidelijke software heeft aanzienlijke ongewenste gevolgen
Q20: Kunt u aangeven of u, als consument of burger, de volgende gebeurtenissen in de afgelopen 12 maanden
heeft meegemaakt? [Consumenten]
U zat met een hulp- of zorgvraag (voor gemeente
of zorgverlener), maar heeft daar van afgezien
omdat u er op het Internet niet uitkwam
20%
U probeerde een product via het Internet aan te
schaffen, kreeg telkens een foutmelding waardoor
u het maar elders heeft gekocht
U probeerde online een formulier in te vullen bij de
overheid, maar gaf het op omdat u er niet uit
kwam
U heeft een app op uw smartphone of tablet
vervangen door een andere app, omdat deze
telkens haperde of vastliep
30%
22%
46%
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%
Bron: Pb7 Research, 2014
De publieke sector heeft weinig last van dergelijke concurrentieproblemen. Maar de
maatschappelijk gevolgen van ondeugdelijke software lijkt aanzienlijk. Meer dan één op de
vijf burgers heeft het afgelopen jaar een formulier bij de overheid proberen in te vullen,
maar gaf het uiteindelijk op omdat men er niet uitkwam. Nog dramatischer is dat 20% van
de respondenten het afgelopen jaar heeft afgezien van een hulp- of zorgvraag omdat men er
op Internet simpelweg niet uitkwam. Het is dus niet zo dat men aangeeft een alternatieve
route te hebben gevonden: onduidelijke software staat veel burgers in de weg van het recht
op hulp en zorg.
Software op de plank
Een andere manier om te kijken naar softwarefalen, is de mate waarin software uiteindelijk
in gebruik wordt genomen. Volgens IT-beslissers wordt 1 op de 6 opgeleverde applicaties
uiteindelijk niet in gebruik genomen. Een vergelijkbaar aantal applicaties wordt uiteindelijk
alleen beperkt in gebruik genomen. Ongeveer een kwart van alle uitgaven aan software-
13-10-2014
5
Gebruikers Betrekken
ontwikkeling wordt dus uiteindelijk zinloos uitgegeven. Een aanpak waarmee dat percentage
perce
kan worden teruggedrongen, verlaagt de kosten van software ontwikkeling. Maar achter elk
falend softwareproject, gaat ook een falende optimalisatie van een proces of innovatie
schuil die noodzakelijk is voor een sterke concurrentiepositie, of het uit kunnen voeren van
nieuwe wet- of regelgeving.
Figuur: In welke mate worden opgeleverde applicaties in gebruik genomen?
Q6: In welke mate worden, bij benadering, opgeleverde softwareapplicaties ook in gebruik genomen?
Applicaties die niet in gebruik
worden genomen
16%
15%
Applicaties die beperkt (minder
dan plan) in gebruik worden
genomen
18%
51%
Applicaties worden volgens plan in
gebruik genomen
Het gebruik overtreft het plan/de
verwachtingen
Bron: Pb7 Research, 2014
Aangezien wee het hier over werkende applicaties hebben, hebben we hier voornamelijk te
maken met het functionele falen van applicaties: de gebruiker kan er niet mee uit de voeten.
Het is dan ook logisch om te onderzoeken of de samenwerking met gebruikers kan worden
geoptimaliseerd
eoptimaliseerd om dergelijk falen terug te dringen.
2. Hoe worden gebruikers betrokken: perceptie versus realiteit
Het betrekken van gebruikers bij de ontwikkeling van software is decennialang een
ondergeschoven kindje geweest bij software ontwikkeling. Het is heel lang gewoon geweest
dat de interne klant de specificaties aanleverde, dat de software grotendeels in afzondering
werd ontwikkeld en dat aan het eind een acceptatietest plaatsvond. Pas de laatste jaren
begint het besef door te dringen dat een nauwe
nauwe samenwerking wenselijk is. Gebruikers
dienen tenslotte met de software aan de slag te gaan en hoe beter de software is afgestemd
op hun behoeften en hoe intuïtiever de applicatie werkt, des te soepeler zal het proces
werken en des te meer transacties er
er uitgevoerd kunnen worden. Hoewel samenwerking
met bijvoorbeeld Agile steeds hoger op de agenda lijkt te staan, laat de praktijk zien
samenwerking nog altijd een ondergeschoven kindje is.
is
13-10-2014
6
Gebruikers Betrekken
7
De echo’s van decennia van geïsoleerde software ontwikkeling zijn te horen in de resultaten
van het onderzoek. Lang niet alle IT-beslissers (51%) en gebruikers (37%) zijn het erover eens
dat het meer betrekken van gebruikers een positief effect heeft op de kwaliteit van
software. Wel zeggen de meeste IT-beslissers (47%) en gebruikers (65%) het erover eens dat
gebruikers te weinig worden betrokken bij de ontwikkeling van nieuwe software.
Maar gebeurt dat eigenlijk wel? Volgens de meeste IT-beslissers valt dat behoorlijk tegen. De
meeste organisaties werken tijdens de ontwikkeling van software helemaal niet samen met
de gebruiker. Wel werkt men, begrijpelijkerwijs, vaker samen met softwareontwikkeling
voor interne gebruikers (staf, lijn) dan met externe gebruikers. Of dat terecht is, is overigens
maar de vraag.
Figuur: Samenwerking met gebruikers t.b.v. de ontwikkeling van software
Q7: Op welke wijze worden gebruikers betrokken bij de ontwikkeling van software voor intern gebruik (lijn,
staf) en extern gebruik (klanten, burgers, patiënten)?
In het geheel niet
19%
9%
We onderzoeken de behoeften onder potentiële
gebruikers
19%
17%
Ze leveren de specificaties
Ze leveren de specificaties en zijn doen een
acceptatietest
23%
21%
19%
20%
Op enkele vaste punten gedurende het ontwikkelproces
betrekken we (toekomstige) gebruikers
13%
7%
Gedurende het gehele proces wordt nauw samengewerkt
met een groep(je) toekomstige gebruikers
9%
23%
1%
1%
Anders
0%
Extern
5%
10%
15%
20%
Intern
Bron: Pb7 Research, 2014
Zoals we boven zagen, lijken relatief veel IT-beslissers de status quo prima vinden, terwijl
gebruikers vinden dat ze meer betrokken zouden moeten worden. Dat wordt wel heel
opvallend zichtbaar als we ook de gebruiker vragen naar hoe er wordt samengewerkt. De ITgebruiker herkent het beeld van de IT-beslisser nauwelijks. Nauwe samenwerking is de
uitzondering en zelden de regel. Als er al samengewerkt wordt tijdens het ontwikkelproces,
is het niet zo nauw. En volgens de gebruiker, leveren zij helemaal niet de specificaties, dat
doet namelijk hun manager. Van de gebruikers zegt 67% dan ook dat ze persoonlijk nog
nooit betrokken zijn geweest bij het proces van software ontwikkeling.
13-10-2014
25%
Gebruikers Betrekken
8
Figuur: Betrekken van gebruikers: perceptie versus realiteit
Q7: Op welke wijze worden gebruikers betrokken bij de ontwikkeling van software voor intern gebruik (lijn,
staf)? [IT-beslissers]
Q15: Op welke wijze worden gebruikers van uw afdeling betrokken bij de ontwikkeling van software voor
intern gebruik? [IT-gebruikers]
9%
In het geheel niet
Ze onderzoeken de behoeften onder potentiële
gebruikers
12%
We leveren de specificaties
12%
Op enkele vaste punten gedurende het ontwikkelproces
worden we betrokken
Gedurende het gehele proces werken we nauw samen
met de ontwikkelaars
7%
0%
20%
15%
14%
1%
0%
19%
21%
3%
We leveren de specificaties en doen een acceptatietest
Anders
44%
23%
Volgens IT-beslissers
Volgens IT-gebruikers
5% 10% 15% 20% 25% 30% 35% 40% 45% 50%
Bron: Pb7 Research, 2014
Zelfs als het beeld van de meer optimistische IT-beslissers juist zou blijken, valt het huidige
niveau van samenwerking behoorlijk tegen. Mogelijk zijn er valide argumenten om de
gebruiker buiten het proces te houden en wegen de voordelen niet op tegen de nadelen. Of
hebben we hier te maken met de weerbarstigheid van ingebakken gewoonten?
3. Voordelen en valkuilen
Om te bepalen welke voor- en nadelen het betrekken van gebruikers bij de software
ontwikkeling heeft, hebben we IT-beslissers én gebruikers gevraagd naar welke voor- en
nadelen ze daadwerkelijk ervaren hebben bij projecten waar gebruikers actief worden
betrokken. Wat dan allereerst duidelijk wordt, is dat de ervaringen overwegend positief zijn.
Men ervaart vooral een grotere tevredenheid van de gebruiker, een snellere acceptatie en
een productiever gebruik van applicaties. Slechts volgens een enkeling worden er in het
geheel geen voordelen gerealiseerd.
Wat opvalt is dat relatief weinig respondenten en vooral weinig IT-beslissers aangeven een
grotere tevredenheid onder externe gebruikers te hebben ervaren dankzij een sterkere
samenwerking. Deze tevredenheid is uiteraard minder zichtbaar dan de tevredenheid van
interne gebruikers, maar in het onderzoek hebben we ook gezien dat er simpelweg veel
minder met externe gebruikers wordt samengewerkt. Aangezien in het onderzoek veel
consumenten aangaven dat het gebruiksgemak nogal te wensen overlaat en duidelijk wordt
dat men het vervolgens snel opgeeft, is het belangrijk dat organisaties meer zicht en grip
krijgen op de behoeften van de externe gebruiker.
13-10-2014
Gebruikers Betrekken
9
Figuur: Voordelen van het succesvol betrekken van gebruikers
Q8: Welke voordelen heeft u ervaren als gevolg van het (succesvol) betrekken van gebruikers? [IT-beslissers]
Q17: Welke voordelen ziet u in het actief betrekken van gebruikers in het proces van softwareontwikkeling?
[IT-gebruikers]
53%
Tevreden interne gebruikers
61%
47%
52%
Beter gebruik
Snellere acceptatie
50%
27%
Tevreden externe gebruikers (klanten/burgers)
14%
Goed bereik (we bereiken beter iedereen die we willen
bereiken)
29%
18%
13%
Meer gebruik
11%
Tijdige(re) oplevering
7%
Lagere ontwikkelkosten
12%
6%
Lagere beheerkosten
5%
1%
Geen
0%
25%
14%
Volgens IT-beslissers
14%
Volgens IT-gebruikers
8%
10%
20%
30%
40%
50%
60%
Bron: Pb7 Research, 2014
De nadelen die men ervaart zijn beduidend minder uitgesproken. Volgens de helft van de
gebruikers zijn er helemaal geen nadelen, een mening die door een kwart van de ITbeslissers wordt gedeeld. IT-beslissers zijn vooral bang voor hogere ontwikkelkosten. Als
gebruikers zich ermee gaan “bemoeien”, wordt het ontwikkelproces immers een stuk
minder rechttoe, rechtaan. Bovendien kan het tot conflicten leiden.
IT gebruikers zien vooral in dat het aantal stuurmannen op een schip niet te groot moet
worden. Veel gebruikers hebben projecten voorbij zien komen waarbij de specificaties
vooral een optelsom van de wensen van de verschillende stakeholders was, zodat het
gezamenlijke doel steeds verder uit beeld raakt en het eindresultaat een applicatie voor
niemand is. We stuiten hier op de “poldervalkuil”: iedereen heeft inspraak, maar er is geen
ander gezamenlijk doel dan het compromis.
13-10-2014
70%
Gebruikers Betrekken
10
Figuur: Nadelen van het betrekken van gebruikers
Q9: Welke nadelen heeft u ervaren als gevolg van het betrekken van gebruikers? [IT-beslissers]
Q18: Welke nadelen ziet u in het betrekken van gebruikers? [IT-gebruikers]
Onwerkbare specificaties (teveel stakeholders met
verschillende belangen)
16%
Veel conflicten
15%
Het kost teveel tijd die we beter anders kunnen
besteden
22%
21%
Volgens IT-beslissers
Volgens IT-gebruikers
15%
12%
Hogere ontwikkelkosten
23%
11%
Late(re) levering
7%
Hogere beheerkosten
2%
17%
15%
25%
Geen
47%
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%
Bron: Pb7 Research, 2014
Over de hoge ontwikkelkosten die IT-beslissers zien, valt echter nog een en ander te zeggen.
Het is een reële veronderstelling dat de directe kosten van een softwareproject hoger
worden, naarmate de gebruiker meer betrokken wordt. Maar aangezien de kwaliteit van de
software er van kan profiteren, zou er minder software op de plank blijven liggen, waardoor
de totale kosten van software ontwikkeling omlaag kunnen.
Figuur: Meer samenwerken = Minder software op de plank
Q7c1: Intern - Op welke wijze worden gebruikers betrokken bij de ontwikkeling van software voor intern
gebruik (lijn, staf) en extern gebruik (klanten, burgers, patiënten)? * Q6: In welke mate worden, bij
benadering, opgeleverde softwareapplicaties ook in gebruik genomen? [optie “Op enkele vaste punten
gedurende het ontwikkelproces betrekken we (toekomstige) gebruikers” niet meegenomen vanwege een te
lage N]
Gedurende het gehele proces wordt nauw
samengewerkt met een groep(je) toekomstige
gebruikers
niet
beperkt
Ze leveren de specificaties en zijn doen een
acceptatietest
Ze leveren de specificaties
We onderzoeken de behoeften onder potentiële
gebruikers
In het geheel niet
0%
5% 10% 15% 20% 25% 30% 35% 40% 45%
Bron: Pb7 Research, 2014
13-10-2014
Gebruikers Betrekken
Dat samenwerking echt tot minder applicaties op de plank leidt, kunnen we helder
vaststellen als we deze twee variabelen met elkaar kruisen (zie figuur). Elke applicatie die
niet in gebruik wordt genomen, betekent dat een organisatieverandering niet zoals gewenst
kan plaatsvinden of dat bijvoorbeeld een product niet gelanceerd kan worden. Bovendien
zijn gebruikers, zoals we hebben gezien, in staat om er sneller en beter gebruik van te
maken, wat een positief effect heeft op de productiviteit.
4. Aanbevelingen
Niemand twijfelt aan het belang van excellente software en dat technisch en functioneel
falen ongewenst is. Een goed proces van kwaliteitszorg is voor de software ontwikkeling
binnen grote organisaties daarom geen luxe. De meeste ontwikkelaars en gebruikers zien
ook in dat ze moeten samenwerken om functioneel falen te voorkomen en als het even kan
om functionele excellentie te bereiken. Hoewel het door de populariteit van Agile
softwareontwikkeling lijkt alsof gebruikers en ontwikkelaars steeds beter samenwerken,
blijkt samenwerking tijdens het ontwikkelproces nog altijd meer uitzondering dan regel.
Voor organisaties die wel graag meer of beter willen samenwerken met gebruikers en de
omslag maar niet weten te maken, heeft Pb7 Research de volgende aanbevelingen:
•
•
•
•
Categoriseer ontwikkelprojecten en pas een risico-analyse toe: “All applications are
not created equal”. Terwijl aan de ene kant voor steeds meer applicaties
softwarefalen onacceptabel is, produceren organisaties aan de andere kant ook
steeds meer “wegwerpsoftware” die vooral aan een aantal basisvereisten moet
voldoen. Standaardiseer en optimaliseer de ontwikkeltrajecten en de betrokkenheid
van gebruikers op basis van een afweging van de baten en risico’s.
Bespaar niet op de samenwerking met gebruikers: met bovenstaande risico-analyse
zou duidelijk moeten worden dat het ontwikkelproject op papier wat langer kan
duren en wat meer budget nodig heeft als gebruikers nauw worden betrokken, maar
dat er dan behoorlijke risico’s worden genomen met betrekking tot de uiteindelijke
kosten en acceptatie. Het aantal plankliggers kan immers worden gehalveerd en de
gebruikers blijken applicatie beter te gebruiken. Stel die acceptatietest dus niet uit
tot het eind.
Voorkom onwerkbare specificaties: het intensief betrekken van gebruikers heeft
alleen zin als dat goed gestructureerd plaatsvindt. Stuur op eenduidige doelen en
communiceer deze gedurende het gehele proces helder. Breek indien nodig (en
indien mogelijk) het project op in kleinere projecten met concrete deliverables.
Onderzoek Agile methoden opnieuw en pas deze ook consequent toe: Agile software
ontwikkeling biedt voor veel toepassingen een goed framework om nauw samen te
werken met de gebruiker. Hoewel de meeste Nederlandse organisaties er inmiddels
gebruik van zeggen maken, wordt het teveel als een ontwikkelaarsfeestje gebruikt.
Voorkom zoveel mogelijk shortcuts waarbij de gebruiker uit beeld verdwijnt ten
koste van het gemak of de snelheid. Kijk opnieuw naar de beginselen van agile en
geef de gebruiker een grotere rol.
13-10-2014
11
Gebruikers Betrekken
•
Stel ook voor externe doelgroepen de gebruiker centraal en houdt het overzichtelijk:
Vooral door de complexiteit van online formulieren, haken veel consumenten,
burgers en patiënten af. Te vaak wordt vooral gekeken naar hoe
consumententoepassingen zo eenvoudig mogelijk aansluiten bij de
bedrijfsprocessen, in plaats van dat de gebruikersbeleving voorop staat.
Samenwerking met gebruikers kan dit aanzienlijk verbeteren. Onderzoek daarom
hoe beter met uw klant kan worden samengewerkt. Denk daarbij aan mogelijkheden
als co-creatie of testpanels.
13-10-2014
12
Memo Aanbevelingen
Onderzoek
Aan:
Datum:
Van:
Cc:
Kenmerk:
De ontvanger van het onderzoeksrapport
28 oktober 2014
Sogeti Nederland B.V.
Aanbevelingen
Ze zijn het roerend eens, Marco van den Brink en Jorik Abspoel: er is geen organisatie die niet
een agile methode toepast bij de ontwikkeling van software. Tegelijkertijd constateren ze dat
er wel heel veel verschillende maten van volwassenheid zijn. En dat slechts een enkeling het
aandurft de gebruiker van de software van meet af aan serieus bij een project te betrekken.
Van den Brink is directeur Testing & Quality Control bij IT-dienstverlener Sogeti. Abspoel is
verantwoordelijk voor een groot aantal klanten bij hetzelfde bedrijf. Zij onderschrijven en
herkennen de bevindingen uit het onderzoek van Pb7. “We zien dat de ketens steeds langer
worden. Software maak je niet meer alleen voor eigen medewerkers. Ook partners,
consumenten, burgers en patiënten spelen daarin een rol. Deze verschillende type gebruikers
moeten hun rol krijgen binnen het ontwikkelproces. Verontrustend vinden ze dan ook de
uitkomst dat een groot deel van de IT-beslissers eigenlijk vindt dat gebruikers weinig
toevoegen aan het ontwikkelproces. “Als je kijkt naar energiebedrijven: eigenlijk kunnen zij
zich nu alleen nog maar onderscheiden van de concurrent met hun diensten. Daarbij speelt
de online wereld een belangrijke rol. Als de website stagneert of als bepaalde toepassingen
haperen, dan staat de concurrent al klaar om de overstap te regelen voor de klant. Die
overstapdiensten gaan ongetwijfeld ook in de financiële wereld komen. Zo biedt de nieuwe
bank Knab dat nu al aan. De andere banken zullen volgen. De digitale dienstverlening kan je
maken of breken bij de consument. Daarom is het zo belangrijk de klant te betrekken bij het
bouwen van software”, stelt Abspoel.
Hoe doe je dat dan?
Houd het klein. “Dat is de tweede aanbeveling, naast het betrekken van ketenpartners: hou
het overzichtelijk. Geen grote, megalomane projecten.” Een aanbeveling die geheel past
binnen de agile denkwereld: stel met elkaar doelen vast die op korte termijn, bijvoorbeeld
binnen een sprint van twee tot drie weken, werkende software opleveren. De gebruikers
kunnen op die manier direct feedback geven. Als de ketens steeds langer worden, wie moet
dan het voortouw nemen? Van den Brink aarzelt geen moment: “Bedrijven die het goed
willen blijven doen op de markt trekken dit naar zich toe. Eigenlijk behoort
softwareontwikkeling onderdeel te zijn van de kwaliteitsprogramma's binnen de
onderneming of overheidsinstantie. Regisseer de kwaliteit, ook over de grenzen van de eigen
discipline of organisatie heen. Bedrijven en instellingen die dit oppakken en goed uitvoeren,
hebben de toekomst.”
Memo Aanbevelingen Onderzoek
1/3
Splits IT in tweeën
Voorts is het verstandig de IT-afdeling in tweeën te splitsen. “Je moet IT-gebruikers uiteraard
niet vermoeien met de keuze van een router of andere infrastructurele zaken. Ook de
software die alleen bedoeld is voor 'eigen gebruik', zoals een HR-systeem, Office-producten,
houd je binnen de eigen gelederen. Daar is al veel ervaring mee opgedaan. Natuurlijk is het
ook nuttig om gebruikers daarbij te betrekken, maar consumenten en partners hoeven zich
niet te buigen over allerlei bedrijfsprocesmatige kanten van de IT”, licht Van den Brink toe.
Splits IT in de backoffice en de frontoffice. Alle IT waar een partner, consument of burger mee
te maken krijgt, en de organisatie direct waarde oplevert, moet gestalte krijgen op een
breed podium. Tegelijkertijd moet de backoffice van een organisatie lean&mean zijn. Tegen
zo weinig mogelijk kosten zo goed mogelijk functioneren. Dus zoveel mogelijk
standaardiseren en als dienst uit de markt aanbieden. De backoffice IT is tenslotte veelal een
kostenpost. Investeer in de frontoffice, want dat genereert immers omzet of zorgt voor
tevreden burgers. De backoffice-IT-afdeling mag best huisvesten in een apart gebouw. Maar
de frontoffice-IT'ers moeten bij wijze van spreken temidden van alle marketeers zitten.
Gewoon doen
Voor het bedrijfsleven lijkt het evident dat het zijn klanten wil plezieren. Zonder klanten bloedt
de onderneming immers dood. Maar de overheid? Abspoel en Van den Brink zijn ervan
overtuigd, dat overheidsdienaren het de burger naar de zin willen maken. Dat die wens vaak
ondergesneeuwd raakt in complexiteit (zoals de Commissie Elias duidelijk heeft aangetoond)
doet niets af aan de wil om het goed aan te pakken. En bewijst eigenlijk alleen maar dat die
eerste twee aanbevelingen broodnodig zijn: betrek de burger bij het ontwikkelproces; en
houdt het klein.
“Bij een kennis van mij was een bepaalde toeslag stopgezet. Vervolgens betaalt de overheid
toch twee maanden lang onterecht de toeslag uit waarna het teveel betaalde geld weer
teruggevorderd moet worden.”, vertelt Abspoel. “De burger krijgt het gevoel dat hij niet
serieus wordt genomen. De uitvoeringskosten zijn onnodig hoog en de overheid loopt het
risico dat het bedrag niet terugbetaald wordt. Dit gebeurt niet als de burger bij het
ontwikkelproces is betrokken.”
Van den Brink ziet op dit moment een mooie taak weggelegd voor de wethouders met
maatschappelijke zorg in hun portefeuille. “Per 1 januari krijgen zij de uitvoering van het
zorgbeleid op hun bordje. Ga erop uit, betrek de burgers erbij, laat ze hun licht schijnen over
de uitvoering. Kom uit die ivoren toren.”
Memo Aanbevelingen Onderzoek
2/3
Toon lef
Het duo wijst erop, dat veel bedrijven webcare teams hebben: mensen die voortdurend
speuren naar wat over hun onderneming wordt geschreven in social media. “Reactief beleid
dat je moet ombuigen naar proactiviteit. Maak de consument eens product-owner in een
softwareontwikkelproces. Of een directielid. Toon lef!” Het kost geen moeite om
consumenten te vinden die willen meewerken. “Zij hebben namelijk belang bij het goed
functioneren van een website of dat overheidstaken naar behoren worden afgewikkeld.
Veel mensen geven nu al gratis tips naar aanleiding van hun ervaringen met een
webwinkel.” Abspoel haakt onmiddellijk aan: “Ik heb Marktplaats ooit een voorstel gedaan
om mensen actief te waarschuwen als een product waarnaar zij op zoek zijn, wordt
aangeboden. Dan hoef je namelijk niet steeds in te loggen en te zoeken. Compleet met hoe
je dat technisch zou moeten uitvoeren. Nooit iets op gehoord.” Dat brengt de volgende
aanbeveling in beeld: “Neem iedereen serieus; wees transparant met jouw bedoelingen. Leg
ook uit waarom je een bepaald voorstel niet uitvoert. Daar hebben mensen vrede mee. “
Op een rijtje
De top 6 belangrijkste aanbevelingen van Sogeti op een rij:
- Splits IT in tweeën. Dit leidt tot een ander IT-beleid voor backoffice-IT en een eigen
aanpak voor frontoffice-IT dat direct waarde oplevert voor de organisatie;
- Betrek consumenten, burgers of patiënten vanaf het begin actief bij de
softwareontwikkeling van frontoffice applicaties;
- Houd het klein;
- Voorkom onwerkbare specificaties. Neem iedereen in de keten serieus; leg ook uit
waarom je iets niet uitvoert.
- Gewoon doen (en leer van de ervaringen); toon lef.
- Kijk waar de agile methode nog verder verbeterd kan worden.
IT-dienstverlener Sogeti stelt dat organisaties die hun cultuur op deze manier weten aan te
passen toekomst hebben.
Memo Aanbevelingen Onderzoek
3/3

Download Report