RAPPORT AFSTUDEEROPDRACHT 2009

Autotechniek

RAPPORT AFSTUDEEROPDRACHT 2009 De relatie tussen RDC en de softwareleveranciers tegen het licht gehouden Softwareleverancier: van klant tot relatie

Bedrijfsnaam Student Student Bedrijfsbegeleider Docent Docent

RDC Datacentrum Dhr. E. Anwari Dhr. B. Janssen Dhr. W. Boldewijn Drs. N.G. Dutilh Mw. A.M.F. Delissen

Hogeschool van Arnhem en Nijmegen

HTS Autotechniek 2

Samenvatting Door de reorganisatie die RDC recentelijk achter de rug heeft, is de focus op de externe factoren verzwakt. Hierdoor is er minder aandacht besteed aan de relatie met de softwareleveranciers. De softwareleveranciers zijn zeer belangrijk voor RDC, aangezien deze door middel van hun softwarepakketten een groot deel van de markt voorzien van producten en diensten van RDC. Om de relatie met de softwareleveranciers op een hoger niveau te brengen moet RDC de wensen en behoeften van de softwareleveranciers in kaart brengen. Naar aanleiding hiervan is RDC een onderzoek gestart. De hoofdvraag die met dit onderzoek beantwoord moet worden is “welke stappen moet RDC ondernemen om de relatie met de softwareleveranciers te verbeteren?”. Om de hoofdvraag te kunnen beantwoorden, zijn de softwareleveranciers waar RDC mee samenwerkt in de mobiliteitsbranche in kaart gebracht. Na een deskresearch zijn alle softwareleveranciers telefonisch benaderd voor een interview. Het doel van de telefonische interviews is om een eerste indruk te krijgen van de softwareleveranciers, om te kijken welke wensen en behoeften de softwareleveranciers hebben en om te onderzoeken welk beeld de softwareleveranciers van RDC hebben. Uit de telefonische interviews is gebleken dat de softwareleveranciers voornamelijk ontevreden zijn over de testomgeving, de documentatie en de manier waarop vragen en klachten worden afgehandeld door de helpdesk van RDC. Om te achterhalen door welke factoren er ontevredenheid ontstaat bij de softwareleveranciers zijn er verdiepende interviews afgenomen met vier softwareleveranciers. Hierbij zijn de punten die uit de telefonische interviews naar voren zijn gekomen nader onderzocht (de documentatie, de testomgeving en de afhandeling van vragen en klachten). Met de verdiepende interviews is er niet alleen gekeken welke factoren ontevredenheid veroorzaken, maar ook wat de softwareleveranciers zelf als oplossing zien. Dit wordt in de aanbevelingen meegenomen. Uit de verdiepende interview zijn enkele zeer kritische reacties naar voren gekomen. Naast de markt interviews zijn er ook interne interviews afgenomen. Door beide kanten van het verhaal te horen is er is er een compleet beeld ontstaan. De interne interviews zijn, samen met de telefonische en de verdiepende interviews, gebruikt voor het opstellen van een SWOT analyse. De SWOT is zo breed mogelijk gehouden om een meerwaarde te creëren voor RDC. In de SWOT analyse wordt er gekeken naar de sterke en zwakke punten van RDC maar ook naar de kansen en de bedreigingen vanuit de markt. De SWOT ziet er als volgt uit: Sterkten S1 Marktleider S2 Centraal punt voor afhandeling vragen en klachten S3 Ervaren en vakkundig personeel S4 Meer diensten en producten dan concurrentie Zwakten Z1 Lange lijnen binnen RDC / trage oplostijd Z2 Softwareleverancier wordt gezien als klant en niet als relatie Z3 Geringe informatie voorziening richting softwareleveranciers Z4 Borging van kennis onvoldoende (persoon weg, kennis weg) Z5 Geen besef van vercommercialisering Z6 Testmethodiek


HTS Autotechniek 3

Kansen K1 Service Level Agreements met softwareleveranciers K2 Groot netwerk in de branche Bedreigingen B1 Concurrentie koppelt snel terug bij vragen/problemen B2 RDC heeft een ‘duur’ imago ten opzichte van concurrentie B3 Wetswijzigingen van de overheid B4 Vercommercialisering RDW Aan de hand van de SWOT analyse is er een confrontatiematrix opgesteld. Hierbij wordt er gekeken naar de relatie tussen de sterkten, zwakten, kansen en bedreigingen. Hierbij worden er onderscheid gemaakt tussen vier kwadranten namelijk: Aanvallen Bij aanvallen worden de sterke punten van RDC in relatie gebracht met kansen die er zijn in de markt. De hoofdvraag hierbij is “hoe kan een sterkte van RDC gebruikt worden om op een kans in te spelen”. Verdedigen Bij verdedigen worden de sterke punten van RDC in relatie gebracht met de bedreigingen die op RDC afkomen. De hoofdvraag hierbij is “hoe kan een sterkte gebruikt worden om een bedreiging af te wenden”. Versterken Bij versterken worden de zwakke punten van RDC in relatie gebracht met kansen die op de markt spelen. Hierbij is de hoofdvraag “op welke manier kan een zwakte versterkt worden om op een kans in te spelen”. Terugtreden Bij terugtreden worden de zwakke punten van RDC in relatie gebracht met bedreigingen die op de markt zijn. Hierbij is de hoofdvraag “hoe kan een zwakte zodanig versterkt worden om een bedreiging het hoofd te bieden”. Aan de hand van de punten die uit de confrontatiematrix naar voren zijn gekomen, zijn er zeven aanbevelingen geschreven voor RDC die allemaal het doel hebben om de relatie met de softwareleveranciers naar een hoger niveau te brengen. Enkele van deze aanbevelingen zijn al in werking getreden, andere worden binnen twee maanden in werking gezet. Een van de belangrijkste aanbevelingen heeft betrekking met het “contactpunt RDC voor softwareleveranciers”. Uit het onderzoek is gebleken dat de softwareleveranciers niet tevreden zijn met de huidige manier van communicatie met RDC. In de huidige situatie nemen softwareleveranciers bij vragen en klachten contact op met het Klant Contact Centrum (KCC) van RDC, hier werken geen technische specialisten en het merendeel van de vragen en klachten van de softwareleveranciers kan niet direct worden beantwoord. RDC wordt aanbevolen om een technisch specialist aan te nemen en deze op KCC verantwoordelijk te maken voor het afhandelen van incidenten van softwareleveranciers en het bewaken van alle calls die de tweede lijn in gaan. Een net zo belangrijke aanbeveling heeft betrekking op de testomgeving. Momenteel beschikt RDC niet over een dedicated testomgeving en kunnen softwareleveranciers niet onbeperkt testen, ook de testdata is niet duidelijk bij de softwareleveranciers. RDC wordt aanbevolen om de communicatie en


HTS Autotechniek 4

documentatie met betrekking tot de testomgeving te verbeteren en om een vervolg onderzoek uit te laten voeren door mensen met voldoenden kennis op ICT gebied. Uit het onderzoek is ook naar voren gekomen dat er veel ontevredenheid is over de documentatie van RDC richting de softwareleveranciers. De huidige documentatie is niet up to date en is slecht bereikbaar voor softwareleveranciers. RDC wordt aangeraden om een nieuwe documentatie op te stellen en deze up to date houden. Het is ook belangrijk dat dit document een prominente plek op de internetsite van RDC krijgt die binnen drie klikken vanaf de homepage te bereiken is. Deze verbetering is al in gang gezet en voor 31 december 2009 zal een totaal vernieuwd document worden gepresenteerd waarin alle documentatie is gebundeld en up to date is. Een andere aanbeveling is om het borgen van kennis tot de dagelijkse werkzaamheden te laten behoren. Het borgen van kennis kan helpen om de efficiëntie van de werknemers te vergroten. Er is minder kans op verlies van kennis als een werknemer om welke reden dan ook de organisatie verlaat en kunnen werkzaamheden door andere werknemers worden overgenomen zonder dat het wiel opnieuw uitgevonden hoeft te worden. Het borgen van kennis neemt tijd in beslag, RDC wordt aangeraden om haar medewerkers de tijd te geven om hun kennis op een juiste mannier te kunnen documenteren en delen met andere medewerkers. RDC mist als onderneming continuïteit. Dit wordt veroorzaakt doordat in de huidige situatie het management niet op de hoogte is van de prestatie die de werknemers van RDC leveren met betrekking tot de gestelde doelen. Key Performance Indicators (KPI) kunnen hier de uitkomst bieden. RDC wordt aangeraden om voor elke afdeling aparte KPI’s op te stellen (enkele afdelingen hebben al een vergelijkbaar rapportage (HiLow rapportage)). De KPI’s moeten voor iedereen binnen RDC te raadplegen zijn. Zodat het management en de medewerkers elkaar kunnen aanspreken. De HiLow rapportage kan hierbij als voorbeeld dienen. Een ander punt dat uit het onderzoek gebleken is, is dat softwareleveranciers ontevreden zijn over het wachtwoordbeheer van RDC. RDC wordt aanbevolen om te investeren in innovatie met betrekking tot het wachtwoord beheer. Het moet voor de gebruiker mogelijk zijn om op gebruikersniveau in te loggen voor de diensten van RDC in plaats van inloggen op klantniveau. Hierdoor kan RDC de samenwerking met de softwareleveranciers verbeteren. Tot slot is het noodzakelijk om te kijken naar een Service Level Agreement (SLA) met externe partijen. Omdat RDC op dit moment nog niet op een constant hoog service level zit, is het op dit moment niet haalbaar om realistische SLA’s af te sluiten, daarom wordt deze aanbeveling gedaan met het oog op de toekomst. Dit moet een doel zijn om naar toe te werken. Als RDC het service level op een dusdanig niveau heeft dat het realistische SLA’s af kan sluiten moet ze dit zeker doen. Op die manier is het voor de markt duidelijk wat ze van RDC kunnen verwachten en zal het verschil in verwachting en realiteit dat er nu is wegvallen.


HTS Autotechniek 5

Inhoudsopgave 1. Inleiding ..................................................................................................................................................... 7 2. Interne analyse .......................................................................................................................................... 9 3. Externe analyse ....................................................................................................................................... 12 4. Het onderzoek ......................................................................................................................................... 15 4.1 Telefonische interviews ..................................................................................................................... 15 4.2 Verdiepende interviews ..................................................................................................................... 16 4.3 Interne interviews .............................................................................................................................. 16 5. SWOT ....................................................................................................................................................... 17 5.1 Sterkten.............................................................................................................................................. 18 5.2 Zwakten ............................................................................................................................................. 18 5.3 Kansen................................................................................................................................................ 20 5.4 Bedreigingen ...................................................................................................................................... 21 6. Confrontatiematrix .................................................................................................................................. 23 6.1 Aanvallen ........................................................................................................................................... 24 6.2 Verdedigen......................................................................................................................................... 24 6.3 Versterken.......................................................................................................................................... 25 6.4 Terugtreden ....................................................................................................................................... 26 7. Analyse van oplossingen voor knelpunten .............................................................................................. 28 7.1 Contactpunt RDC voor softwareleveranciers .................................................................................... 28 7.2 Testomgeving ..................................................................................................................................... 36 7.3 Documentatie .................................................................................................................................... 39 7.4 Het borgen van kennis ....................................................................................................................... 41 7.5 KPI ...................................................................................................................................................... 42 7.6 Wachtwoord beheer .......................................................................................................................... 43 7.7 Service Level Agreement ................................................................................................................... 43 8. Conclusie en aanbevelingen .................................................................................................................... 45 8.1 Aanbeveling contactpunt RDC voor softwareleveranciers ................................................................ 45 8.2 Aanbeveling testomgeving ................................................................................................................ 46 8.3 Aanbeveling documentatie ................................................................................................................ 46 8.4 Aanbeveling het borgen van kennis................................................................................................... 46 8.5 Aanbeveling KPI ................................................................................................................................. 47 8.6 Aanbeveling wachtwoord beheer...................................................................................................... 47 8.7 Aanbeveling Service Level Agreement............................................................................................... 48 8.8 Actieplan ............................................................................................................................................ 48 Bronvermelding ........................................................................................................................................... 49 Verklarende woordenlijst en afkortingen ................................................................................................... 50


HTS Autotechniek 6

Inhoudsopgave bijlagen Inleiding ......................................................................................................................................................... 3 Bijlage I Organigram RDC............................................................................................................................... 4 Bijlage II Brainstorm telefonische interviews ................................................................................................ 5 Bijlage III Belscript telefonische interviews ................................................................................................... 6 Bijlage IV Resultaten telefonische interviews ............................................................................................... 8 Bijlage V Analyse telefonische interviews ................................................................................................... 18 Bijlage VI Brainstorm verdiepende interviews ............................................................................................ 22 Bijlage VII Script verdiepende interviews .................................................................................................... 23 Bijlage VIII Gespreksverslagen verdiepende interviews.............................................................................. 24 Bijlage IX Marktaandeel per dienst ............................................................................................................. 33 Bijlage X Prijsinformatie RDC tov concurrentie ........................................................................................... 34 Bijlage XIBusiness case wachtwoord vergeten............................................................................................ 36 Bijlage XII KPI KCC ........................................................................................................................................ 39 Bijlage XIII Actieplan .................................................................................................................................... 42


HTS Autotechniek 7

1. Inleiding RDC is het afgelopen jaar overgegaan naar een nieuw platform voor de producten en diensten die het levert. Het verouderde mainframe is vervangen door webservices en de Service Oriented Architecture structuur (SOA). Er is voor deze concepten gekozen omdat deze dichter aansluiten bij de wensen en verwachtingen van de klant. Met deze concepten kan er door de gehele keten sneller en (kosten)efficiënter worden gewerkt en is RDC in vergelijking met de concurrenten vooruitstrevend en innovatief. Deze verandering in combinatie met een interne reorganisatie hebben ervoor gezorgd dat er minder aandacht is geweest voor doorontwikkeling en innovatie van bestaande en nieuwe producten en diensten. Hierdoor is de relatie met de markt minder geworden en is de afstand tussen RDC en de softwareleveranciers groter geworden. Sommige klanten van RDC (importeurs, dealerorganisaties, garagebedrijven, schadeherstel en leasemaatschappijen) hebben een rechtstreekse samenwerking met RDC. Kleinere organisaties, waaronder garagebedrijven en (merk)dealers, zijn indirect klant doordat ze gebruik maken van Dealer Management Software (DMS) en garage software pakketten welke door diverse softwareleveranciers in Nederland worden aangeboden. De softwareleveranciers zijn erg belangrijk voor RDC omdat deze een aanzienlijk gedeelte van de markt voorzien van DMS (Dealer management softwarepakketten) waar producten en diensten van RDC in zijn geïntegreerd. Door de overgang naar het nieuwe platform en de reorganisatie binnen RDC is de relatie met de softwareleveranciers niet voldoende onderhouden waardoor op dit gebied een achterstand is ontstaan ten opzichte van de concurrentie en de softwareleveranciers vaker voor de concurrentie kiezen. Deze relatie moet weer worden opgebouwd om ook op dit gebied de concurrentie een stap voor te zijn. De hoofdvraag die in dit onderzoek beantwoord moet worden is: Welke stappen moet RDC ondernemen om de relatie met de softwareleveranciers te verbeteren? Om de hoofdvraag te beantwoorden zullen ook de volgende deelvragen beantwoord moeten worden: Wat zijn de ervaringen van de softwareleveranciers met RDC met betrekking tot communicatie, kwaliteit van producten en de afhandeling van klachten/vragen Dekt de huidige documentatie en/of informatievoorziening de wensen en behoeften van softwareleveranciers? Door middel van telefonische interviews met zo veel mogelijk softwareleveranciers wordt er een beeld geschetst van de situatie in de markt. Wat zijn de wensen van de softwareleveranciers op het gebied van communicatie, kwaliteit van de producten (commercieel: gemakkelijk mee te werken, technisch: storingsgevoeligheid, etc.), de informatievoorziening en zijn er naast deze punten nog andere wensen die er spelen. Aan de hand van deze informatie kan er dieper op bepaalde onderwerpen worden ingegaan. Dit gebeurt tijdens de verdiepende interviews die bij enkele softwareleveranciers worden afgenomen. Als de wensen en behoeften uit de markt duidelijk zijn, wordt er intern gekeken naar de mogelijkheden om deze te verbeteren of aan te passen. Het eindproduct van dit onderzoek is een adviesrapport met daarin de resultaten van het onderzoek en een advies voor RDC om de wensen en behoeften die er zijn in de markt zoveel mogelijk te dekken. Het rapport bevat een actieplan met een concrete beschrijving van het probleem en bijbehorende acties die


