Gebruikers Betrekken Onderzoekspaper. In opdracht van: Sogeti Nederland. Peter Vermeulen Pb7 Research 30 oktober 2014

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


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


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


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


Tabel 3: Directe kosten van softwarefouten

Productiviteit/omzet waarvan productiviteit B2C Ecommerce transacties Totaal

EUR Mln 1542 1020 61 1603


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


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


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%


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


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


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


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


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%


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%


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


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%


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%


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%


13-10-2014


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


•

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.”


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.”


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.


3/3

Gebruikers Betrekken Onderzoekspaper. In opdracht van: Sogeti Nederland. Peter Vermeulen Pb7 Research 30 oktober 2014

Recommend Documents