HTS Autotechniek 8

ondernomen moeten worden om de verbeteringen in gang te zetten. Ieder actiepunt zal een verantwoordelijke krijgen voor het invoeren van de verbetering en een verantwoordelijke voor het controleren en borgen van de verbetering. Om het actieplan compleet te maken zal er voor elk verbeterpunt een startdatum en een deadline worden vastgesteld. Dit alles met als doel om de relatie tussen RDC en de softwareleveranciers te verbeteren. Het rapport is als volgt ingedeeld: hoofdstuk twee en drie zijn de interne- en externe analyse van RDC. Hierin worden de organisatie, de klanten en producten, de markt en de concurrentie beschreven. In hoofdstuk vier wordt het onderzoek uiteengezet met de gehanteerde werkwijze. Hoofdstuk vijf bevat een SWOT analyse en hoofdstuk zes de confrontatiematrix, in hoofdstuk zeven worden oplossingen gegeven voor de knelpunten en in hoofdstuk acht is de conclusie aanbevelingen voor RDC weergeven, dit hoofdstuk wordt afgesloten met het actieplan. Na de conclusie en aanbevelingen is een bronvermelding en lijst met veelgebruikte afkortingen te vinden. De bijlagen zijn gebundeld in een apart rapport en wordt samen met dit rapport verstrekt.


HTS Autotechniek 9

2. Interne analyse RDC Datacentrum (RDC) is in Nederland de grootste informatie leverancier in de mobiliteitsbranche. Producten en diensten die RDC levert aan de sector zijn: marktinformatie (uit de database van Rijksdienst voor het Wegverkeer (RDW)), direct marketing, informatieen communicatiediensten en automatiseringsoplossingen. Naast de mobiliteitssector is RDC met diensten op het gebied van ICT en procesintegratie ook actief in andere gebieden, zoals accountants, advocaten, incassobureaus en verzekeraars. RDC vervult een centrale rol in de processen van haar klanten in de mobiliteitsbranche. De producten van RDC zijn dienstverleningen op het gebied van ICT, informatievoorzieningen en Software As A Service (SAAS), maar het kan ook totaaloplossingen leveren in de vorm van een volledige infrastructuur waarmee de processen en informatiestromen van klanten worden gedigitaliseerd en geïntegreerd. Verzamelen, opslaan en bewerken van veel verschillende datastromen staat centraal bij RDC, door deze ongestructureerde data om te vormen tot bruikbare informatie kunnen klanten inzicht krijgen in hun markt(en), klanten en vooruitzichten. Door middel van verschillende online softwareprogramma’s hebben klanten overal en altijd toegang tot hun data. De software en informatie van de klanten (klanten zijn te allen tijde eigenaar van de data) worden beheerd en goed beveiligd op de servers van het moderne rekencentrum van het RDC. Organisatie RDC bestaat uit verschillende afdelingen met ieder een eigen taak om op die manier de producten en diensten te blijven ontwikkelen en de klanten een zo compleet mogelijk product aan te kunnen bieden. De organisatiestructuur van RDC is procesgericht. Dit heeft geleid tot een verdeling in drie segmenten: klanten, producten en techniek. In bijlage I Organigram RDC is het volledige organigram van RDC weergegeven. Hieronder worden de verschillende afdelingen benoemd en beschreven. Klanten Het segment Klanten is onderverdeeld in de volgende drie marktsegmenten: Mobiliteit Financiële dienstverlening Zakelijke dienstverlening Om de relatie met haar klanten zo snel en direct mogelijk te laten verlopen zijn per segment klantenteams samengesteld met medewerkers van de afdelingen Verkoop, Sales Support en ServiceDesk. Zo hebben de klanten directe aanspreekpunten voor hun verzoeken en vragen. Klanten bestaat uit de volgende afdelingen: Verkoop ServiceDesk Sales Support Marketing Direct Mail – NAW Klantenadministratie Business Implementatie Producten Binnen het segment Producten ligt de focus op producten business functionaliteit. Het is verantwoordelijk voor het ontwikkelen en beheren van de diensten die RDC levert.


HTS Autotechniek 10

Producten bestaat uit de volgende afdelingen: Business Service Management (BSM) Functioneel Beheer (FB) Applicatie Beheer (AB) Architecten Informatiebeheer Techniek Binnen het segment Techniek ligt de focus op de ondersteuning en productie van ICT. De afdeling is verantwoordelijk voor het optimaal laten aansluiten van de technische beheersprocessen op de bedrijfsen serviceprocessen. Techniek bestaat uit de volgende afdelingen: IT & Infrastructuur, bestaande uit: Platformbeheer (I en II) en Netwerken & Toegang Applicatie- ontwikkeling en onderhoud Test Naast bovenstaande segmenten heeft RDC een staf waarin de volgende afdelingen zijn vertegenwoordigd. Programmamanagement Business consultant Inkoop- en Facilitair Management Strategie Marketing Juridische zaken Secretariaat HRM Financiën en administratie RDC levert verschillende diensten aan zijn klantengroep. Deze diensten worden direct (via een online applicatie) aan klanten aangeboden, of via externe softwareleveranciers die de verschillende diensten in een totaalpakket (denk aan een DMS) aan dealers, importeurs en garagebedrijven aanbieden. Hieronder worden de belangrijkste diensten benoemd en beschreven. De APK/Tagasas service De APK/Tagasas service bestaat uit APK, afmelden tachograaf, afmelden snelheidsbegrenzer, en afmelden inbouw LPG. Via de service kan een Keurmeester via het internet aan de RDW doorgeven dat een voertuig goed- of afgekeurd is. BPM service De BPM (Belasting van Personenauto's en Motorrijwielen) service is een service die op basis van ingave van een kenteken, meldcode en inruildatum het restbedrag van de BPM berekent. Dit gebeurt op basis van de datum eerste toelating die wordt opgehaald uit het voertuigen en eigenaren register (VER) en het bij het kenteken bekende BPM bedrag. Vervolgens wordt de ouderdom bepaald en in de forfaitaire afschrijvingstabel van de belastingdienst gekeken hoe groot de afschrijving is. Ook voor bestelwagens wordt een restbedrag berekend. DVS service Met de DVS (Document Verificatie Systeem) service wordt de geldigheid gecontroleerd van een aangeboden rijbewijs bijvoorbeeld bij autoverhuur of een proefrit. Hiermee wordt het risico verkleind


HTS Autotechniek 11

dat garagisten de dupe worden van een gestolen of vervalst rijbewijs. En daarmee de kans dat goederen niet of beschadigd worden terugbezorgd. De verificatie van een rijbewijs gebeurt bij de RDW, die RDC maandelijks een factuur stuurt voor het totaal aantal DVS-transacties in de betreffende maand. INDI service (stichting INDI) Het INDI (Interface NAW Dealer Importeur) platform vormt het centrale verzamel-, validatie- en uitwisselpunt van NAW-gegevens voor importeurs en dealers binnen het merkkanaal. Via deze service beschikken de merkdealers en importeurs altijd over de juiste en meest actuele gegevens van hun klanten en vooruitzichten. NAP service (stichting NAP) De hoofdfuncties van NAP (Nationale Auto Pas) zijn de volgende: De opslag en weergave van de kilometerlevensloop van gekentekende motorvoertuigen, voornamelijk personenauto's en bestelauto’s Het uitgeven van de Elektronische Autopas Het bieden van de mogelijkheid om een weblabel aan te vragen Het doen van een Nap Bepaling (ook wel genoemd nap consument) ORB service Met behulp van ORB (Online Registratie Bedrijfsvoorraad) kunnen de ondernemingen hun bedrijfsvoorraad (kentekens) vrijwaren. ROB service (stichting ROB) De doelstelling van het ROB (Reparatie, Onderhoud en Banden) systeem is één uniform communicatiesysteem realiseren tussen leveranciers en leasemaatschappijen, op het gebied van Reparatie, Onderhoud, Banden en Vervangend vervoer. Uitgangspunt hierbij is een uniforme ROB werkorder, inclusief relevante coderingen Het communicatiesysteem voorziet globaal in de volgende trajecten: Het aanvraagtraject voor het verkrijgen van toestemming door de leverancier voor reparatie, onderhoud, banden en vervangend vervoer bij leasemaatschappijen; Het antwoordtraject van de leasemaatschappij naar de leverancier; Het al dan niet geheel of gedeeltelijk automatisch accorderen van de betreffende werkopdrachten; Het beschikbaar stellen van de, voor facturatie van leverancier aan leasemaatschappij, relevante informatie aan de leveranciers; Het ten behoeve van leasemaatschappijen beschikbaar stellen van al dan niet geaggregeerde informatie over de werkopdrachten interactie. GPS service Met het GPS (Garage Polis Systeem) kunnen garagepolissen beheerd worden. Een garagepolis is een contract tussen een verzekeraar en een polishouder waarbij bepaalde schade aan de verzekerde objecten (kentekens) door die polis gedekt worden. De verzekerde objecten worden door de polishouder aangevraagd en vallen, na acceptatie door de verzekeraar, onder de dekking. De garageverzekering dekt: De schade toegebracht met motorrijtuigen (van het bedrijf of van klanten) De schade aan motorrijtuigen van klanten tijdens reparatie- en onderhoudswerkzaamheden, De schade door een onjuiste uitvoering van de werkzaamheden aan het motorrijtuig.


HTS Autotechniek 12

3. Externe analyse In dit hoofdstuk wordt toegelicht welke externe factoren invloed uitoefenen op RDC als onderneming. De markt, klanten en de concurrentie worden besproken. Markt en klanten De core business van RDC is het verschaffen van informatie aan de mobiliteitsbranche. RDC is als informatieen communicatieprovider in staat om gegevens uit de database van de RDW te halen en deze, via eigen servers, te leveren aan de eindgebruiker. Het verschaffen van deze informatie kan op twee manieren. Direct Hierbij wordt de informatie / data direct aan de eindgebruiker verstrekt. Via een online applicatie waar de eindgebruiker kan inloggen met een gebruikersnaam en wachtwoord kan deze direct informatie over een voertuig opvragen of bijvoorbeeld een APK afmelden. Indirect Hierbij wordt de werking van de applicaties aan softwareleveranciers verstrekt. De software leveranciers integreren deze applicaties in hun softwarepakketten (DMS of garage software pakketten) en bieden deze aan de eindgebruiker aan. Denk hierbij aan schadeherstellers, garagebedrijven, leasemaatschappijen, dealers en importeurs. Op deze manier heeft de eindgebruiker een pakket voor al zijn bedrijfsprocessen. Het klantenportfolio van RDC bestaat uit kleine universele garages tot grote importeurs en leasemaatschappijen. Binnen de mobiliteitsbranche bestaan de klanten van RDC uit: Garages Dealers Importeurs Leasemaatschappijen Fleetowners Autohandelaren (Brom-)Fiets bedrijf Voertuigverhuurbedrijven Daarnaast heeft RDC ook klanten in de volgende branches Overheid Criminaliteitspreventie (politie) Softwareleveranciers ICT Accountancy Verzekeraars Schadebedrijven


HTS Autotechniek 13

Concurrentie Er zijn in Nederland drie partijen die zorgen voor zowel communicatie met de RDW als het leveren van informatie uit de RDW database. Naast RDC zijn dit VWE en A2SP: VWE Circa 7 000 bedrijven maken gebruik van de online applicatie van VWE. Dit maakt VWE tweede grootste RDW informatieen communicatieprovider. A2SP A2SP kent een klantenbestand van 4 500 bedrijven. A2SP is net als RDC en VWE een RDW informatieen communicatieprovider. RDC is de grootste RDW informatieen communicatieprovider met een marktaandeel van ruim 60%. RDC beschikt over het meest uitgebreide dienstenpakket. Dat is voor veel bedrijven binnen de mobiliteitsbranche de doorslaggevende reden om voor RDC te kiezen.

Marktaandeel VWE 23%

A2SP 15%

RDC 62%

Figuur 1: Marktaandeel RDC, VWE en A2SP

In de onderstaande tabel zijn de diensten die RDC aanbied vergeleken met diensten die directe concurrenten aanbieden. Voor deze vergelijking zijn alleen de RDW gerelateerde diensten meegenomen. Zowel RDC als de twee concurrenten bieden meerdere diensten aan. Diensten RDC VWE A2SP APK √ √ √ BPM √ √ √ DVS √ √ √ INDI √ NAP √ √ ORB √ √ √ ROB √ GPS √ Tabel 1: Dienstenaanbod RDC, VWE en A2SP In bijlage IX Marktaandeel per dienst wordt er dieper ingegaan op het marktaandeel dat RDC heeft per dienst Naast de twee directe concurrente kent RDC ook drie indirecte concurrenten: VDC Nederland VDC Nederland is een RDW communicatieprovider. Dat wil zeggen dat VDC de communicatie tussen RDW en automobielbedrijven mogelijk maakt maar geen informatie uit de RDW database kan verschaffen aan de betreffende bedrijven.


HTS Autotechniek 14

MotiWise MotiWise is een dochteronderneming van Pon’s Automobielhandel. MotiWise is in tegenstelling tot VDC Nederland RDW informatieprovider. Dat wit zeggen dat MotiWise informatie uit de database van RDW aan automobielbedrijven kan verschaffen. Autotaxatie.net Autotaxatie.net is een dochteronderneming van Buitenhuis-Groep en is net als MotiWise een RDW informatieprovider. Omdat de bovenstaande drie bedrijven alleen de communicatie of alleen de informatie met de RDW database verzorgen zijn dit indirecte concurrenten.


HTS Autotechniek 15

4. Het onderzoek Om de behoefte van de markt in kaart te brengen is er een marktonderzoek opgesteld en uitgevoerd. Er is gekozen om het marktonderzoek uit te voeren door middel van interviews met belanghebbenden in de markt. Hierbij zijn zowel de softwareleveranciers als het personeel van RDC geïnterviewd. De reden hiervoor was om een objectief beeld te vormen. De eindgebruikers zijn niet meegenomen in het marktonderzoek. De reden hiervoor is dat RDC veel verschillende eindgebruikers kent met zeer uiteenlopende eisen en wensen. Het is daarom niet mogelijk om binnen de gereserveerde tijd voor het marktonderzoek de eindgebruikers te interviewen. Een tweede reden waarom de eindgebruikers zijn uitgesloten is omdat de softwareleveranciers hun klanten moeten kennen en op hun beurt moeten inspelen op de behoeften van hun klanten. Hierdoor kan gezegd worden dat de eisen en wensen van de softwareleverancier tot zekere mate overeen moet komen met de eisen en wensen van de eindgebruikers. Voordat er daadwerkelijk contact is gezocht met de softwareleveranciers moest er een selectie gemaakt worden welke software leveranciers benaderd gaan worden. In bijlage IV Resultaten telefonische interviews is te zien welke softwareleveranciers zijn benaderd. De selectie is als volgt gegaan: alle softwareleveranciers waar RDC mee samenwerkt in de mobiliteitsbranche zijn gefilterd uit het contactgegevensbestand. Dit waren in totaal 26 softwareleveranciers, deze zijn allemaal benaderd voor het telefonische interview.

4.1 Telefonische interviews Het doel van de telefonische interviews is om een beeld te vormen van de markt waar RDC actief in is. Door middel van een brainstorm (Bijlage II Brainstorm telefonische interviews) is het doel gedefinieerd. Uiteraard heeft er voorafgaand aan de telefonische interviews deskresearch plaatsgevonden naar de softwareleveranciers en de producten en diensten die ze leveren. De telefonische interviews zullen het deskresearch met het volgende punten aanvullen: Welk beeld hebben de softwareleveranciers van RDC Hoe de softwareleverancier de communicatie met RDC ervaren Hoe de softwareleveranciers het gebruiksgemak en kwaliteit van de producten en diensten van RDC ervaren Welke producten en diensten van RDC de softwareleveranciers gebruiken in hun software Welke eisen en wensen zijn er vanuit de softwareleveranciers. Om de telefonische interviews zo efficiënt mogelijk uit te voeren en zoveel mogelijk nuttige informatie eruit te halen, is er voorafgaand aan de interviews met behulp van een brainstormsessie gekeken welke informatie de interviews moesten opleveren. De volgende stap was het bedenken van vragen waarbij de antwoorden alle informatie die nodig is, kon dekken. Aan de hand van deze vragen is er een belscript opgesteld. Dit belscript is in bijlage III Belscript telefonische interviews te zien. Van ieder interview is er een verslag gemaakt en de resultaten zijn in een Excel bestand verwerkt (zie bijlage IV Resultaten telefonische interviews). Dit is gedaan om het analyseren van de resultaten te vergemakkelijken. In totaal zijn er 18 softwareleveranciers telefonisch geïnterviewd. De resterende softwareleveranciers wilden of konden om verschillende redenen niet deelnemen aan het marktonderzoek. De resultaten van de telefonische interviews zijn gebruikt als basis voor de verdiepende interviews. Tijdens deze interviews kwamen er drie duidelijke knelpunten naar boven. Namelijk: de testomgeving, de afhandeling van vragen en klachten en de documentatie. Tijdens de verdiepende interviews is hier dieper op in gegaan. Een analyse van de telefonische interviews zijn te vinden in bijlage V Analyse telefonische interviews.


HTS Autotechniek 16

4.2 Verdiepende interviews Door de telefonische interviews is er een duidelijk beeld ontstaan over de omstandigheden in de markt waarin RDC opereert. Na het analyseren van de antwoorden die de softwareleveranciers hebben gegeven in de telefonische interviews is er ook een beeld ontstaan van waar de knelpunten liggen in de relatie tussen RDC en de softwareleveranciers. Onderwerpen die door de softwareleveranciers als negatief worden beschouwd zijn: de testomgeving, de afhandeling van vragen en klachten en de documentatie. Het doel dat de verdiepende interviews hadden, was een inzicht te krijgen in de problemen waar de softwareleveranciers tegenaan lopen en hoe deze opgelost zouden kunnen worden. Voor de verdiepende interviews is dezelfde werkwijze gehanteerd als met de telefonische interviews. Met behulp van een brainstormsessie (Bijlage VI Brainstorm verdiepende interviews) is er bepaald welke onderwerpen er aan bod moesten komen. Hierbij is gekeken welke informatie er tijdens de verdiepende interviews naar boven moest komen. Vervolgens zijn er vragen bedacht waarbij de antwoorden de informatie die nodig is zal dekken. Aan de hand van deze vragen is er een script opgesteld, dit script is in bijlage VII Script verdiepende interviews te zien. Voor de verdiepende interviews zijn er vier softwareleveranciers bezocht. Er zijn niet meer softwareleveranciers bezocht omdat er uit deze interviews voldoende informatie is gekomen waarmee het project kon worden ingevuld. Daarnaast was er in de planning ook geen ruimte om nog meer bezoeken af te leggen. De antwoorden die de softwareleveranciers hebben gegeven tijdens de verdiepende interviews zijn als interview verslag gedocumenteerd en zijn te zien in bijlage VIII Gespreksverslagen verdiepende interviews.

4.3 Interne interviews Om het beeld dat is ontstaan na de interviews met de softwareleveranciers in perspectief te kunnen zetten, zijn er ook intern interviews afgenomen met betrokken medewerkers. Hierbij zijn de eindverantwoordelijken van de producten en diensten waar ongenoegen over was geïnterviewd. Hierbij kregen zij de kans om hun standpunten en manier van werken te verdedigen. Hierbij is ook gekeken welke mogelijkheden in de toekomst een oplossing kunnen bieden. De interne interviews zijn, samen met de telefonische interviews en de verdiepende interviews, gebruikt voor het opstellen van een SWOT (sterkten-zwakten, kansen-bedreigingen) analyse, deze is in het volgende hoofdstuk te vinden.

5. SWOT In dit hoofdstuk wordt de SWOT analyse van RDC gegeven, de SWOT is zo breed mogelijk gehouden om op die manier meerwaarde te creëren voor het bedrijf. Als eerste wordt de SWOT als tabel weergegeven, vervolgens wordt ieder punt apart besproken in de paragrafen sterkten, zwakten, kansen en bedreigingen.

Sterkten S1 S2 S3 S4

Marktleider Centraal punt voor afhandeling vragen en klachten Ervaren en vakkundig personeel Meer diensten dan concurrentie

Kansen K1 Service Level Agreements met softwareleveranciers K2 Groot netwerk in de branche

Figuur 2: SWOT

Zwakten Z1 Z2 Z3 Z4 Z5 Z6

Lange lijnen binnen RDC/ trage oplostijd Softwareleverancier wordt gezien als klant en niet als relatie Geringe informatie voorziening richting softwareleveranciers Borging van kennis onvoldoende (persoon weg, kennis weg) Geen besef van vercommercialisering Testmethodiek

Bedreigingen B1 B2 B3 B4

Concurrentie koppelt snel terug bij vragen/problemen RDC heeft een ‘duur’ imago ten opzichte van concurrentie Wetswijzigingen van de overheid Vercommercialisering RDW

5.1 Sterkten S1 Marktleider RDC heeft in het verleden het alleenrecht gehad voor het leveren van mobiliteitinformatie, hierdoor had RDC een marktaandeel van 100%. Na het openbreken van de markt in 2000 en de komst van concurrenten heeft RDC een groot deel van het marktaandeel in moeten leveren. RDC is momenteel nog steeds marktleider, zo beschikt RDC bijvoorbeeld over een marktaandeel van 60% als het om de APK afmeldingen gaat. Het marktaandeel van de overige diensten is te vinden in bijlage IX Marktaandeel per dienst. Door het grote marktaandeel (dus veel klanten) kan RDC de situatie in de markt goed inschatten en hierop inspelen om op die manier de concurrenten een stap voor te blijven. S2 Centraal punt voor afhandeling vragen en klachten Ieder contact dat wordt gelegd met RDC komt binnen bij het Klant Contact Center (KCC). Deze manier van afhandelen van vragen en klachten wordt ook wel single point contact genoemd. Hierdoor kunnen de medewerkers van KCC de vragen en klachten van de softwareleveranciers en de eindgebruikers goed vast leggen in Topdesk. KCC heeft in september 9276 calls behandeld. Door deze grote aantallen kan RDC een goed beeld schetsen van de situatie in de markt en kunnen de binnenkomende contacten goed gedocumenteerd worden. Hierdoor worden dure marktonderzoeken overbodig. Door het vastleggen van de calls kan het management zien waar het fout gaat en kunnen acties genomen worden om dit op te lossen of te verbeteren. S3 Ervaren en vakkundig personeel Bij RDC is er weinig verloop van personeel, hierdoor zijn er veel specialisten met veel kennis. De werknemers van RDC zijn bekend met de organisatie, de markt en de concurrentie. Dit heeft als voordeel dat de behoeften van de markt goed zichtbaar zijn en RDC met deze informatie producten kan ontwikkelen die aansluiten bij de vraag van de markt en het aanbod van de concurrentie overtreffen in kwaliteit en functionaliteit. S4 Meer diensten en producten dan concurrentie RDC beschikt over een zeer uitgebreid diensten productpakket. In de externe analyse is te zien welke diensten RDC levert en welke diensten de concurrenten van RDC leveren. Eindgebruikers geven de voorkeur aan een informatieleverancier die een zo compleet mogelijk pakket kunnen aanbieden. De voordelen voor de eindgebruiker is dat die maar een factuur binnen krijgt waardoor er minder administratieve handelingen plaatsvinden. Een ander voordeel van werken met een informatieleverancier is dat de garagemedewerkers niet hoeven te leren werken met verschillende programma’s.

5.2 Zwakten Z1 Lange lijnen binnen RDC / trage oplostijd RDC heeft het afgelopen jaar een reorganisatie doorgevoerd. Hierdoor zijn enkele functies komen te vervallen en zijn er enkele nieuwe functies ontstaan. Mede door deze reorganisatie zijn sommige verantwoordelijken en verantwoordelijkheden onduidelijk geworden. Deze taken zouden aan meerdere afdelingen toegekend kunnen worden. Hierdoor kan het voorkomen dat vragen en klachten (calls) van softwareleveranciers meerdere malen worden doorgestuurd binnen de organisatie voordat deze bij de juiste persoon zijn. Omdat er geen bewaking van de voortgang van de call is door KCC, is het onduidelijk hoelang het duurt en wat de status van de call is. Dit kan dus ook niet worden gecommuniceerd naar de softwareleverancier die daardoor het gevoel kan krijgen dat er niets gebeurt met zijn vraag of klacht. Deze situatie zorgt ervoor dat de doorlooptijd van calls langer is dan de verwachting van de softwareleverancier waardoor er ontevredenheid ontstaat bij de softwareleverancier.


HTS Autotechniek 19

Z2 Softwareleverancier wordt gezien als klant en niet als relatie De softwareleveranciers betalen RDC niet voor het inbouwen van de verschillende diensten en producten en worden hiervoor ook niet betaald. De softwareleveranciers zorgen er wel voor dat veel betalende eindgebruikers diensten van RDC afnemen die in hun softwarepakketten verwerkt zijn. Daarom moeten de softwareleveranciers niet als klanten van RDC worden beschouwd maar als relaties. De klant wordt als volgt gedefinieerd: “een klant is de afnemer van een goed of dienst van een leverancier. In principe is het zo dat hier betaling tegenover staat. Omdat de leverancier graag geld wil verdienen en/of van zijn inkomsten van de klant afhankelijk is zal hij proberen het zijn klant naar de zin te maken”. (Bron: wikipedia) Doordat de softwareleveranciers als klanten wordt gezien ontstaat er ook een bepaalde afstand tussen RDC en de softwareleveranciers. Als de softwareleveranciers als relatie worden gezien worden de lijnen tussen RDC en softwareleveranciers korter. Hierdoor wordt de samenwerking gestimuleerd wat resulteert tot een betere sturing vanuit de markt (in deze situatie de softwareleveranciers) en een verbetering van kwaliteit van de producten. Z3 Geringe informatie voorziening richting softwareleveranciers De documentatie (informatie voorziening) is voor de softwareleveranciers van essentieel belang Om de diensten en producten van RDC goed in te kunnen bouwen in hun softwarepakketten. Op dit gebied kan RDC nog een grote slag slaan, de documentatie van de concurrenten wordt als zeer prettig en compleet ervaren. De documentatie van RDC zou op de volgende punten verbeterd kunnen worden: De documentatie op de website van RDC is ongestructureerd en verouderd. De documentatie moet een levend document zijn waar alle veranderingen in verwerkt worden. Het is dan van belang dat de lezer in een oog opslag kan zien wat er veranderd is in vergelijking met de voorgaande versies. De inhoudsopgave komt niet overeen met de inhoud van het bestand. De documentatie bevat geen SOAP voorbeeld codes. De documentatie moet de softwareleveranciers voldoende bagage geven om zelfstandig de producten en diensten van RDC in te kunnen bouwen in hun software. Als dat niet geval is nemen de softwareleveranciers contact op met RDC waardoor veel tweede lijn calls ontstaan. Het is dus van belang om per transactionele dienst de SOAP voorbeeld codes toe te voegen in de documentatie. De procesbeschrijving ontbreekt. De procesbeschrijving is van belang om te kunnen begrijpen hoe de diensten zijn opgebouwd en welke handelingen er plaats vinden voor dat er concrete data uit komt. Een goede documentatie kan ervoor zorgen dat de softwareleveranciers de diensten en producten van RDC sneller en beter kunnen integreren in de softwarepakketten. De documentatie moet ook gemakkelijk te raadplegen zijn voor de softwareleveranciers. Er is onderzoek gedaan naar de bereikbaarheid van de documentatie voor de softwareleveranciers. Het is ons niet gelukt om op de website van RDC (https://www.rdc.nl/) de documentatie te vinden. Naar aanleiding hiervan kan er geconcludeerd worden dat het voor externe partij als de softwareleveranciers de documentatie onvindbaar is.


HTS Autotechniek 20

NB: De bovenstaande punten zijn van toepassing voor de huidige documentatie (RDC webservices) en niet voor de PIT gids.

Z4 Borging van kennis onvoldoende (persoon weg, kennis weg) Binnen RDC is er ontzettend veel kennis aanwezig, zowel technisch als commercieel. Deze kennis is echter niet goed gedocumenteerd en daardoor niet beschikbaar voor iedere werknemer. Dit is nadelig voor het probleemoplossend vermogen van RDC, omdat er nu vaak lang gezocht moet worden naar de juiste gegevens om tot een oplossing te komen. RDC-wiki is een goed tool om de kennis te borgen. Momenteel is de RDC-wiki niet goed gevuld. Als men kijkt naar de beschrijving van afdelingen binnen RDC-wiki zijn er veel pagina’s niet volledig ingevuld. Een ander nadeel wat slecht documenteren met zich meebrengt is dat als er een medewerker, om welke reden dan ook, RDC verlaat, er ook meteen een stuk kennis verloren gaat. Dit creëert ruimte tussen de verschillende afdelingen. Omdat niet volkomen duidelijk is welke verantwoordelijkheden de verschillende werknemers en afdelingen hebben, kan dit zorgen voor onduidelijke situaties. Een recent voorbeeld hiervan is het vertrek van een werknemer van de afdeling BSM. Deze was verantwoordelijk voor de ROB dienst. Zijn directe collega’s die zijn taken tijdelijk moeten overnemen hebben niet hetzelfde kennisniveau van deze dienst en moeten het wiel hier en daar opnieuw uitvinden. Z5 Geen besef van vercommercialisering Er wordt binnen RDC nog te weinig aandacht besteedt aan de markt en de vraag en behoefte uit die markt. RDC kan nog veel meer handelen als een echt commercieel bedrijf, de markt is er nog niet van overtuigd dat ‘iedereen bij RDC beseft dat het een commerciële organisatie is’, aldus een van de respondenten. Hier liggen dus kansen, beter luisteren naar de markt om op die manier meer samenwerking te creëren en te leren van elkaars kennis en specialiteiten. Beter inspringen op veranderingen in de markt en rekening houden met de concurrenten. Z6 Testmethodiek RDC beschikt momenteel niet over een dedicated testomgeving. RDC levert de softwareleveranciers echter testdata waarmee ze zelf kunnen testen. De testdata die RDC beschikbaar stelt aan de softwareleveranciers functioneert niet goed. Testresultaten zijn vaak erg langzaam waardoor de doorlooptijd van een test (bij de softwareleverancier) erg lang duurt, terwijl dit veel sneller zou moeten en kunnen. Een voorbeeld is de testomgeving van INDI. Bij de testomgeving van INDI moeten de softwareleveranciers per handeling 48 uur wachten op een antwoord, omdat de softwareleverancier wel tien keer een test wil doen is de doorlooptijd van deze test tien keer 48 uur! De testomgeving wijkt ook af van de live versie waardoor de software weer aangepast moet worden aan de nieuwe situatie. Een kleine verandering kan grote gevolgen hebben voor de softwareleveranciers. Een voorbeeld hiervan is het elektronisch factureren in ROB. In de testversie was het mogelijk om te allen tijde openstaande werkorders op te vragen, zo vaak als je zou willen. In de live versie was dit niet meer mogelijk en kon je de openstaande werkorder maar een keer per half uur opvragen, een essentieel verschil dat niet had mogen voorkomen.

5.3 Kansen K1 Service Level Agreements (SLA) met softwareleveranciers Tussen de softwareleveranciers en RDC zijn nu geen duidelijke afspraken gemaakt. Hierdoor is er een verschil tussen het verwachtingspatroon dat de softwareleveranciers hebben en de werkelijke situatie. Dit zorgt voor ontevredenheid bij de softwareleveranciers, met behulp van goed gedefinieerde SLA’s is


HTS Autotechniek 21

voor beide partijen duidelijk welke afspraken er zijn en welke verwachtingen ze kunnen hebben. Door het opstellen van SLA’s zullen de softwareleveranciers minder naar KCC bellen om te vragen wat de status van hun call is. K2 Groot netwerk in de branche RDC heeft ruim 12.000 klanten in de mobiliteitsbranche. Door de bestaande samenwerking is het voor RDC gemakkelijk om bij de doelgroep binnen te komen met een nieuw product. De bestaande producten kunnen in combinatie met producten en diensten die de eindgebruikers al afnemen worden verkocht. De softwareleveranciers kunnen hier een belangrijke rol in spelen door meerdere diensten van RDC in een softwarepakket te integreren en de productdichtheid bij de klant te verhogen.

5.4 Bedreigingen B1 Concurrentie koppelt snel terug bij vragen/problemen In de verdiepende interviews hebben vier softwareleveranciers aangegeven dat ze vaak lang moeten wachten op een antwoord op hun vragen en klachten bij RDC. De doorlooptijd wordt als erg lang ervaren, zeker in vergelijking met de concurrenten. Dit zorgt ervoor dat softwareleveranciers minder graag met RDC werken dan met een van de concurrenten. Daarnaast nemen softwareleveranciers liever geen contact op met RDC bij kleine dingen, terwijl dit erg belangrijke informatie kan zijn om de kwaliteit van de producten en diensten te verbeteren. B2 RDC heeft een ‘duur’ imago ten opzichte van concurrentie De algemene gedachte in de markt is dat RDC duur is, terwijl dit lang niet altijd zo is. Door meer openheid te geven over de prijzen die RDC rekent en belangrijker nog, wat je voor die prijzen krijgt, creëer je een ander beeld en is het voor de eindgebruiker gemakkelijker om op dat vlak te vergelijken. De klant zal dan zien dat ze bij RDC waar voor hun geld krijgen en een zeer uitgebreid dienstenpakket kunnen krijgen op maat. Als de informatie die nu door iedereen kan worden gevonden op het internet over de prijzen die de verschillende informatieproviders voor hun diensten rekenen goed worden bekeken zoals in bijlage X Prijsinformatie RDC tov concurrentie waar de prijzen van RDC, VWE, A2SP en VDC met elkaar zijn vergeleken, dan zie je dat RDC zeer concurrerende prijzen rekent voor de aangeboden diensten. B3 Wetswijzigingen van de overheid RDC heeft veel te maken met de regelgeving van de overheid. Denk bijvoorbeeld aan veranderingen in de APK wetgeving. Via de RDW worden deze wets- en regelwijzigingen ingevoerd en RDC moet hier zijn producten en diensten op aanpassen, dus ook de softwareleveranciers moeten hun pakketten aanpassen. Omdat er met deze veranderingen niet meer cashflow wordt gecreëerd en dit wel veel tijd en geld kost is het lastig dit commercieel uit te buiten. Een recent voorbeeld hiervan is de veranderingen omtrent APK afmelding waardoor RDC een investering van bijna EUR 200.000 moest doen om de dienst draaiende te houden, tegen deze kosten staan geen extra inkomsten. B4 Vercommercialisering RDW RDW biedt tegenwoordig gelijkwaardige diensten aan in dezelfde markt waar RDC actief in is. RDW is naast partner van RDC nu ook een directe concurrent geworden. De eindgebruikers kunnen via de internetsite van RDW hun APK meldingen, LPG meldingen, snelheidbegrenzer meldingen en tachograaf meldingen regelen.


HTS Autotechniek 22

In de toekomst zal RDW meer gelijkwaardige diensten gaan aanbieden. In een brief van drs. H. van Santen, directeur bedrijfsvoering RDW staat het volgende: “De RDW is van plan om in de toekomst meer dienstverlening direct via de internetsite mogelijk te maken en om deze in een bedrijfsportaal voor erkenninghouders beschikbaar te stellen. Dit om de kwaliteit van de publieke dienstverlening te verbeteren en de administratieve lasten te verlagen. Het gaat hier bijvoorbeeld om het uitbreiden van de rechtstreekse meldingen en het digitaal opvragen van de eigen bedrijfsvoorraad”. (bron: RDW.nl)


HTS Autotechniek 23

6. Confrontatiematrix In dit hoofdstuk is de confrontatiematrix weergegeven. Aan de hand van de SWOT is elk punt met elkaar vergeleken en gekeken hoe deze punten elkaar kunnen elimineren, versterken of verzwakken. Ieder kwadrant wordt apart besproken in de paragrafen aanvallen, verdedigen, versterken en terugtreden.

Figuur 3: Confrontatiematrix

o + + o -o o -

o o o o o -o o o

o o o o o o o o o

o o o + o o o o o

4 4 0

1 0 1

2 4 -2

0 3 -3

0 1 -1

1 1 0

Totaal

Vercommercialisering RDW

+ o o o o o o o o o

Aantal minnen

Wetswijzigingen de overheid

o + o -+ o + +

Aantal plussen

RDC heeft een ‘duur’ imago ten opzichte van concurrentie

B4

Concurrentie koppelt snel terug bij vragen/problemen

Marktleider Centraal punt voor afhandeling vragen en klachten Ervaren en vakkundig personeel Meer diensten dan concurrentie Lange lijnen binnen RDC/ trage oplostijd Softwareleverancier wordt gezien als klant en niet als relatie Geringe informatie voorziening richting softwareleveranciers Borging van kennis onvoldoende (persoon weg, kennis weg) Geen besef van vercommercialisering Testomgeving Aantal plussen Aantal minnen Totaal Aanvallen Verdedigen Versterken Terugtreden

B1

Groot netwerk in de branche

S1 S2 S3 S4 Z1 Z2 Z3 Z4 Z5 Z6

Bedreigingen B2 B3

SLA met softwareleveranciers Zwakten

Sterkten

Kansen K1 K2

1 2 1 1 0 1 0 0 1 1

1 0 0 0 3 0 4 2 1 1

0 2 1 1 -3 1 -4 -2 0 0

Toelichting matrix In de confrontatiematrix is gekeken naar de link tussen de punten uit de SWOT analyse. De matrix moet als volgt worden gelezen: ++

Tussen deze twee onderwerpen is een relatie dat een zeer positief effect kan hebben op de samenwerking tussen RDC en de softwareleveranciers. + Tussen deze twee onderwerpen is een relatie dat een positief effect kan hebben op de samenwerking tussen RDC en de softwareleveranciers. Hierbij is het effect kleiner dan in de bovenstaande situatie o Tussen deze twee onderwerpen is geen relatie Tussen deze twee onderwerpen is een relatie dat een negatief effect kan hebben op de samenwerking tussen RDC en de softwareleveranciers -Tussen deze twee onderwerpen is een relatie dat een zeer negatief effect kan hebben op de samenwerking tussen RDC en de softwareleveranciers. Hierbij is het effect groter dan de bovenstaande situatie In de onderstaande paragrafen worden alleen de punten besproken die zijn beoordeeld met een: ‘+ +’, ‘+’, ‘-‘ of een ‘- -‘. De punten beoordeeld met een ‘o’ zijn in mindere mate van belang en zullen daarom niet worden besproken.

6.1 Aanvallen In deze paragraaf worden de sterke punten van RDC in relatie gebracht met kansen die er zijn in de markt. De hoofdvraag hierbij is “hoe kan een sterkte van RDC gebruikt worden om op een kans in te spelen”. S1-K2: Marktleider - Groot netwerk in de branche (+) RDC is met veel producten en diensten marktleider in Nederland. Door optimaal gebruik te maken van het grote netwerk dat RDC heeft en de productdichtheid bij de klanten te vergroten kan RDC deze positie vasthouden in een markt waar steeds meer concurrenten actief zijn. Actieve acquisitie binnen het bestaande netwerk kan een manier zijn om het bestaande marktaandeel te behouden. S2-K1: Centraal punt voor afhandeling vragen en klachten - Service Level Agreements (SLA) met softwareleveranciers (+) Door het afhandelen van vragen en klachten op een centraal punt (KCC) kan de frequentie en de doorlooptijd van calls bijgehouden worden. Deze informatie kan gebruikt worden voor het opstellen van een SLA. Bij het opstellen van een SLA is het namelijk van belang om reële afspraken te maken die door beide partijen nagekomen kunnen worden. S4-K1: Meer diensten dan concurrentie - SLA met softwareleveranciers (-) Aanbieden van veel producten en diensten is een unique selling point die voor de eindgebruiker de doorslag kan geven om voor RDC te kiezen. Aanbieden van veel producten en diensten is echter nadelig als het aankomt op het samenstellen van een SLA. Voor ieder product en/of dienst moeten er afzonderlijke afspraken worden gemaakt. Hoe meer afspraken des te moeilijker het is om deze daadwerkelijk te realiseren en na te komen.

6.2 Verdedigen In deze paragraaf worden de sterke punten van RDC in relatie gebracht met de bedreigingen die op RDC afkomen. De hoofdvraag hierbij is “hoe kan een sterkte gebruikt worden om een bedreiging af te wenden”.


HTS Autotechniek 25

S1-B1: Marktleider - RDC heeft een ‘duur’ imago ten opzichte van concurrentie (-) RDC wordt in de markt als duur gezien, terwijl dat niet altijd het geval is (in bijlage X Prijsinformatie RDC tov concurrentie worden de prijzen van RDC met de concurrenten vergeleken). Het is voor RDC van belang om het prijs- en productbeleid goed te communiceren. Het is vooral van belang om te laten zien welk product de klant krijgt voor de prijs die hij ervoor betaald. Het grote marktaandeel van RDC kan het communiceren van het prijs- en productbeleid vergemakkelijken, omdat er direct contact is met een groot gedeelte van de markt. S2-B1: Centraal punt voor afhandeling vragen en klachten - Concurrentie koppelt snel terug bij vragen / problemen (+) De concurrentie koppelt sneller terug bij vragen en klachten in vergelijking met RDC, dit is gebleken uit marktonderzoek. Softwareleveranciers ervaren dit als negatief. Door het optimaliseren van het afhandelproces (door KCC een andere functie te geven in het proces) van de vragen en klachten kan RDC beter aan de verwachting van de softwareleveranciers voldoen, waardoor er minder frictie ontstaat tussen beide partijen. S3-B1: Ervaren en vakkundig personeel - Concurrentie koppelt snel terug bij vragen/problemen (+) RDC beschikt over veel ervaren personeel die zowel de organisatie als de markt goed kennen. Deze kennis kan gebruikt worden om de doorlooptijd van calls terug te dringen. Het komt nu nog te vaak voor dat een vraag bij de verkeerde persoon terecht komt, waardoor de vraag niet adequaat beantwoord wordt. Dit heeft een nadelig effect op de doorlooptijd en de kwaliteit van de antwoorden. S4-B4: Meer diensten dan concurrentie - Vercommercialisering RDW (+) Door de vercommercialisering van RDW zal RDC (en de concurrenten) marktaandeel kwijt raken, RDC zal hier als marktleider logischerwijs de meeste last van hebben. Door het uitgebreide dienstenpakket van RDC kan een terugval in marktaandeel van een bepaalde dienst goed worden opgevangen door een andere dienst.

6.3 Versterken In deze paragraaf worden de zwakke punten in relatie gebracht met kansen die op de markt spelen. Hierbij is de hoofdvraag “op welke manier kan een zwakte versterkt worden om op een kans in te spelen”. Z1-K1: Lange lijnen binnen RDC / trage oplostijd - SLA met softwareleveranciers (- -) De trage oplostijd binnen RDC moet eerst worden opgelost, voordat RDC een SLA kan afsluiten met softwareleveranciers. Een trage oplostijd kan door de concurrentie gebruikt worden om klanten bij RDC weg te lokken. Het nu overeenkomen van SLA is geen realistisch doel omdat de organisatie er nu nog niet klaar voor is. Z2-K1: Softwareleverancier wordt gezien als klant en niet als relatie - SLA met softwareleveranciers (+) Door het opstellen van een SLA kan RDC laten zien dat het de samenwerking met softwareleveranciers belangrijk vindt. De relatie tussen RDC en softwareleveranciers zal sterker worden, omdat er tussen beide partijen duidelijke afspraken gemaakt worden; men weet dus wat er van elkaar verwacht kan worden. Z4-K1: Borging van kennis onvoldoende (persoon weg, kennis weg) - SLA met softwareleveranciers (-) Een SLA heeft alleen meerwaarde als de gemaakte afspraken ook daadwerkelijk door beide partijen worden nageleefd. Door onvoldoende borging van kennis en documentatie zal er kennis verloren gaan,


HTS Autotechniek 26

wat zal leiden tot een verslechtering van het oplossend vermogen van RDC. Door een verslechtering van het oplossend vermogen van RDC kunnen de afspraken uit het SLA niet worden na gekomen. Z5-K1: Geen besef van vercommercialisering - SLA met softwareleveranciers (+) Door een goed gedefinieerde SLA op te stellen, dwingt RDC zichzelf om kritisch naar de eigen organisatie te kijken en de medewerkers op deze manier beter op hun verantwoordelijkheden te wijzen, waardoor de controle ook omhoog gaat. Prestaties kunnen beter worden gemeten en daarom ook worden verbeterd. Z6-K1: Testomgeving - SLA met softwareleveranciers (+) Door in de toekomst de testomgeving op te nemen in het SLA verplicht RDC zichzelf om de testomgeving op een bepaald niveau te brengen. Dit niveau moet voor beide partijen acceptabel en functioneel zijn. Tevens is het een goed hulpmiddel om verbeteringen en ontwikkelingen in samenspraak met de softwareleveranciers door te voeren.

6.4 Terugtreden In deze paragraaf worden de zwakke punten in relatie gebracht met bedreigingen die op de markt zijn. Hierbij is de hoofdvraag “hoe kan een zwakte zodanig versterkt worden om een bedreiging het hoofd te bieden”. Z1-B1: Lange lijnen binnen RDC / trage oplostijd - Concurrentie koppelt snel terug bij vragen / problemen (- -) Bij RDC duurt de terugkoppeling vaak lang wat tot irritatie bij de softwareleveranciers kan leiden. Dit effect wordt versterkt doordat de concurrentie wel in staat is om snel terug te koppelen. Z3-B1: Geringe informatievoorziening richting softwareleveranciers - Concurrentie koppelt snel terug bij vragen/problemen (-) Door de geringe informatievoorziening ontstaan er veel vragen en klachten bij de softwareleveranciers, de softwareleveranciers nemen naar aanleiding hiervan contact op met KCC die een call aanmaakt en deze doorstuurt naar de tweede lijn. Door het hoge aantal calls zal de oplostijd toenemen. Door de informatievoorziening te verbeteren zal het aantal calls afnemen en daardoor de oplostijd van andere calls afnemen omdat hier meer tijd voor is. Z3-B2: Geringe informatievoorziening richting softwareleveranciers - RDC heeft een ‘duur’ imago ten opzichte van concurrentie (- -) RDC voorziet softwareleveranciers en de eindgebruikers niet alleen onvoldoende van technische informatie, maar ook van commerciële informatie. Dit is gebleken uit marktonderzoek, veel van de ondervraagden gaven aan RDC duur te vinden. Door de markt te voorzien van gespecificeerde productinformatie (wat krijg je voor je geld) kan dit imago worden omgevormd. Z3-B3: Geringe informatievoorziening richting softwareleveranciers – Wetswijzigingen van de overheid (-) Als de overheid een wetswijziging doorvoert moeten RDC en de softwareleveranciers aanpassingen aanbrengen om aan de nieuwe eisen van de overheid te voldoen. Het is belangrijk dat RDC de softwareleveranciers tijdig op de hoogte stelt van de veranderingen die gaan komen, zodat de softwareleveranciers de mogelijkheid krijgen om de aanpassingen door te voeren. Het is ook van belang dat RDC de softwareleveranciers duidelijk de reden van de veranderingen communiceert, bijvoorbeeld dat het deze niet zelf initieert, maar dat het in opdracht van RDW wordt uitgevoerd.


HTS Autotechniek 27

Z4-B1: Borging van kennis onvoldoende (persoon weg, kennis weg) - Concurrentie koppelt snel terug bij vragen / problemen (-) Zoals eerder gezegd beïnvloed onvoldoende borging van kennis en documentatie de oplostijd van vragen en klachten nadelig. Hierdoor moeten de softwareleveranciers langer wachten op de terugkoppeling van hun vragen en klachten in vergelijking met de concurrentie. Z5-B4: Geen besef van vercommercialisering - Vercommercialisering RDW (-) RDC opereert nog niet consequent als een commercieel bedrijf. Er wordt nog te weinig gekeken en geluisterd naar de markt. Hierdoor is er ook geen samenwerking met de markt. Omdat concurrenten dit wel doen, kan dit voor klanten een keuze zijn om te veranderen van provider. RDW biedt sinds kort gelijkwaardige producten aan als RDC in dezelfde markt en is nu in plaats van partner ook een concurrent geworden. Z6-B1: Testomgeving - Concurrentie koppelt snel terug bij vragen / problemen (-) De vragen die aan de hand van de testen ontstaan worden net als de overige vragen door KCC opgeslagen in Topdesk en in behandeling genomen. Uit onderzoek is gebleken dat de oplostijd van deze vragen in vergelijking met de concurrentie te lang is. Een lange doorlooptijd veroorzaakt niet alleen irritatie bij de softwareleveranciers maar kost ze ook veel tijd (en dus ook geld). Omdat de softwareleveranciers meer moeten investeren zal hun marge kleiner worden. Aangezien de concurrentie wel snel terugkoppeling geeft op de vragen en klachten kan dit een reden zijn om voor de concurrent te kiezen.


HTS Autotechniek 28

7. Analyse van oplossingen voor knelpunten In dit hoofdstuk worden oplossingen aangedragen voor de knelpunten die er zijn. Vanuit de SWOT en confrontatiematrix zijn er een aantal oplossingen opgesteld die de knelpunten moeten verhelpen. Bij het opstellen van de oplossingen is rekening gehouden met de behoeften die er zijn in de markt (met behulp van de telefonische en verdiepende) en de mogelijkheden binnen RDC om de knelpunten aan te pakken (met behulp van de interne interviews).

7.1 Contactpunt RDC voor softwareleveranciers Uit het onderzoek is gebleken dat de softwareleveranciers niet tevreden zijn met de huidige manier van communicatie met RDC. In dit hoofdstuk worden met behulp van stroomschema’s verschillende scenario’s beschreven voor het beantwoorden en oplossen van vragen en klachten van de softwareleveranciers. Naast de huidige situatie komen de volgende vier scenario’s aan bod: Scenario 1: KCC wordt eigenaar van de call en is verantwoordelijk voor de doorlooptijd Scenario 2: Incident manager wordt eigenaar van de call en is verantwoordelijk voor de doorlooptijd Scenario 3: Er komt een technisch specialist op KCC die verantwoordelijk wordt voor de softwareleveranciers Scenario 4: De tweede lijn koppelt direct terug naar de softwareleverancier Huidige situatie Terugkoppeling

Terugkoppeling SWL neemt contact op met RDC via KCC

Call

KCC maakt call aan in Topdesk en probeert eerst zelf een oplossing te geven

Geen oplossing

Terugkoppeling

KCC stuurt call via Topdesk naar tweede lijn

BSM, FB of AB nemen de call over en proberen een oplossing te geven

Figuur 4: Routing call in de huidige situatie

Opgelost

De call wordt in Topdesk gereed gemeld


HTS Autotechniek 29

In de huidige situatie nemen softwareleveranciers bij vragen en klachten contact op met het Klant Contact Centrum (KCC) van RDC. Bij KCC zijn acht callcenter agents werkzaam die verantwoordelijk zijn voor het afhandelen van binnenkomende vragen en klachten, deze worden calls genoemd. De afdeling wordt aangestuurd door drie zogenaamde incidentmanagers. Iedereen (in dit geval softwareleveranciers) die contact opneemt met RDC komt in principe binnen bij het KCC waar ze te woord worden gestaan door een van de callcenter agents (eerste lijn). Er wordt geprobeerd om zoveel mogelijk vragen en klachten direct te beantwoorden, dit percentage ligt op 80%. 68% van de calls die binnenkomen worden geregistreerd in Topdesk, dit programma maakt het mogelijk de call te delen met specialisten en de voortgang te controleren. Als de callcenter agent de vraag of klacht direct kan beantwoorden of oplossen wordt de call gereed gemeld in Topdesk. Als de callcenter agent niet in staat is om direct een passende oplossing te geven wordt de vraag of klacht zo goed mogelijk beschreven in Topdesk en doorgestuurd naar een specialist (tweede lijn) die de call overneemt. De tweede lijn, vaak iemand van de afdeling Business Service Management (BSM), Applicatie Beheer (AB) of Functioneel Beheer (FB), is vanaf dat moment verantwoordelijk voor het oplossen van de call en het terugkoppelen van de oplossing naar KCC. Het KCC neemt dan weer contact op met de softwareleverancier waarna de call gereed wordt gemeld in Topdesk. Voordeel: Single point of contact Nadeel: Technische kennis KCC medewerkers vaak onvoldoende voor vragen van SWL Geen bewaking van calls in tweede lijn Lange doorlooptijd van calls Niet alle calls worden geregistreerd Niemand is ‘eigenaar’ van de call Geen duidelijke afspraken over oplostijden met SWL


HTS Autotechniek 30

Scenario 1: KCC wordt eigenaar van de call en is verantwoordelijk voor de doorlooptijd Terugkoppeling Terugkoppeling SWL neemt contact op met RDC via KCC

Call


Bewaking naar de afdelingen

Opgelost

De call wordt in Topdesk gereed gemeld Terugkoppeling van de afdelingen

Geen oplossing KCC stuurt call via Topdesk naar tweede lijn Hotline

AB neemt hotline op en neemt call over

Hotline

Hotline

FB neemt hotline op en neemt call over

BSM neemt hotline op en neemt call over

Figuur 5: Routing call in scenario 1

Deze situatie is in principe hetzelfde als de huidige situatie. Het verschil zit hem in het feit dat degene die de call heeft aangemaakt en de call naar de tweede lijn stuurt nu verantwoordelijk is voor de doorlooptijd. Hij of zij moet er dus actief voor zorgen dat de call binnen de afgesproken tijd wordt opgelost en wordt gecommuniceerd met de softwareleverancier, de bewaking van de call ligt dus volledig in handen van KCC. Dit kan door middel van een lijst met openstaande calls die beschikbaar is per callcenter agent met daarbij de afgesproken oplostijd. Indien de callcenter agent de call niet kan beantwoorden en het probleem heeft een dusdanige urgentie dat deze direct opgelost dient te worden, dan kan de agent er voor kiezen om de telefoon direct door te verbinden met een van de technische afdelingen. Dit is een centrale telefoon (hotline) die opgenomen moet worden door iemand op de afdeling die op dat moment geen werkzaamheden aan het doen is die een hogere prioriteit hebben dan het beantwoorden van de call en het helpen van de softwareleverancier. De softwareleverancier krijgt dan iemand te spreken die zijn probleem in de meeste gevallen direct kan oplossen. Voordeel: Controle over de voortgang van de call Doorlooptijd sluit aan bij verwachting SWL omdat hier afspraken over zijn gemaakt Snellere terugkoppeling naar SWL Vertraging kan aan SWL worden doorgegeven Calls kunnen sneller naar tweede lijn worden doorverbonden


HTS Autotechniek 31

Nadeel: Voor de softwareleverancier verandert er niets, die krijgt nog steeds iemand aan de lijn die hem (vaak) niet direct kan helpen Doorlooptijd erg afhankelijk van reactiesnelheid tweede lijn Terugkoppeling door KCC medewerker, kan wedervragen vaak niet beantwoorden KCC medewerker moet oplossingen communiceren die hij zelf niet altijd snapt KCC medewerker spreekt andere ‘taal’ dan SWL Scenario 2: Incident manager wordt eigenaar van de call en is verantwoordelijk voor de doorlooptijd Terugkoppeling SWL neemt contact op met RDC via incident manager (direct nummer of een keuze In Menu)

Terugkoppeling Call

Incident manager maakt call aan in Topdesk en probeert eerst zelf een oplossing te geven

Opgelost


Geen oplossing

Bewaking

Incident manager stuurt call via Topdesk naar tweede lijn

Terugkoppeling

BSM, FB of AB nemen de call over en proberen een oplossing te geven Figuur 6: Routing call in scenario 2

In deze situatie komen alle calls van de softwareleveranciers binnen bij een van de drie incidentmanagers. Deze maakt ook de call aan in Topdesk en als er niet direct een oplossing gegeven kan worden wordt de call naar de tweede lijn gestuurd. De incidentmanager is verantwoordelijk voor de bewaking van de call en moet er voor zorgen dat de afgesproken oplostijd niet wordt overschreden. Voordeel: Betere controle over de voortgang van de call Incidentmanagers hebben meer invloed op de medewerkers van de tweede lijn dan de KCC medewerkers Doorlooptijd sluit aan bij verwachting SWL omdat hier afspraken over zijn gemaakt Softwareleverancier krijgt incidentmanager aan de lijn waardoor deze het gevoel krijgt dat hij ‘belangrijk’ is en er naar hem geluisterd wordt


HTS Autotechniek 32

Nadeel: Telefoon aannemen geen taak voor incidentmanager Incidentmanager is geen technisch specialist Doorlooptijd erg afhankelijk van reactiesnelheid tweede lijn Scenario 3: Er komt een technisch specialist op KCC die verantwoordelijk wordt voor de softwareleveranciers Terugkoppeling

SWL neemt contact op met RDC via technisch medewerker op KCC (direct nummer)

Terugkoppeling Call

Technisch medewerker maakt call aan in Topdesk en probeert eerst zelf een oplossing te geven

Opgelost


Geen oplossing

Bewaken

Technische medewerker stuurt call via Topdesk naar tweede lijn

Terugkoppeling



In deze situatie komt er een technisch specialist op het KCC die verantwoordelijk is voor alle calls van de softwareleveranciers. Hierdoor wordt het oplosvermogen van het KCC enorm vergroot en zullen er minder calls naar de tweede lijn worden doorgestuurd. De technisch specialist moet over dusdanige kennis beschikken dat hij in staat is om 90% van alle binnenkomende calls direct te beantwoorden. De calls die naar de tweede lijn worden doorgestuurd (maximaal 10% van de calls wordt geëscaleerd naar de afdeling BSM, FB of AB) vallen onder de verantwoordelijkheid van de technisch specialist, deze moet de voortgang bewaken. Voordeel: Spreekt dezelfde ‘taal’ als softwareleveranciers Oplosvermogen KCC wordt verbeterd Oplossingen kunnen vaker direct gegeven worden, inclusief beantwoording van wedervragen Minder calls door naar tweede lijn


HTS Autotechniek 33

Service level KCC omhoog Nadeel: Te weinig capaciteit op piekmomenten Scenario 4: De tweede lijn koppelt direct terug naar de softwareleverancier Terugkoppeling

SWL neemt contact op met RDC via KCC

Call


Opgelost


Geen oplossing Gereed melden

KCC stuurt call via Topdesk naar tweede lijn

Terugkoppeling

Bewaking



Deze situatie is dezelfde als de tweede, met als enig verschil dat de tweede lijn de oplossing direct terugkoppelt naar de softwareleverancier, zonder tussenkomst van KCC. Voordeel: SWL krijgt terugkoppeling van specialist Nadeel: ‘Single point of contact’ verdwijnt Tweede lijn krijgt er een taak bij Controle over calls wordt minder (doorlooptijd)


HTS Autotechniek 34

Keuzetabel inrichting KCC

Wat wil de SWL Impact op de organisatie Kosten Controle intern Impact op doorlooptijd call Registratie van calls

Weegfactor Scenario 1 4 8 3 12 3 9 3 9 2 6 2 2 Totaal:

46

Scenario 2 8 9 9 12 4 2 44

Scenario 3 16 9 3 9 8 6

Scenario 4 12 3 9 6 6 4

51 40 Tabel 2: Keuzetabel inrichting KCC

Weegfactor: 1, 2, 3, 4. (1 minst gunstig, 4 meest gunstig) Punten: 1, 2, 3, 4 vermenigvuldigd met weegfactor Wat wil de softwareleverancier: Komt het scenario overeen met de wens van de softwareleverancier, namelijk een korte doorlooptijd van calls, goede oplossingen en antwoorden waar ze direct mee verder kunnen. Er is gekozen voor weegfactor vier omdat dit punt het allerbelangrijkste is en in vergelijking met de andere factoren het zwaarste moet wegen. Impact op de organisatie: Welke impact heeft de verandering op de organisatie, hoeveel afdelingen en werknemers moeten op een andere manier gaan werken en welke werknemers krijgen welke taken (erbij). Dit punt heeft weegfactor drie gekregen omdat dit een bepalende factor is voor het succes van de maatregelen. Kosten: Wat zijn de kosten van de verandering? Kosten zijn uiteraard erg belangrijk, om toch onderscheid te maken tussen de wensen van softwareleveranciers heeft dit punt weegfactor drie gekregen. Controle intern: Is de interne controle (bewaking) op de calls goed te bepalen? Kan het management aan de hand van deze gegevens de organisatie sturen? Er is gekozen voor weegfactor drie omdat controle op de doorlooptijd en het naleven van de gemaakte afspraken (met softwareleverancier) een van de speerpunten is in de nieuwe situatie. Impact op de doorlooptijd van de call: Wordt de doorlooptijd van calls echt aanzienlijk korter in het nieuwe scenario? De doorlooptijd is een belangrijk verbeterpunt, maar niet bepalend voor de nieuwe situatie, daarom is gekozen voor weegfactor twee. Registratie van de calls: Wordt iedere call SMART geregistreerd en kunnen deze gegevens worden gebruikt voor productverbetering? Het is belangrijk om iedere call goed te beschrijven en te registreren, omdat ook dit punt geen bepalende factor is heeft deze weegfactor twee gekregen. Uit de keuzetabel komt scenario 3: Er komt een technisch specialist op KCC die verantwoordelijk wordt voor de softwareleveranciers het beste naar voren, dit scenario scoort 51 van de maximaal 68 te behalen punten (75%).


HTS Autotechniek 35

Wat wil de softwareleverancier: 16 van de 16 punten De softwareleverancier krijgt in dit scenario direct iemand te spreken met technische kennis van hetzelfde niveau als hijzelf, daardoor wordt het gemakkelijker om het probleem uit te leggen en kan er in veel gevallen direct een oplossing worden gegeven. Indien de call de tweede lijn in gaat, wordt deze bewaakt door de technisch specialist, die er voor zorgt dat de softwareleverancier op de hoogte wordt gehouden van de status van de call en binnen de afgesproken termijn een oplossing communiceert (nee kan ook een antwoord zijn). Dit scenario sluit naadloos aan bij de wens en verwachting van de softwareleverancier. Impact op de organisatie: 9 van de 12 punten Dit scenario heeft een redelijke impact op de organisatie. Er ontstaat een nieuwe functie op KCC, namelijk die van een technische specialist die het aanspreekpunt wordt voor de softwareleverancier, hiervoor moet er een speciaal nummer en een speciaal e-mail adres komen die de softwareleverancier kan gebruiken. De technisch specialist is ook verantwoordelijk voor alle tweede lijn calls, deze verantwoordelijkheid zorgt ervoor dat hij werknemers op andere afdelingen moet kunnen aansturen, hierdoor moet hij in de hiërarchie van RDC een trede hoger op de ladder staan dan diegene waar hij de call naar toe stuurt, zodat hij diegene kan aansturen en prioriteit kan geven aan het oplossen van de call Kosten: 3 van de 12 punten Er ontstaat een nieuwe functie op KCC en deze moet worden ingevuld door een technisch specialist, deze specialist zal meer kosten dan een reguliere call center agent van KCC. Ook in het om- en bijscholen van deze persoon zal geld moeten worden gestoken. Controle intern: 9 van de 12 punten Omdat de calls van de softwareleveranciers allemaal binnenkomen bij een persoon, is het gemakkelijk om veel voorkomende problemen te rapporteren. Dit kan kostbare informatie zijn voor de ontwikkeling van bestaande en nieuwe producten, met deze informatie kan RDC nog meer voldoen aan de vraag in de markt. Ook de bewaking van de doorlooptijd van de calls kan beter worden uitgevoerd. Omdat deze persoon hier ook de bevoegdheden voor heeft, kan hij rapporteren naar de directie, die op zijn beurt de afdelingen op hun verantwoordelijkheden kunnen wijzen. Impact op de doorlooptijd van de call: 8 van de 8 punten Omdat de technisch specialist calls vaak direct kan afhandelen zal de doorlooptijd drastisch omlaag gaan. Calls die naar de tweede lijn gaan worden beter beschreven voor degene die hem moet behandelen, hierdoor ontstaan er minder onduidelijkheden zodat er ook geen verkeerde antwoorden worden gecommuniceerd met de softwareleverancier. Ook de bewaking van de calls is in vergelijking met de huidige situatie beter en ook voor deze calls gaat de doorlooptijd omlaag. Registratie van de calls: 6 van de 8 punten Iedere call moet geregistreerd worden in Topdesk, van de aanname met een beschrijving van het probleem, tot de terugkoppeling (naar de softwareleverancier) met de oplossing. Omdat de technisch specialist minder afhankelijk is van de tweede lijn, kan de registratie van iedere call beter worden gedaan waardoor er in het traject minder informatie verloren gaat. Niveau van de technisch specialist De kennis en vaardigheden van de technisch specialist die op het KCC er bijkomt, moet van een dusdanig niveau zijn dat softwareleveranciers er echt voordeel bij hebben. Enkele eisen waaraan de technisch specialist moet voldoen:


HTS Autotechniek 36

De technisch specialist moet: Weten welke producten en diensten RDC levert aan softwareleveranciers Weten hoe de producten en diensten van RDC zijn opgebouwd (functioneel ontwerp) Op de hoogte zijn en mee kunnen praten met programmeertalen die binnen RDC worden gebruikt 90% van de binnenkomende calls kunnen oplossen Informatie waarover hij moet beschikken: Welke mogelijke en veel voorkomende foutmeldingen er zijn (in test en live) Wanneer updates en nieuwe releases gepland zijn Welke testontwikkelingen er zijn Wie kan er benaderd worden met welk probleem Daarnaast moet deze persoon natuurlijk bekend raken met de organisatie en hulpmiddelen die worden gebruikt zoals Topdesk en RDC-wiki. Doelstellingen KCC De technisch specialist eigenaar te maken van een incident wat hij aanneemt (Dagelijkse) controle door technisch specialist of de tweede lijn calls binnen de gemaakte afspraken worden teruggekoppeld Bereikbaarheid van 100%, als de technisch specialist niet bereikbaar is (in gesprek, vakantie of ziekte) zorgen voor back up. Dit kan incident manager zijn of een andere technische medewerker Pro actief terugkoppelen naar klant als oplostijd niet gehaald wordt Oplostijden en overschrijdingen inzichtelijk maken via eenduidige rapportage Intern afspraken maken over oplostijden en een KPI vaststellen (zie hoofdstuk 7.5 voor een nadere toelichting) Mogelijkheid inrichten voor technisch specialist om hiërarchisch te escaleren als interne afspraken over teveel overschrijdingen niet worden nagekomen Kosten en baten Het scenario kent veel voordelen, echter moeten er wel kosten worden gemaakt om tot de verbeteringen te komen. Hieronder zijn de kosten en baten puntsgewijs opgesomd. Kosten: Kosten voor opleiding (om- en bijscholen) technisch specialist Loonkosten (1 FTE) Kosten voor werkplek Kosten voor direct nummer en e-mail adres Baten: Minder leegloop van klanten (behoud van marktaandeel) Betere verstandhouding met softwareleveranciers Veel informatie uit de markt over het functioneren van diensten Bruikbare informatie uit de markt voor productverbetering

7.2 Testomgeving Momenteel beschikt RDC niet over een dedicated testomgeving. Er kan van een dedicated testomgeving gesproken worden als er op de server (van RDC) een afzonderlijk gedeelte is gereserveerd voor testapplicaties.


HTS Autotechniek 37

De huidige testcyclus verloopt als volgt: RDC ontwikkelt een nieuw product of dienst, voorzien de softwareleveranciers van testdata en de XML eigenschappen van het betreffende product of dienst. De testdata bestaat meestal uit enkele voorbeeld kentekens waarmee softwareleveranciers kunnen testen. Met elk kenteken is iets bijzonders aan de hand (hierbij kan gedacht worden aan kentekens die bij APK afmelden moeten wachten op een steekproef of een kenteken van een gestolen auto wat van belang is voor verzekeringsmaatschappijen). Als softwareleveranciers problemen ondervinden tijdens het testen nemen ze contact op met KCC. De testgerelateerde vragen bestaan voor een groot deel uit tweede lijns vragen. KCC maakt dus een call aan voor de technische medewerkers en zij zoeken uit waardoor het probleem dat de softwareleverancier heeft geconstateerd wordt veroorzaakt. In dit stadium is tijd een kostbaar goed aangezien de softwareleverancier een of meerdere testers hebben ingezet voor het testen van de nieuwe software. Het is het voor RDC van belang om snel te schakelen om de klantentevredenheid hoog te houden. Momenteel worden de vragen die naar aanleiding van de testcyclus binnen komen bij KCC aangepakt zoals beschreven in hoofdstuk 7.1 huidige situatie Wensen uit de markt Uit de telefonische interviews is gebleken dat de huidige testomgeving van RDC niet naar de wensen van de softwareleveranciers functioneert. Hierdoor is er tijdens de verdiepende interviews veel aandacht besteed aan de testomgeving. De doelstelling was om te onderzoeken wat er fout gaat met de huidige situatie en hoe de softwareleveranciers de testomgeving graag zien. Onderbouwing testdata Zoals eerder vermeld voorziet RDC softwareleveranciers van testdata. De testdata bestaat meestal uit enkele voorbeeld kentekens. Testdata kan bijvoorbeeld ook uit rijbewijsnummers bestaan. Bijvoorbeeld voor het testen van de DVS service. Het is van belang om voor ieder mogelijk scenario een voorbeeld kenteken te leveren aan softwareleveranciers. Bijvoorbeeld als er veranderingen zijn voor de APK afmelding en door benodigde aanpassingen getest moet worden, hebben de softwareleveranciers vier kentekens nodig om mee te testen, namelijk: Een kenteken van een benzine auto die goedgekeurd wordt Een kenteken van een diesel auto die goedgekeurd wordt Een kenteken van een auto die afgekeurd wordt Een kenteken van een auto die moet wachten op een steekproef Uit de verdiepende interview is naar voren gekomen dat RDC over het algemeen wel alle kentekens die nodig zijn om te kunnen testen levert, maar er geen toelichting bij geeft. De softwareleveranciers weten niet welke functie aan welk kenteken gekoppeld is. Dit maakt het testproces ingewikkelder voor softwareleveranciers. Ongelimiteerde testmogelijkheden Testen is een kostbare handeling voor zowel RDC als voor softwareleveranciers. Daarom willen beide partijen de testcyclus zo kort mogelijk houden. De testcyclus wordt in het huidige situatie opgehouden doordat de softwareleveranciers een bepaalde handeling bijvoorbeeld maar een keer per dag kunnen uitvoeren. De softwareleveranciers kunnen die dag niet verder testen. Een voorbeeld hiervan is INDI. De softwareleveranciers moeten 48 uur per handeling wachten op een antwoord van RDC. Als de


HTS Autotechniek 38

softwareleveranciers ongelimiteerd zouden kunnen testen, zou de testcyclus vele malen sneller verlopen. Toelichting foutmeldingen Uit de verdiepende interviews is naar voren gekomen dat de foutmeldingen die de softwareleveranciers krijgen gedurende de testcyclus niet juist of niet duidelijk zijn. Hierbij kan gedacht worden aan foutmeldingen als “een van de velden is niet correct ingevuld”. Dit is een foutmelding waar de softwareleveranciers weinig mee kunnen, omdat ze niet weten welk veld niet correct is ingevuld. Direct contactpersoon De softwareleveranciers hebben aangegeven dat ze de voorkeur geven aan een direct contactpersoon voor testgerelateerde vragen. Deze persoon moet over voldoende kennis beschikken en op de hoogte zijn van de mogelijke foutmeldingen. Deze wens heeft veel raakvlak met de scenario’s in hoofdstuk 7.1 (er komt een technisch specialist op KCC die verantwoordelijk wordt voor de softwareleveranciers). Test release en. live release De softwareleveranciers hebben aangegeven dat ze vaak verschillen ontdekken tussen de test release en de live release. Een voorbeeld hiervan is ORB, in de test release werd er gebruik gemaakt van kleine letters voor het programmeren en in de live release werd er gebruik gemaakt van hoofdletters. Hierdoor werkten sommige functies niet meer in de live versie terwijl deze wel werkten in de test. Het is een kleine verandering met grote gevolgen die beter gecommuniceerd had moeten worden naar de softwareleveranciers. De standaard procedure is dat er een test release komt. Als er aan de hand hiervan veranderingen nodig zijn moet er nog een test release komen en als dat goed bevonden wordt volgt de live release (in figuur 9 is deze methode schematisch weergegeven). De extra test release wordt in sommige gevallen overgeslagen. Dit kan komen door bijvoorbeeld gebrek aan tijd of omdat het financieel veel nadelen heeft. Gevolg hiervan is dat de softwareleveranciers veel veranderingen moeten doorvoeren na de release van de live versie.


HTS Autotechniek 39

RDW voert een verandering door

RDC past producten en diensten aan nav veranderingen

RDC test de aanpassingen

De testdata op basis van de verandering gecommuniceerd met softwareleveranciers Softwareleveranciers voeren aanpassingen door in hun softwarepakketten

Softwareleveranciers testen de applicatie

Indien negatieve testresultaten, opnieuw aanpassingen doorvoeren

De resultaten van de testcyclus worden met RDC gecommuniceerd Testresultaten zijn positief De live release wordt vrijgegeven

Softwareleveranciers communiceren naar hun klanten dat de nieuwe release live is

Figuur 9: testcyclus RDC

7.3 Documentatie Goede en up to date zijnde documentatie is van groot belang voor softwareleveranciers om de producten en diensten van RDC te integreren in de door hen aangeboden softwarepakketten. Het vergemakkelijkt het integratieproces bij de softwareleverancier, waardoor deze zonder problemen zijn werk kan doen. Uit de telefonische en verdiepende interviews is gebleken dat de softwareleveranciers over het algemeen niet tevreden zijn over de huidige documentatie en de communicatie omtrent de documentatie. In dit hoofdstuk wordt aan de hand van wensen en eisen van de softwareleveranciers een aanbeveling gegeven aan RDC om op dit vlak te voldoen aan de verwachtingen van de markt. Verschillende soorten documentatie Inbouwen van functionaliteiten Dit is het belangrijkste onderdeel van de documentatie. Dit wordt door de softwareleveranciers gebruikt als vertrekpunt bij het integreren van (RDC) diensten. Hierin dient onmiskenbaar beschreven te zijn hoe een dienst werkt en is opgebouwd, welke foutmeldingen er kunnen voorkomen en welke retourberichten de softwareleverancier kan verwachten. Onderdelen die niet mogen ontbreken in de documentatie:


HTS Autotechniek 40

o

Functionaliteit van de dienst

o

(Technische) opbouw van de dienst

o

Mogelijke foutmeldingen

o

Vraag en antwoord (retour) berichten

o

Procesbeschrijving

Op dit moment wordt er door RDC hard gewerkt aan een document (vanaf nu: PIT gids) waarin deze onderdelen uitvoerig worden beschreven voor elke FTP- en transactionele dienst die RDC levert. Testen De documentatie voor de testomgeving is ook erg belangrijk. Als de softwareleverancier de dienst heeft geïntegreerd in zijn pakket, wordt deze eerst getest (en indien nodig aangepast en opnieuw getest) voordat deze in productie gaat. Voor het testen heeft de softwareleverancier testdata nodig, dit bestaat meestal uit voorbeeldkentekens (zie hoofdstuk 7.2 testomgeving). Bijvoorbeeld voor het testen van de APK applicatie zijn de volgende gegevens nodig: o Kentekens en gegevens van de kentekens 

Benzine en diesel voertuig



APK goedgekeurd, afgekeurd en steekproef

Releases/updates Bij het uitbrengen van een nieuwe dienst (release) of een update van een dienst is het van belang de softwareleverancier tijdig te informeren over de veranderingen, zodat deze zich daar ook op kan voorbereiden. Tevens dient deze informatie verwerkt te worden in de PIT gids. Onderwerpen die hierin moeten staan zijn: o

Wat zijn de exacte veranderingen ten opzichte van de oude situatie

Communicatie naar SWL Uit de telefonische interviews is gebleken dat alle softwareleveranciers het liefst door middel van emails op de hoogte gehouden willen worden over nieuwe releases en updates. Informatie die in de begeleidende e-mails moet staan is: o

Waarom zijn deze veranderingen gedaan (als dit relevant is)

o

Indien nodig: vanaf welke datum kan er worden getest in de nieuwe situatie 

o

Welke gegevens (kentekens) kunnen worden gebruikt in de test

Vanaf welke datum is de update in productie (dus niet meer testen)

Bereikbaarheid op website Omdat de PIT gids een levend document is dat regelmatig aangepast zal moeten worden, kan dit het beste op de website van RDC (RDC.nl) worden geplaatst. Op die manier is de laatste versie van de PIT gids altijd en overal voor iedereen beschikbaar. Om irritatie te voorkomen moet de PIT gids snel te vinden zijn. Om een voorbeeld te geven: de huidige documentatie is zodanig ‘verstopt’ op de website van RDC, dat deze haast onvindbaar is voor iemand die de website niet door en door kent. Na een half


HTS Autotechniek 41

uur zoeken op de website hebben wij (Ehsan en Benjamin) de documentatie niet kunnen vinden. Terwijl de concurrentie (VWE op VWE.nl) de documentatie drie klikken vanaf de homepage heeft staan. Up to date houden van documentatie Zoals al eerder gezegd zit de waarde van de PIT gids in de actualiteit ervan. Updates en nieuwe releases moeten direct verwerkt worden in de gids. Het is aan te raden om in de PIT gids ruimte te reserveren voor versiecontrole, daar kan in een oogopslag worden bekeken waar de gids is aangepast en welke versie de meest recente is.

7.4 Het borgen van kennis Voor ieder bedrijf is kennis een belangrijke factor om zich te onderscheiden in de markt. Denk hierbij aan kennis van producten, productieprocessen, klanten, markten, diensten, doelgroepen en marketing. Door het borgen van deze kennis zal het niet verloren gaan als een werknemer om welke reden dan ook RDC verlaat. Borging van kennis zorgt er voor dat de werkzaamheden kunnen worden uitgevoerd door verschillende personen, je bent minder afhankelijk van die ene specialist. Borging van kennis maakt het mogelijk dat de juiste kennis, op het juiste moment, op de juiste plaats aanwezig is. Hierdoor hoeft het wiel niet steeds opnieuw uitgevonden te worden. Bij borging van kennis moet er rekening worden gehouden met de volgende factoren: Documenteren Door het vastleggen van kennis in informatiesystemen, zoals een (online) portal of een databank wordt de informatie voor meer werknemers toegankelijk en daardoor waardevoller. RDC-wiki en Topdesk zijn twee (informatie) systemen die RDC kan gebruiken voor het vastleggen van informatie over bijvoorbeeld producten, processen, markten en klanten. Toegankelijk maken Het vastleggen van informatie is de eerste stap in de borging van kennis. Het personeel moet ook op de hoogte zijn van de specialiteiten van elkaar, zodat ze weten wie ze kunnen raadplegen bij een vraag of een probleem. Hier kan RDC-wiki een grote rol in spelen, iedere werknemer heeft hier al een eigen pagina met informatie over zichzelf. Uitwisselen van kennis Het delen van bestanden, ervaringen en vaardigheden is zeer belangrijk voor de borging van de kennis. Zorg ervoor dat je collega’s op de hoogte zijn van je werkzaamheden en resultaten daarvan. Afstand tussen afdelingen kunnen het delen van kennis belemmeren, hierdoor wordt de kennis niet met het gehele bedrijf gedeeld. Hergebruik van kennis Als een proces of handeling al eerder in kaart is gebracht, is het verspilde tijd om dit te herhalen. Door gebruik te maken van de kennis die al aanwezig is binnen RDC zal de waarde van deze kennis toenemen. Ook kennis die bij softwareleveranciers aanwezig is, of met hen is ontwikkeld kan worden (her)gebruikt. (bron: SCFB.nl) Instrumenten en maatregelen Het is van belang om het personeel goede instrumenten te geven waarmee het mogelijk wordt om zoveel mogelijk kennis te delen. RDC heeft met RDC-wiki en Topdesk twee uitstekende manieren om kennis over de organisatie, processen, technologie, klanten en markten vast te leggen. Naast deze twee


HTS Autotechniek 42

bestaande systemen wordt er gewerkt aan de implementatie van een nieuw CRM systeem (Microsoft Dynamics). Dit zal als eerst in gebruik worden genomen door de afdelingen Marketing en Sales. Na een proefperiode zal het systeem ook worden uitgerold over de andere afdelingen van de organisatie. Deze drie instrumenten moeten beter worden benut. Hier moet het personeel ook de tijd en ruimte voor krijgen.

7.5 KPI KPI staat voor Key Performance Indicator of Kritische Prestatie Indicator. Een KPI is een handige tool voor beleidsmakers om een beeld te krijgen van de onderneming met betrekking tot prestaties in relatie met de gestelde doelen. Een KPI zal RDC helpen om haar continuïteit in haar bedrijfsprocessen te handhaven. Om een goed controlesysteem te hebben moeten KPI’s worden bewaakt met behulp van kengetallen, een KPI dient dan ook altijd SMART geformuleerd te worden. De bedrijfsprocessen worden gekoppeld aan vastgestelde KPI’s. Een KPI wordt dus uitgedrukt in een getal en gerelateerd aan een norm of target. Veel voorkomende KPI’s zijn: prijs, efficiëntie, kwaliteit, innovatie en service. Deze punten worden ook wel KSF (Kritische Succes factoren) genoemd. KPI's worden op drie niveaus gedefinieerd. Op het topniveau (missie/visie) volstaan drie tot vijf KPI's om te bepalen of een organisatie op koers ligt. Op lagere niveaus worden KPI's doorgaans samengesteld uit een set onderliggende prestatie indicatoren. Visie/missie (topniveau) In de visie en missie wordt het bestaansrecht van een organisatie vastgesteld. Strategische doelstellingen (middenniveau) Waar moet de focus van de organisatie liggen om zijn visie succesvol na te streven. De interne en externe omstandigheden waarbinnen een organisatie moet werken spelen hierbij een rol. Doelstellingen (laagniveau) Strategische doelstellingen zijn van een te hoog niveau om werkbaar te kunnen zijn voor organisaties. Daarom moeten deze worden opgesplitst naar concrete en specifieke doelen. Deze worden omgezet naar tactische plannen, met realistische planningen, verantwoordelijken en budgetten. Toepassing Door de reorganisatie die RDC achter de rug heeft, is overlapping ontstaan tussen de afdelingen. Deze overlapping veroorzaakt verwarring en ruis binnen RDC. Door het opstellen van KPI’s per afdeling worden zowel de scheidingsvlakken van verantwoordelijkheden als de targets in kaart gebracht. Zowel de KPI doelen als de realisatie ervan moeten altijd voor alle medewerkers te raadplegen zijn. Een goed voorbeeld is de KPI’s van KCC (zie bijlage XII KPI KCC). In de KPI die maandelijks door KCC wordt opgesteld is te zien: Wat de maximale wachttijd in de betreffende maand is; Wat de gemiddelde wachttijd is; Wat de gemiddelde behandeltijd van de e-mails zijn; Wat het zelfoplossende vermogen van KCC is; Hoeveel procent van de calls in Topdesk wordt geregisterd; Hoeveel procent van de tweede lijn calls meteen bij de juiste collega wordt neer gelegd; Hoeveel procent van de antwoorden inhoudelijk correct zijn;


HTS Autotechniek 43

Wat het gemiddelde Klant tevredenheids cijfer is; De verdeling tussen de prioriteiten die aan de tweede lijn calls zijn gegeven. KPI’s moeten het personeel motiveren om de gestelde doelen te halen. KPI’s moeten ook als een tool door het management gebruikt worden om het personeel aan te sturen.

7.6 Wachtwoord beheer Het wachtwoord beheer van RDC is al enige tijd een punt van discussie. Uit de telefonische en verdiepende interviews is gebleken dat het wachtwoord beheer ook bij de softwareleveranciers een punt van irritatie is (zie bijlage VIII Gespreksverslagen verdiepende interviews bezoekverslag Xray). Het grootste punt is het hoge aantal calls dat bij KCC binnenkomt die direct te maken hebben met wachtwoorden die zijn verlopen of zijn gewijzigd. Dit zijn op jaarbasis ongeveer 25.000 calls. Elke call duurt ongeveer twee minuten (call aanmaken, vraag beantwoorden, wachtwoord resetten). Per jaar wordt er dus ruim 833 uur besteed aan het resetten van wachtwoorden. Dit komt overeen met 0,4 FTE (zie voorberekeningen hieronder). 261 x 8 = 2088 uur per jaar 833 / 2088 = 0,3989 ≈ 0,4 FTE op jaarbasis Toelichting: 261= het aantaal werkdagen waarmee afdeling HR rekent (excl. verlof, verzuim en vakantie) wat overeenkomt met 40 uur per week. 8 = aantal werkuren per dag 833 = gemiddelde benodigde tijd voor wachtwoord beheer. De 0,4 FTE die KCC kan besparen, kan worden gebruikt om de overige calls beter te bewaken zodat de terugkoppeltijd korter wordt. Hiermee elimineert RDC een van haar zwaktes. Naast de besparing in de vorm van 0,4 FTE zal de verbetering van het wachtwoord beheer irritatie wegnemen bij de klanten en op deze manier de klanttevredenheid verhogen. Een ander gevolg hiervan is dat RDC beter scoort in de markt en er minder klanten zullen overstappen naar een van de concurrenten.

7.7 Service Level Agreement Een Service Level Agreement (SLA) is een schriftelijke overeenkomst tussen een aanbieder en een afnemer van bepaalde producten en/of diensten. In een SLA staan, naast de beschrijving van de te leveren diensten, ook de rechten en de plichten van zowel de aanbieder als de afnemer ten aanzien van het overeengekomen kwaliteitsniveau (service level) van de te leveren producten. Een SLA kan de status van een contract hebben, maar dat hoeft niet. Met behulp van een SLA wordt bereikt dat bij afnemer en aanbieder eenzelfde verwachting ontstaat over de te leveren producten en diensten. In een SLA staan onder andere de volgende punten beschreven: Beschrijving van de dienst Duur en beëindiging van de overeenkomst Contactpersonen


HTS Autotechniek 44

Responstijd Levertijd Berekening van tarieven en overige kosten Wijze van betaling Wijze waarop dienst wordt gemeten Hoe vaak en naar wie toe wordt gerapporteerd Sancties bij niet nakomen van afspraken Hoe om te gaan met eventuele wijzigingen in de dienst Of en onder welke voorwaarden de SLA is te ontbinden Eventuele bijzonderheden De betekenis voor RDC Een SLA is een handig middel voor RDC om een statement naar de markt te maken en haar personeel te motiveren om prestatiegericht te werken. RDC wordt momenteel nog steeds als een ambtelijk bedrijf gezien (dit is gebleken uit de telefonische en verdiepende interviews) dat weinig luistert naar de markt, in dit geval de softwareleveranciers. RDC zal met een SLA aantonen de samenwerking met softwareleveranciers aan te willen gaan. Door een betere samenwerking zal er meer sturing vanuit de markt zijn. Meer sturing zal lijden tot minder klanten verlies en zelfs tot aantrekken van nieuwe klanten. Een SLA zal naast de positieve impulsen naar de markt ook een positief effect hebben op het personeel van RDC. Om de afspraken die gemaakt zijn na te komen, moet het personeel van RDC actiever en meer klantgericht handelen. Het is voor het management ook gemakkelijker om het personeel aan te sturen. De SLA kan hier als een minimaal te behalen doel beschouwd worden. Het gevaar van een SLA Een SLA kent naast de bovengenoemde voordelen ook nadelen. In een SLA wordt onder andere ook vastgelegd welke sancties er volgen als de afspraken niet worden nageleefd door een van de partijen. De consequenties hebben meestal financiële gevolgen. Hierbij kan gedacht worden aan boetes of het vergoeden van de schade die de softwareleveranciers hebben opgelopen als gevolg van niet nakomen van afspraken. RDC moet hierdoor eerst nagaan of haar organisatie klaar is om een SLA aan te gaan met de softwareleveranciers. Als dat niet het geval is, zal een SLA enkel averechts werken. RDC zou een SLA kunnen opstellen dat zo veel marge heeft dat het onmogelijk overschreden kan worden. Een dergelijk SLA zal niet serieus worden genomen door de softwareleveranciers wat het imago van RDC kan aantasten en is daarom zeker geen optie.


HTS Autotechniek 45

8. Conclusie en aanbevelingen Zoals eerder benoemd is er door de interne reorganisatie van RDC minder aandacht geweest voor de markt. Hierdoor is de relatie tussen RDC en de softwareleveranciers verzwakt. Om deze reden is RDC een project gestart om de afstand met de markt te verkleinen en de relatie met de softwareleveranciers aan te halen. De hoofdvraag die met dit project beantwoord moet worden is: “Welke stappen moet RDC ondernemen om de relatie met de softwareleveranciers te verbeteren?” In het paragraaf 8.1 tot en met paragraaf 8.7 zijn zeven aanbevelingen te vinden die samen de relatie tussen RDC en de softwareleveranciers naar een hoger niveau zullen tillen. In deze paragrafen komt ook de realisatie van de aanbevelingen aan bod. De aanbevelingen zijn opgesteld aan de hand van telefonische- en verdiepende interviews die met softwareleveranciers zijn afgenomen. Aan de hand van deze interviews kan er geconcludeerd worden dat de softwareleveranciers geen positief beeld van RDC hebben, ruim een derde van de geïnterviewde softwareleveranciers beoordeeld RDC met een onvoldoende of slecht. Het beeld dat de softwareleveranciers hebben wordt voornamelijk veroorzaak door de gebrekkige communicatie en de testomgeving. Onder communicatie wordt zowel informatievoorziening als de afhandelen van vragen en klachten door de helpdesk van RDC gezien. Een ander punt dat uit de interviews naar voren kwam was dat de softwareleveranciers tevreden waren over de kwaliteit en het gebruiksgemak van de diensten en producten die RDC levert. Om de gegevens uit de interviews te verwerken is er gebruik gemaakt van een SWOT analyse en een confrontatiematrix, hierin zijn alle sterke en zwakke punten van RDC verwerkt en met elkaar vergeleken. Aan de hand van deze gegevens zijn de aanbevelingen geschreven.

8.1 Aanbeveling contactpunt RDC voor softwareleveranciers Onze aanbeveling aan RDC is om een technisch specialist aan te nemen en deze op KCC verantwoordelijk maken voor het afhandelen van incidenten van softwareleveranciers en deze de verantwoordelijkheid te geven over alle tweede lijn calls. Realisatie Om dit scenario te kunnen realiseren moeten er de volgende stappen worden ondernomen: Vacature technisch specialist KCC invullen Dit kan een geheel nieuwe werknemer zijn of iemand uit de organisatie. Wordt deze vacature intern ingevuld heeft dat als voordeel dat deze al bekend is met de organisatie en de manier van werken van RDC Werkplek inrichten voor technisch specialist Een werkplek zoals deze er al zijn bij KCC. Enig verschil is dat de technisch specialist een direct nummer en een direct e-mail adres heeft voor softwareleveranciers Intern de veranderingen communiceren Iedereen binnen RDC op de hoogte stellen van de nieuwe werknemer en daarbij ook duidelijk zijn taken en verantwoordelijkheden benoemen. Softwareleveranciers op de hoogte brengen van veranderingen Softwareleveranciers laten weten dat er een apart nummer en e-mail adres is voor hun vragen en klachten. Dat deze persoon over technische kennis beschikt en een goede gesprekspartner is.


HTS Autotechniek 46

8.2 Aanbeveling testomgeving Onze aanbeveling aan RDC is om voor de testcyclus het stroomschema dat van paragraaf 7.2 (figuur 9)aan te houden. Hierbij moet er te allen tijde rekening worden gehouden met de wensen van de softwareleveranciers. Communicatie en documentatie spelen hierbij een belangrijke rol. Helaas is onze technische achtergrond op ICT gebied niet toerijkend om een uitspraak te kunnen doen over de wijze van implementatie van de wensen van de softwareleveranciers. Wij adviseren RDC om dit door mensen met voldoenden kennis op ICT gebied verder te laten onderzoeken. Realisatie Voor het opzetten van een dedicated testomgeving moet RDC ruimte op de netwerk reserveren en voor het opzetten en beheren van de applicatie zijn er ICT specialisten noodzakelijk. Voor bepalen van de omvang van werkzaamheden en de benodigde investering is er een verdiepend onderzoek noodzakelijk.

8.3 Aanbeveling documentatie Onze aanbeveling aan RDC is om de PIT gids zo snel mogelijk af te ronden en deze te delen met de softwareleveranciers. Een vereiste is dat de PIT gids te allen tijde up to date is, hier moet een verantwoordelijke voor worden aangewezen. Daarnaast moet de PIT gids een prominente plaats krijgen op de website, binnen drie muisklikken vanaf de homepage van RDC, iedereen moet hem zonder problemen kunnen vinden. Realisatie Eindverantwoordelijke aanwijzen voor PIT gids Iemand binnen de organisatie moet verantwoordelijk zijn voor de PIT gids. Om deze up to date te houden en veranderingen omtrent de gids te communiceren, zowel intern als extern Up to date houden van document Indien er updates zijn deze direct verwerken en communiceren met softwareleveranciers. Omdat het up to date houden van de gids afhankelijk is van de ontwikkeling van de producten en diensten van RDC is het lastig om hier een concrete tijdsbesteding voor te bepalen. Rekening houdend met het aantal updates en releases van RDC is de verwachting dat er per maand een halve dag gebruikt moet worden om updates in de gids te verwerken. Dit komt neer op 0,02 FTE op jaarbasis. Ruimte reserveren op de website voor PIT gids Zorg ervoor dat de PIT gids maximaal drie muisklikken van de homepage is verwijderd.

8.4 Aanbeveling het borgen van kennis Onze aanbeveling aan RDC is om het borgen van kennis te integreren in de dagelijkse werkzaamheden. Hierbij moet RDC het personeel de gelegenheid geven om hun kennis te borgen. Borgen van kennis vergt tijd. Het moet gezien worden als een investering in efficiëntie. Borging van kennis kan gestimuleerd worden door vaststellen van beoordelingscriteria en belonen van correct vastleggen van informatie. Realisatie Voor de borging van de kennis moet allereerst geïnvesteerd worden in het aanpassen en verbeteren van borging instrumenten zoals Topdesk en RDC-wiki. Daarnaast is er ook een constante investering nodig, na ieder project moet er documentatie over het product worden vastgelegd. Hierin moet staan wat de functionaliteiten zijn, hoe het eruit ziet (functioneel en technisch), hoe het werkt en welke fouten er


HTS Autotechniek 47

kunnen voorkomen. Ook moet het personeel op de hoogte zijn van nieuwe producten. Dit kan door middel van het geven van presentaties. De investering hiervoor is uitgedrukt in de tijd die werknemers nodig hebben om hun kennis te borgen. Borging van kennis zal RDC gemiddeld zeven FTE op jaarbasis kosten. Hierbij is er uitgegaan dat RDC 117 werknemers in dienst heeft die samen goed zijn voor 112 FTE (bron: Sander Heuvelman afdeling HRM) en dat er per FTE een half uur per dag nodig is om de kennis te borgen 1 FTE op jaar basis = 261 werkdagen * 8 uur per werkdag = 2088 uur per jaar 112 FTE * 0,5 uur per werkdag is = 56 uur per dag 56 * 261 = 14616 uur per jaar 14616 / 2088 = 7 FTE op jaar basis In de bovenstaande berekening is er vanuit gegaan een situatie waarbij er van nul uur tijdsbesteding naar een half uur per dag tijdsbesteding gaat. In de realiteit besteden de werknemers van RDC hier nu ook al tijd aan dus er zal naar verwachting minder dan zeven FTE nodig zijn.

8.5 Aanbeveling KPI Onze aanbeveling aan RDC is om per afdeling KPI’s op te stellen. De KPI’s moeten samen het realiseren van de missie mogelijk maken. De KPI’s moeten voor iedereen binnen RDC te raadplegen zijn. Zodat het management en de medewerkers elkaar kunnen aanspreken. De KPI’s moeten maandelijks worden gerapporteerd zodat er sturing ontstaat vanuit deze rapportages. Ieder half jaar moet er worden gekeken of de KPI’s worden gehaald en waar deze scherper gesteld kunnen worden. Realisatie Voordat KPI’s ingevoerd kunnen worden moeten de volgende acties worden genomen: Per afdeling onderzoeken wat de hoofdtaken zijn; Per hoofdtaak uitzoeken welke KSF hieraan verbonden zijn; Wat de huidige prestaties zijn; Wat reële maar toch uitdagende doelen kunnen zijn. Voor het opstellen van KPI’s zal in de opstartfase geïnvesteerd moeten worden. De benodigde tijd voor het onderzoeken en documenteren van de bovenstaande vragen zal maximaal een halve dag in beslag nemen. Verder zal het management continu het niveau van de doelen moeten bepalen en zo nodig aanpassen. Hiervoor is er 0.006 FTE nodig per afdeling per jaar. Hierbij is er vanuit gegaan dat er per afdeling een uur per maand nodig is om de relevantie van de KPI’s te bepalen. 1 FTE op jaar basis = 261 werkdagen * 8 uur per werkdag = 2088 uur per jaar 1 uur per maand * 12 maanden = 12 uur per jaar 12 / 2088 = 0.0057471 ≈ 0.006 FTE per afdeling per jaar.

8.6 Aanbeveling wachtwoord beheer Onze aanbevelingen aan RDC is om te investeren in innovatie met betrekking tot het wachtwoord beheer. Het moet voor de gebruiker mogelijk zijn om op gebruikersniveau in te loggen voor de diensten van RDC in plaats van inloggen op klantniveau. Hierdoor kan RDC de samenwerking met de softwareleveranciers verbeteren.


HTS Autotechniek 48

Realisatie Momenteel loopt er een aanvraag om het wachtwoordbeheer te verbeteren. Deze aanvraag is gedeeltelijk in bijlage XI “Business case wachtwoord vergeten” te zien. Hierin wordt er dieper ingegaan op de voor- en nadelen van het wijzigen van het wachtwoordbeheer. De nadelen zijn voornamelijk van financiële aard. Er moet namelijk een aanzienlijk bedrag geïnvesteerd worden in het verbeteren van het wachtwoordbeheer terwijl hier niet direct meer omzet mee wordt gegenereerd.

8.7 Aanbeveling Service Level Agreement Onze aanbeveling aan RDC is om niet in de huidige situatie een SLA met de softwareleveranciers af te sluiten. RDC is er als organisatie nog niet klaar voor om SLA’s af te sluiten. RDC moet eerst haar service level verhogen en constant krijgen. SLA’s met de softwareleveranciers moet een doel voor RDC zijn om naar toe te werken. Realisatie Voor SLA’s is er net als bij de KPI’s een investering in de opstartfase nodig. RDC moet per softwareleverancier een SLA opstellen die voor beide partijen interessant is. En SLA heeft ook constante investering in de vorm van tijd nodig. Zo moet er per tijdsinterval gekeken worden of de SLA’s bijgesteld moeten worden. Dit zou een keer per jaar moeten gebeuren. De benodigde tijd zal per jaar variëren afhankelijk van het aantal veranderingen die nodig zijn. Het is bij de realisatie belangrijk om te bepalen wat het juiste moment is om met SLA’s te gaan werken.

8.8 Actieplan Om de aanbevelingen te ondersteunen is er een actieplan opgesteld, deze is te vinden in bijlage XII Actieplan. Voor iedere aanbeveling zijn enkele actiepunten beschreven. Per aanbeveling is duidelijk beschreven wat het knelpunt is en welke actie ondernomen moet worden om het knelpunt te elimineren. Daarnaast is bepaald wie er verantwoordelijk is voor het invoeren en bewaken van de actie. Voor ieder actiepunt is geprobeerd om een begin- en een einddatum te bepalen, dit is gedaan om iedere actie een duidelijke deadline te geven. Tot slot kan er een kleur worden gegeven aan de invoering van de actie, dit correspondeert met de status van de verbetering. Het doel is om ieder actiepunt de groene status(nieuwe werkwijze routine) te kunnen geven.

Bronvermelding RDW, Wat doen we? Kerntaken van de RDW. Geraadpleegd op 21 september 2009 http://www.rdw.nl/nl/overrdw/wat_doen_we/kerntaken_van_de_rdw/

Wol, de D (8 oktober 2009). Klant. Geraadpleegd op 26 oktober 2009, http://nl.wikipedia.org/wiki/Klant Santen, van H (2 juli 2007). Noodvoorziening afmelden APK. Geraadpleegd op 27 oktober 2009, http://www.rdw.nl/NR/rdonlyres/0EBCDAF1-48C9-4569-9607CE0D5593BF45/0/20070628BriefAPKWebdirect_DEF_methandtekening.pdf MKB Servicedesk (11 juni 2009). Wat is een Service Level Agreement? En hoe stel ik er een op? Geraadpleegd op 06 november 2009, http://www.mkbservicedesk.nl/995/wat-service-level-agreement.htm Waterbley, A (2006). Succesvolle bedrijfsfinanciering en investeringsbeleid. Apeldoorn. Maluk.

SCFB (2008). Visie op kennisborging. Geraadpleegd op 10 november 2009, http://www.scfb.nl/artikel/99.htm Brink, van den Dr. P(25 augustus 2009). Kennisbehoud bij vertrek van oudere medewerkers. Geraadpleegd op 10 november 2009, http://www.ministerievankennis.nl/kennismanagementscan/docs/kennis_vertrekkende_medew erkers_vasthouden.pdf De Lugt, Y. en Van der Weele, D. (2008). Kennis Management Kookboek. Rotterdam. Essentials.

Intern gesproken met: Vitor Alves Da Silva Rob Blanker Werner Boldewijn Dio van Gils Jaap Heeringa Sander Heuvelman Danny Kruitbosch Jaap Noordsij Daan Ohlenbusch Petra van Schooten Jorgen Waitz Hugo Weijers

Functioneel Beheer Klanten Contact Centrum Business Service Management Klanten Contact Centrum Architecten HRM Architecten Functioneel Beheer Projectbureau Functioneel Beheer Functioneel Beheer Business Service Management


HTS Autotechniek 50

Verklarende woordenlijst en afkortingen A2SP AB APK BPM BSM CRM DMS DVS FB FO FTE FTP GPS ICT INDI KCC KPI KSF KTO NAP NAW ORB PIT RDW ROB SAAS SMART SOA SLA SWL TVI VER VDC VWE KCC

Automotive Application Services Provider (RDW communicatie- en informatieprovider) Applicatie Beheer Algemene Periodieke Keuring Belasting voor Personenauto’s en Motorrijwielen Business Service Management Customer Relationship Management Dealer Management Systeem Document Verificatie Systeem Functioneel Beheer Functioneel Ontwerp Fulltime equivalent File Transfer Protocol, een protocol dat uitwisseling van bestanden tussen computers vergemakkelijkt Garage Polis Systeem Informatie- en Communicatie Technologie Interface NAW Dealer Importeur Klant Contact Center Key Performance Indicator of Kritische Prestatie Indicator Kritische Succes factoren Klant Tevredenheids Onderzoek Nationale Auto Pas Naam Adres Woonplaats Online Registratie Bedrijfsvoorraad Proces Integratie Technologie Rijksdienst voor het Wegverkeer Reparatie Onderhoud en Banden Software As A Service Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden Service Oriented Architecture Service Level Agreement Softwareleverancier Technische Voertuig Informatie Voertuig en Eigenaren Register Voertuig Documentatie Centrum (RDW communicatie- en informatieprovider) Klanten Contact Centrum

RAPPORT AFSTUDEEROPDRACHT 2009

Recommend Documents