BIJLAGEN AFSTUDEEROPDRACHT 2009

Autotechniek

BIJLAGEN 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

Inhoudsopgave Inleiding Bijlage I Bijlage II Bijlage III Bijlage IV Bijlage V Bijlage VI Bijlage VII Bijlage VIII Bijlage IX Bijlage X Bijlage XI Bijlage XII Bijlage XIII

.................................................................................................................................................. 3 Organigram RDC........................................................................................................................ 4 Brainstorm telefonische interviews .......................................................................................... 5 Belscript telefonische interviews .............................................................................................. 6 Resultaten telefonische interviews .......................................................................................... 8 Analyse telefonische interviews ............................................................................................. 18 Brainstorm verdiepende interviews ....................................................................................... 22 Script verdiepende interviews ................................................................................................ 23 Gespreksverslagen verdiepende interviews ........................................................................... 24 Marktaandeel per dienst ........................................................................................................ 33 Prijsinformatie RDC tov concurrentie ..................................................................................... 34 Business case wachtwoord vergeten ...................................................................................... 36 KPI KCC .................................................................................................................................... 39 Actieplan ................................................................................................................................. 42


HTS Autotechniek 3

Inleiding In dit verslag zijn de bijlagen gebundeld die horen bij het rapport De relatie tussen RDC en softwareleveranciers tegen het licht gehouden. Doel van dit verslag is om op enkele punten meer informatie te geven over de behandelde onderwerpen in het hoofdverslag. In de tekst van het hoofdverslag wordt duidelijk verwezen naar de bijlagen als over een onderwerp meer informatie te vinden is dan er in de tekst is weergegeven. Er is gekozen voor een apart verslag om het raadplegen van de bijlagen te vergemakkelijken.


HTS Autotechniek 4

Bijlage I

Organigram RDC

De organisatiestructuur van RDC is procesgericht, dit heeft geleid tot een verdeling in drie segmenten: Klanten, Producten en Techniek. Hieronder is het organigram van RDC te zien.

Figuur 1: Organigram RDC


HTS Autotechniek 5

Bijlage II

Brainstorm telefonische interviews

Voordat er is begonnen aan de telefonische interviews met de softwareleveranciers is er bepaald wat het doel van dit interview is en welke onderwerpen aan bod moesten komen om dit doel te bereiken. Hiervoor is er een brainstormsessie geweest, hieronder zijn de resultaten van deze sessie te zien: Releases (van SWL en van RDC)

Prijs/kwaliteit verhouding

Informatievoorziening (RDC- SWL)

Frequentie

(kwartaal)meetings

Moment

Vast contactpersoon

Wensen en behoeften softwareleveranciers

(Technische) positie RDC tov concurrentie

Kwaliteit

Gebruiksgemak/ integreerbaarheid

Communicatie (RDC- SWL)

Interview software-leveranciers

Imago/relatie

Testomgeving Communicatie (RDC-SWL)

(Nieuwe) producten die gaan komen Nieuwe releases

Behoefte, vraag? Testomgeving

Updates

(extra) diensten onderbrengen

Figuur 2: Brainstorm telefonische interviews

Bekend met alle diensten RDC

Waarom wel/niet?


HTS Autotechniek 6

Bijlage III Belscript telefonische interviews Om ervoor te zorgen dat alle informatie die nodig is voor het onderzoek wordt verkregen en om structuur aan te brengen in het interview is er een belscript opgesteld. Deze is aan de hand van de brainstorm die op de vorige pagina is te zien opgesteld. Na een aantal gesprekken is deze op een aantal punten aangepast omdat enkele vragen niet relevant waren en al met andere vragen werden gedekt. In deze bijlage staat de uiteindelijke versie van het belscript zoals deze is gebruikt bij de telefonische interviews. Voorbereiding: Voor ieder gesprek de website van de softwareleverancier bekijken en een beeld schetsen van het bedrijf. In Excel bestand bekijken welke services SWL afneemt bij RDC 1. Goedemorgen/middag meneer/mevrouw ……. Ik ben …… van HTS Autotechniek in Arnhem en bel u namens RDC. 2. Wij zijn momenteel bezig met een onderzoek naar de relatie tussen de softwareleveranciers en RDC en kijken daarbij naar de wensen en behoeften van softwareleveranciers. 3. Bent u hiervoor het juiste aanspreekpunt en komt het u gelegen uit als ik u hierover wat vragen stel. Zo niet, wie is binnen uw organisatie het juiste aanspreekpunt (nummer van juiste persoon vragen, aanpassen in bestand en terugbellen) Zo niet, wanneer schikt het u 4. a. Klopt het dat u gebruikt maakt van de volgende services van RDC in uw softwarepakketten (uit Excel bestand) i. Zo niet, van welke diensten van RDC maakt u wel gebruik (aanpassen in Excel bestand) b. Van welke diensten van RDC maakt u gebruik. (als Excel bestand niet is ingevuld) 5. Wat is uw beeld van RDC als onderneming Op basis van welke ervaringen met RDC is uw beeld gevormd Op basis van welke criteria heeft u voor RDC gekozen als informatieprovider Maakt u ook gebruik van andere leveranciers voor de informatie (VWE, A2SP) Wat zijn hiervan de positieve punten ten opzichte van RDC 6. Hoe ervaart u de wijze van communicatie tussen RDC en uw bedrijf Hebt u een vast contactpersoon bij RDC Zo ja, wie Zo nee, hoe benadert u RDC als u vragen en/of opmerkingen hebt.


HTS Autotechniek 7

Op welke wijze brengt RDC u op de hoogte als er updates, nieuwe releases of nieuwe producten zijn. (tel, mail, post, fax) 7. Ervaart u deze manier van benadering als prettig, zo nee hoe zou u dit liever zien 8. Hoe ervaart u het gebruiksgemak van de producten die RDC levert Negatief: waarom? Positief: waarom? Hoe zou RDC dat kunnen verbeteren volgens u Indien ook andere leveranciers (Zie vraag 6): hoe is dit gebruiksgemak in vergelijking met de andere leveranciers die u gebruikt? 9. Hoe ervaart u de kwaliteit van de producten / diensten die RDC levert (storing gevoelig en data compleet) Als negatief, hoe zou RDC de kwaliteit en de kwaliteitsbeleving van haar producten kunnen verbeteren Als positief, wat zijn de sterke punten 10. Zijn er producten / diensten die RDC momenteel niet aanbiedt, maar waar u wel belangstelling in zou hebben (wensen) Dedicated testomgeving? Frequentie releases? Aantal releases per jaar en moment? Meeting, informatie dag, discussie? 11. Al mijn vragen zijn beantwoord, hebt u nog vragen waar ik u mee kan helpen Zo ja, de vraag op schrijven en intern de vraag neerleggen bij de juiste persoon. De softwareleverancier laten terugbellen. Zo nee, ik zal u een samenvatting opsturen van dit gespreek met de vergelijking van uw antwoorden teenopzicht van andere softwareleveranciers. 12. Afspraken die gemaakt zijn bevestigen Informatie sturen Terug laten bellen Samenvatting interview sturen 13. Meneer/mevrouw….. Ik wil u bedanken voor uw tijd. Gesprek afsluiten


HTS Autotechniek 8

Bijlage IV

Resultaten telefonische interviews

De resultaten van de telefonische interviews zijn verwerkt in een Excel bestand. Hierin zijn alle antwoorden van de softwareleveranciers die mee hebben gedaan aan de telefonische interviews gezet. Wat is uw beeld van RDC als onderneming (goed, voldoende, onvoldoende of slecht)

ADP ANVA BV Autoflex Auto-interactive Autonet B.V. Autotaal Automatisering B.V. Car Systems Heerlen Computer Service Wieberdink Mivar Group OEC Oribi Promasy Prosaldo Software B.V. Reynolds & Reynolds Riset automatisering Sogeti Nederland B.V. Trip6 Holding B.V. /Vroemm Xray

Voldoende, al is het wel onderbemand Voldoende, sommige punten komen zeker voor verbetering in aanmerking Onvoldoende, laatste tijd wel beter Slecht, een logge en stugge organisatie die nog steeds (mis)bruik maakt van de monopoliepositie Voldoende, laatste tijd wel beter Voldoende, communicatie moet beter, bijvoorbeeld het aangeven van storingen bij RDC Slecht Onvoldoende, is al beter maar kan nog veel beter Onvoldoende, heeft niet het gevoel dat iedereen bij RDC beseft dat het een commerciële instelling is Voldoende, wel erg formeel en ambtelijk Oribi maakt nog geen gebruik van RDC diensten Onvoldoende Goed, nooit grote problemen gehad Voldoende Goed, maken nog geen gebruik van diensten RDC, vanaf januari wel Goed, stabiele infoverstrekker in automotive markt Voldoende, hij vindt het een ambtelijk bedrijf dat een efficiëntieslag kan maken Voldoende, het gaat een stuk beter dan in het verleden maar kan nog beter


HTS Autotechniek 9

Op basis van welke ervaringen met RDC is uw beeld gevormd


Ontwikkeling van software duurt erg lang -geen antwoordBezoek van iemand van RDC RDC komt afspraken niet na, e-mails worden niet beantwoord en brieven zijn onder de maat Communicatie is een stuk beter geworden RDC is lastig te bereiken voor technische vragen Communicatie ronduit slecht, informatie niet altijd te vertrouwen en de testomgeving is totaal anders dan de release. Communicatie met RDC Lang wachten op simpele antwoorden, 12 dagen noemt hij snel, antwoorden niet altijd betrouwbaar De helpdesk die hij waardeloos vindt, lang wachten op antwoord, gebrek aan kennis. -geen antwoordVragen komen niet door, al heel lang een probleem met ORB, wordt niet opgelost Terugkoppeling bij vragen en/of problemen is goed en vaak snel 10 jaar ervaring -geen antwoordGoed contact met medewerkers Slecht reageren op vragen uit de markt RDC biedt weinig support aan bij problemen


HTS Autotechniek 10

Op basis van welke criteria heeft u voor RDC gekozen als informatieprovider


RDC was destijds de enige De enige die TVI levert De twee grootste gekozen (RDC en VWE) RDC is de grootste en klanten kiezen Klanten maken deze keuze RDC is de grootste, wel steeds meer vraag naar VWE vanuit klantenkring 80% van de klanten van Car Systems Heerlen werken met RDC, vandaar Doen de klanten Mivar kiest niet, dit doen de klanten Doen de klanten -geen antwoord-geen antwoordRDC was destijds de enige RDC was destijds de enige RDC is de enige met kentekenregistratie -geen antwoordZe maken geen gebruik van diensten van RDC RDC is de enige NAP leverancier


HTS Autotechniek 11

Maakt u ook gebruik van Wat is het voordeel van VWE/A2SP ten opzichte van RDC andere leveranciers voor de informatie (VWE, A2SP) zo ja, welke


VWE -geen antwoordVWE VWE VWE VWE VWE en A2SP (weinig) VWE en A2SP VWE en ook A2SP VWE en ook A2SP -geen antwoordVWE Ja, VWE VWE Nee Nee geen andere leveranciers A2SP

VWE is een stuk flexibeler en beter bereikbaar -geen antwoordVWE veel kortere lijnen, snellere reactie bij vragen en problemen VWE is goedkoper Communicatie bij VWE is veel beter Documentatie VWE is beter VWE is sneller met antwoorden en heeft betere documentatie Geen groot verschil, maar VWE werkt net iets lekkerder VWE heeft alles heel goed geregeld, binnen een dag antwoord, goede documentatie Leveren net wat andere producten en zijn goedkoper -geen antwoordVWE minder storingsgevoelig Weinig, zeker nu RDC ook met XML-berichten werkt VWE een stuk slagvaardiger -geen antwoord-geen antwoordZe zijn goedkoper -geen antwoord-


HTS Autotechniek 12

Hoe ervaart u de wijze van communicatie tussen RDC en uw bedrijf


Lastig, niet optimaal Goed Langzaam, duurt vaak een week voordat er een oplossing is. Alles ligt dan een week stil. Slecht, geen voorstander van KCC Voldoende Gebrekkige communicatie, communicatie binnen RDC niet goed waardoor informatie niet goed gedeeld wordt. Slecht en langzaam Goed Slecht, calls duren veel te lang! Kan status van calls ook niet bijhouden, zou gemakkelijk zijn online Bij problemen en vragen zijn de medewerkers wel erg behulpzaam, maar de kennis is vaak niet toerijkend -geen antwoordOver het algemeen goed Prima Goed Positief Goed, vaak contact met een van directeuren -geen antwoordNiet ideaal


HTS Autotechniek 13

Op welke wijze brengt RDC u op de Ervaart u deze manier van benadering als prettig, hoogte als er updates, nieuwe zo nee hoe zou u dat liever zien releases en nieuwe producten zijn. (tel, mail, post, fax)


Mail Niet Mail Mail Mail, en dat is goed Mail, dat is goed Niet Mail Mail, dat is goed Mail, maar die komen vaak niet aan -geen antwoordMail Mail, en dat is goed Mail Mail -geen antwoordMail Mail

Goed Graag per email Ja, prima, goede informatie Nee, komt vaak bij verkeerde persoon terecht Goed prima -geen antwoordDat is goed Ja, is goed Goed, als ze aankomen -geen antwoordGoed Het is goed zoals het is Goed Ja -geen antwoordJa Ja


HTS Autotechniek 14

Hoe ervaart u het gebruiksgemak van de diensten die RDC levert (Positief/Negatief)


Positief Werkt er niet direct mee dus kan er niets over zeggen Weinig over zeggen, alleen ROB is nu operationeel Geen uitspraak, werkt er niet direct mee Positief, XML, werkt lekker Positief Negatief Niets op aan te merken -geen antwoordSlecht, applicaties die niet of slecht functioneren. -geen antwoordIn het begin met XML wel even lastig maar nu loopt alles op rolletjes Niets op aan te merken Goed Positief -geen antwoordHij wil graag meer commerciële informatie ontvangen Het gebruiksgemak is goed. Problemen lastig op te lossen (lastig om de juiste persoon aan de lijn te krijgen).


HTS Autotechniek 15

Hoe zou RDC dat kunnen verbeteren volgens u


-geen antwoord-geen antwoord-geen antwoord-geen antwoordAf en toe nog kleine storingen -geen antwoordDocumentatie duidelijk en compleet aanleveren LPG en Tacho ook transactioneel beschikbaar maken -geen antwoord-geen antwoord-geen antwoord-geen antwoord-geen antwoord-geen antwoord-geen antwoord-geen antwoord-geen antwoord-geen antwoord-


HTS Autotechniek 16

Hoe ervaart u de kwaliteit van de producten / diensten die RDC levert (voldoende / onvoldoende)


Goed Kwaliteit kan beter, af en toe storingen Voldoende Zijn wel goed maar niet vlekkeloos, zou wel moeten omdat RDC marktleider is Voldoende Wel goed. De testomgeving kan beter. Onder de maat en incompleet Voldoende Is op zich goed Slecht, vooral testomgeving. Die is vaak anders dan de daadwerkelijke release. -geen antwoordORB is storingsgevoelig Prima Voldoende nvt, gebruiken ze nog niet Goed -geen antwoordStoringsgevoelig, WW beheer niet handig. Iedereen kan het wijzigen, als dat gebeurt, kan niemand meer inloggen


HTS Autotechniek 17

Op welke manier zou u geïnformeerd willen Testomgeving worden over de producten van RDC


Geen informatie nodig Geen informatie nodig Mail Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig Geen informatie nodig

Nee Ja Ja, moet beter! Ja, als het niets kost Is goed zoals die is Ja! Zeker behoefte aan een betere en stabielere testomgeving Huidige omgeving werkt goed Ja, erg veel belangstelling Ja, moet beter! -geen antwoordNee, weinig tests nodig Betere testomgeving met een betere toegang, die niet verloopt Kan beter Geen behoefte aan Goed -geen antwoordNee


HTS Autotechniek 18

Bijlage V Analyse telefonische interviews Het eerste contact met de softwareleveranciers is door middel van een telefonisch interview gedaan. Aan de hand van een belscript zijn er een aantal vragen gesteld. Na een aantal interviews is het belscript iets aangepast omdat sommige vragen overbodig bleken te zijn. Het belscript is te vinden in bijlage III Belscript telefonische interviews. Het doel van het dit interview is om een beeld te krijgen van de markt en te onderzoeken waar de verbeterpunten liggen met betrekking tot de relatie RDC en de softwareleveranciers. De resultaten van het telefonische interview zullen de basis vormen voor het tweede gesprek met een aantal softwareleveranciers. In totaal is er met 26 softwareleveranciers contact opgenomen, waarvan er 8 om verschillende redenen niet mee wilden werken aan het onderzoek. De gegevens zijn dus gebaseerd op de antwoorden van 18 softwareleveranciers. Een van de eerste vragen uit het onderzoek was; wat is uw beeld over RDC als onderneming?

Grafiek 1: Het beeld van RDC als onderneming

In grafiek 1 zijn hiervan de resultaten te zien. Een derde (35%) van de 18 ondervraagden geeft RDC een negatieve beoordeling. Hiervoor zijn verschillende oorzaken: veel van de softwareleveranciers gaven aan dat ze RDC zien als een logge en ambtelijke onderneming dat niet echt marktgericht opereert. Dit beeld wordt vooral gevormd door het contact dat de softwareleveranciers hebben met RDC, bij problemen en vragen duurt het in de ogen van de softwareleveranciers erg lang voordat er een antwoord is en een enkele keer wordt het probleem helemaal niet opgelost. Dit is storend voor hun interne proces, omdat deze stil ligt zolang het probleem niet is opgelost. De softwareleveranciers geven aan dat het afhandelen van problemen/klachten al een stuk beter is dan voorheen, maar hier zijn zeker nog stappen te maken. Een ander punt dat veel naar voren kwam is dat de testomgeving nog wel eens voor problemen zorgt, dit wordt later in dit hoofdstuk beschreven. Omdat vanaf het begin al duidelijk was dat de communicatie een grote rol speelt in de relatie met de softwareleveranciers, is hier ook aandacht aan besteed. Een van de vragen uit het interview was dan ook: hoe ervaart u de manier van communicatie tussen uw bedrijf en RDC. Hierbij werd vooral gevraagd naar de afhandeling van vragen/problemen door het Klant Contact Center (KCC) van RDC en de manier


HTS Autotechniek 19

waarop RDC de softwareleveranciers op de hoogte brengt als er updates of nieuwe releases worden uitgebracht.

grafiek 2: Communicatie softwareleveranciers en RDC

In grafiek 2 is te zien hoe de softwareleveranciers de manier van communiceren met RDC ervaren. De helft (50%) is hier ontevreden over. Dit heeft grotendeels te maken met het de manier waarop problemen en vragen worden afgehandeld. Het afhandelen van problemen en vragen gaat als volgt: indien een softwareleverancier een probleem of een vraag heeft neemt hij contact op met het KCC, in dit callcenter wordt geprobeerd om vragen zo goed en zo snel mogelijk op te lossen. Maar omdat in het KCC niet altijd de specifieke en technische kennis aanwezig is worden sommige van deze vragen naar de tweede lijn (met de tweede lijn wordt een afdeling of persoon bedoeld die wel alle technische kennis heeft om met een oplossing te komen) doorgestuurd, dit gaat met behulp van een applicatie (TopDesk) waarin de vraag (call) wordt omschreven met daarbij alle gegevens van de softwareleverancier die de vraag heeft gesteld. Als er een oplossing is voor de vraag wordt gevonden, wordt de call teruggestuurd naar het KCC en die bellen op hun beurt de softwareleverancier op met het antwoord. Dit proces neemt soms erg veel tijd in beslag waardoor de softwareleveranciers blijven zitten met hun vragen of problemen. Tot er een oplossing is ligt het proces bij de softwareleveranciers stil en dat wekt veel irritatie op. De communicatie met betrekking tot het aankondigen van updates en nieuwe releases wordt door bijna alle softwareleveranciers als positief beoordeeld. Dit gaat via e-mails en hier is bijna iedereen over te spreken. Bij een enkeling komen de e-mails niet aan of worden ze naar de verkeerde gestuurd waardoor ze met vertraging of helemaal niet bij de juiste persoon aankomen.


HTS Autotechniek 20

Grafiek 3: Kwaliteit van de producten en diensten RDC

Een ander belangrijk punt uit de telefonische enquête is de kwaliteit en het gebruiksgemak van de producten en diensten die RDC aan de softwareleveranciers levert. Grafiek 3 laat zien dat de kwaliteit van de producten nog te wensen overlaat. De 40% die de kwaliteit als negatief beoordeelde gaven als argument dat er regelmatig storingen zijn en er nergens wordt gemeld dat er storingen zijn.

Grafiek 4: Gebruiksgemak producten en diensten RDC

Het gebruiksgemak van de diensten en producten van RDC (grafiek 4) wordt zeer positief beoordeeld. Ruim 80% kan de verschillende applicaties zonder problemen in zijn softwarepaketten integreren. Slechts een klein gedeelte beoordeeld dit als negatief en dat is vooral te wijten aan de documentatie die volgens sommige softwareleveranciers niet compleet of onjuist is. Tijdens de tweede interviews, die onder enkele softwareleveranciers worden afgenomen, wordt er dieper ingegaan op de documentatie.


HTS Autotechniek 21

Grafiek 5: Concurrentie RDC

Naast RDC zijn er nog twee bedrijven die RDW communicatie- en informatieprovider zijn: VWE en A2SP. Uit de externe analyse bleek al dat VWE de grootste concurrent is van RDC en dat A2SP een kleine speler op de markt is. Zoals grafiek 5 laat zien komt dit overeen met de resultaten uit de telefonische interviews. De reden dat voor VWE wordt gekozen is dat VWE een betrouwbare leverancier is met een hele goede helpdesk. Ook het prijsniveau van VWE ligt lager dan RDC. A2SP biedt minder diensten aan dan RDC en VWE en is daarom een stuk kleiner, voordeel van A2SP is wel dat ze erg goedkoop zijn, het is een prijsvechter en probeert op die manier marktaandeel te verkrijgen.

Grafiek 6: Vraag naar verbeterde testomgeving

Grafiek 6 laat zien dat er dringend behoefte is aan een verbeterde testomgeving, ruim tweederde van de softwareleveranciers (69%) is niet tevreden met de testomgeving zoals die er nu is. Er zijn te vaak storingen en de testapplicaties verschillen vaak erg veel van de werkelijke release, waardoor het testen dus eigenlijk niet zo zinvol is geweest. Tijdens de tweede interviews worden de wensen en behoeften met betrekking tot een verbeterde testomgeving verder onderzocht zodat er een voorstel tot verbetering gedaan kan worden.


HTS Autotechniek 22

Bijlage VI

Brainstorm verdiepende interviews

Na de telefonische interviews zijn er een aantal punten naar voren gekomen waar dieper op in is gegaan tijdens de verdiepende interviews. Aan de hand van een brainstorm zijn de onderwerpen verdiept met deelvragen die beantwoord moesten worden. Hieronder is het resultaat van de brainstorm te zien: Hoe ziet de testcyclus eruit

Kwaliteit van de oplossingen

Kennis op KCC

Ideale testomgeving volgens SWL

Verschil met liveversie

Afhandeling vragen/problemen

Testomgeving

Afhandelingsduur

Tweede interview SWL

Geen communicatie over storingen

Klanten te snel doorverwijzen naar SWL

Hoelang Wat is nodig om aan de slag te gaan

Onderwerpen Welke onderwerpen moeten er in staan

Informatiedag Documentatie Wie zou u willen spreken (functie) Wat is voor u belangrijk

Figuur 3: Brainstorm verdiepende interviews

Tips/voorbeelden


HTS Autotechniek 23

Bijlage VII Script verdiepende interviews Om structuur aan de verdiepende interviews te geven en om er voor te zorgen dat alle vragen aan bod komen tijdens de verdiepende interviews is er een vragenlijst opgesteld. In deze bijlage is per onderwerp te zien welke vragen er zijn gesteld. Testomgeving Hoe ziet uw testcyclus er uit? Uit de telefonische interviews is gebleken dat de huidige testomgeving beter kan, wat is uw ervaring met de testomgeving? Het verschil tussen de test versie en live versie, voorbeelden? Hoe zou de ideale testomgeving eruitzien volgens u? Communicatie met betrekking tot storingen (niet alleen testomgeving maar ook algemeen in applicaties), hoe zou u op de hoogte gebracht willen worden, bijvoorbeeld met een sms, e-mail, op de site van RDC? Afhandeling vragen/problemen Wat is uw ervaring met betrekking tot de afhandeling van vragen/klachten (procedure) Wat vind u van de kwaliteit van de antwoorden, zijn deze goed zodat u verder kan? (inhoudelijk) Documentatie Het huidige document is verouderd en er wordt hard gewerkt aan een nieuw document dat zal worden aangeleverd aan de SWL om mee aan de slag te gaan, deze wordt dit jaar nog gepubliceerd. Welke informatie hebt u nodig om aan de slag te kunnen, welke onderwerpen moeten er in staan Hebt u tips en/of voorbeelden gedocumenteerd, zou u deze kunnen opsturen? Informatiedag Om de informatiedag zo nuttig mogelijk in te vullen willen we hierover graag wat respons over hebben uit de markt. Welke onderwerpen zou u graag willen bespreken Welke mensen (functie) zou u graag willen spreken Hoelang mag het duren Welke frequentie zou dit moeten plaatsvinden


HTS Autotechniek 24

Bijlage VIII Gespreksverslagen verdiepende interviews In totaal zijn er vier verdiepende interviews afgenomen, in deze bijlage zijn alle vier de gespreksverslagen van deze interviews opgenomen. Datum: ·· Betreft: Tijd: Locatie: Deelnemers:

28 september 2009 Tweede interview 10:00 – 11:30 OEC Nederland B.V., Noordsebosje 16, Hilversum Emile van Smaalen, Benjamin Janssen en Ehsan Anwari

OEC OEC is een DMS softwareleverancier die al een lange tijd actief is in de autobranche, zowel in Nederland als in Europa. OEC levert drie producten aan de autobranche, namelijk: Carsoft I Car Auto presentatie Testomgeving Het testproces van OEC is als volgt: RDC doet een aankondiging over de nieuw product of dienst en stuurt OEC de specificaties van het product. De specificaties die RDC aan OEC verstuurd zijn voorlopige specificaties en kunnen dus nog aangepast worden. Daarom wordt er vanuit OEC niet direct gehandeld. De applicatiemanager van OEC bekijkt of de specificatie van RDC kloppen. Vervolgens bekijkt de applicatiemanager van OEC in hoeverre het nieuwe product / dienst van RDC toepasbaar en verkoopbaar is. Als de applicatiemanager groen licht geeft, wordt er een softwareprogrammeur op de opdracht gezet om de producten van RDC in het softwarepakket van OEC in te bouwen. De programmeur bouwt de software en test deze ook, samen met de helpdesk, die op deze manier bekend wordt met de software voor (mogelijke) toekomstige vragen van klanten. Als er in de tests dingen naar voren komen die niet kloppen dan worden deze aangepast en opnieuw getest. Als het na aanpassingen nog niet correct functioneert, nemen de applicatiemanager contact op met RDC om bekijken waar het fout gaat. Een groot probleem met de testomgeving is dat deze vaak afwijkt van de live versie waardoor de software weer aangepast moet worden aan de nieuwe situatie. Dit is vooral lastig omdat de software van OEC is ontwikkeld aan de hand van de testomgeving, deze wordt doorgegeven aan de eindgebruiker. Als de (afwijkende) live versie dan actief wordt is de software van OEC meteen ‘verouderd’ en moet worden geüpdate. Een voorbeeld hiervan is het elektronisch factureren in ROB. In de testversie was het mogelijk om te allen tijde openstaande werkorder lijsten op te vragen, zo vaak als je wilde. In de live versie was dit niet meer mogelijk en kon je de openstaande werkorder maar een keer per half uur opvragen. Niet slim


HTS Autotechniek 25

volgens Emile, ook niet vanuit commercieel oogpunt. Dit werkt niet bij OEC en ook niet in de werkplaats. Dit is maar een voorbeeld, dit gebeurt vaker, aldus Emile. De testomgeving van INDI kan volgend Emile ook beter, er is geen openheid over de gegevens in de test. Liefst had hij een set kentekens gekregen die in het systeem zitten zodat hij beter kan testen. Als hij bijvoorbeeld een Toyota kenteken invoert krijgt hij als respons: Geen gegevens. Maar waar ligt dit aan? De software of dat de gegevens niet in de test zitten? Dat maakt het testen een stuk lastiger. Daarnaast werkt het niet echt lekker dat de gegevens uit INDI pas na 48 uur terugkomen, dit maakt van het testen een erg lang proces. Als voorbeeld hoe het beter kan geeft Emile het volgende voorbeeld: Als OEC een nieuw stuk software aanbiedt gaat deze eerst bij enkele klanten in een pilot-fase om er mee te werken. Tijdens deze fase is er bij OEC een contactpersoon waarmee klanten contact op kunnen nemen bij problemen, deze wordt dan ook bij het minste of geringste gebeld. Op die manier is OEC altijd op de hoogte van de problemen en kan er snel geschakeld worden om het probleem op te lossen. Dit levert meteen heel veel informatie op aan OEC over de functionaliteit van het product. Iets vergelijkbaars zou Emile graag willen zien bij RDC. Nu belt Emile niet als er iets mis is (dit kost teveel tijd en vaak krijgt hij geen dekkend antwoord), pas als het echt uit de hand dreigt te lopen neemt hij contact op met RDC, hierdoor gaat er veel informatie verloren waar RDC veel aan kan hebben. Als er een contactpersoon zou zijn die in de materie zit, kunnen problemen veel sneller worden opgelost en gaat de kwaliteit van de diensten omhoog. Afhandeling problemen / communicatie Emile geeft aan dat hij tegenwoordig niet meer op de hoogte wordt gebracht als er storingen zijn. Dat was in het verleden wel het geval. Hij zou nu ook graag per e-mail op de hoogte gebracht willen worden als er storingen of problemen zijn. Voordeel als dit wel het geval is: dan kan OEC aan zijn klanten vertellen wat er speelt en hoeven de klanten niet naar RDC te bellen. Als er problemen zijn belt Emile het liefst iemand die hem meteen kan helpen en vermijdt het contact met KCC. Hij heeft het idee dat de taakverdeling tussen de eerste lijn en tweede lijn niet geheel duidelijk is voor de medewerkers van de KCC. Wat hij hier aan toevoegt is dat de antwoorden die de medewerkers geven (zowel eerste lijn als tweede lijn) niet altijd de lading van de vraag dekken waardoor ze bij OEC niet altijd verder kunnen met de antwoorden. Emile denkt dat als de kantenservice van OEC meer informatie zou krijgen over de dingen die spelen binnen RDC en samen zou werken met de klantenservice van RDC (KCC), de klanten van OEC sneller geholpen zullen zijn en KCC werk zal worden afgenomen doordat de klanten van OEC minder vaak naar RDC zullen worden doorverwezen. De klantenservice van OEC zou dan eerste lijn zijn en KCC tweede lijn. Documentatie In de documentatie (ook de Release Notes) is de technische kennisgeving over het algemeen goed, alleen mist Emile vaak de commerciële vertaling van waarom iets wordt aangepast of is verbeterd. Op die manier is het lastig doorcommuniceren naar de klant. Bijvoorbeeld wat de verwachte functionaliteit bij de eindgebruiker zal zijn. Of wat is de taak van de van OEC helpdesk en die van RDC (KCC), hier kunnen afspraken over gemaakt worden. Een ander voorbeeld is de verandering in INDI, het is alleen nog maar mogelijk om informatie te krijgen over het eigen rayon, technisch is het prima onderbouwd, maar waarom is deze verandering gekomen? Wie heeft het verzonnen? Wat zijn de voordelen?


HTS Autotechniek 26

Informatiedag Hij vertrouwt op RDC voor de invulling van deze dag, Emile waarschuwt voor discussies, die van de kant van de softwareleveranciers pittig kunnen zijn. Thema voor de dag zou kunnen zijn: vergeet het verleden, vanaf nu gaan we het zo doen! Overige Emile is op 23 maart van dit jaar op de hoogte gebracht van een grote verandering in INDI, omdat op dat moment nog niet zeker was of en hoe deze verandering zou worden doorgevoerd is er destijds nog geen actie ondernomen bij OEC. (wel is er gekeken naar de uren die vrij gemaakt moeten worden door OEC om dit te implementeren) in de Release Notes van september/oktober worden er verdere details gegeven over de voortgang van deze verandering en wordt gemeld dat de nieuwe release beschikbaar is voor extern testen op 29 september. In de Release Notes van oktober (25 september verstuurd) wordt vermeld dat de datum voor extern testen is verschoven naar 29 september terwijl de live versie al op 1 oktober live gaat. OEC heeft dus maar twee dagen om te testen. Dat RDC hier zo weinig openheid over geeft vindt Emile een kwalijke zaak.


HTS Autotechniek 27

Datum: Betreft: Tijd: Locatie: Deelnemers:

29 september 2009 Tweede interview 16:00 – 16:30 XRAY, Energiestraat 29, Naarden Frank Koster, Benjamin Janssen en Ehsan Anwari

XRAY XRAY ontwikkelt taxatie software voor occasions voor de automotive branche. De klanten van XRAY bestaan voor een groot deel uit leasemaatschappijen, autohandelars en autoveilingen. Bij XRAY wordt momenteel gewerkt aan een herwaardering proces. Hierbij worden de advies waarden van alle auto’s bekeken en zo nodig aangepast. Dit doen ze zes keer per jaar. Testomgeving XRAY test zijn software in verschillende delen, ieder deel van een totaalpakket wordt getest en indien nodig aangepast. Als alle delen zijn getest wordt ook gehele programma getest. Testen gaat bij XRAY als volgt te werk: XRAY ontvangt van RDC de XML eigenschappen. Bij XRAY krijgt een programmeur de opdracht om het programma te (her)schrijven aan de hand van de specificaties. XRAY test de applicatie aan de hand van voorbeeldvragen. Als de respons op de voorbeeldvraag niet correct is neemt programmeur van XRAY contact op met RDC om te kijken waar het fout gaat. Frank geeft aan dat het voor hun makkelijker zou zijn als ze testdata zouden ontvangen van RDC, bijvoorbeeld de kentekens die in de test zitten. Het komt namelijk vaak voor dat ze fouten die in de testcyclus tegenkomen die niet door een programmeerfout zijn veroorzaakt maar door het gebruik van verkeerde gegevens (bijv. een verkeerd kenteken). XRAY maakt alleen gebruik van de NAP service van RDC. De NAP is een stabiel product die weinig grote veranderingen kent. Afhandeling problemen / communicatie Frank geeft aan dat sinds RDC met XML-berichten werkt, er relatief weinig storingen zijn. Met de NAP is het echter wel zo dat het wachtwoordenbeheer nogal eens voor problemen zorgt (dit wordt later besproken). Frank in geen voorstander van het KCC, hij is van mening dat de medewerkers van het KCC niet over voldoende technische kennis beschikken om de vragen van de programmeurs goed te kunnen beantwoorden. Vaak neemt XRAY contact op met Jeroen Termars en dat wordt als prettig ervaren. Bij storingen krijgt Frank altijd een e-mail, vaak een uur of twee nadat de storing plaatsvindt, maar dat vindt hij ook logisch omdat RDC natuurlijk eerst zelf moet uitzoeken wat er mis is en hoe het opgelost gaat worden. Frank is geen voorstander van een sms tijdens storingen.


HTS Autotechniek 28

Documentatie De PIT gids heeft voor XRAY geen toegevoegde waarde aangezien ze alleen met NAP werken en deze applicatie al werkend hebben. Frank heeft ook geen verdere toevoeging voor de PIT gids. Informatiedag Frank heeft geen ideeën die van toegevoegde waarde zijn voor de informatiedag. Overige De software van XRAY logt bij RDC in met het inlognaam en wachtwoord van de klant, omdat de klanten zelf het wachtwoord kunnen wijzigen of kunnen laten resetten komt het regelmatig voor dat de wachtwoorden in de database van XRAY en RDC niet meer dezelfde zijn. Hierdoor kan de software dus niet meer inloggen en heeft de klant een probleem. Dit moet dan aangepast worden in de database van XRAY en hier gaat veel tijd in zitten. Dit zou opgelost kunnen worden door de softwareleveranciers (in dit geval XRAY) in te laten loggen met hun eigen ID, als ze dan bij RDC ‘binnen’ zijn wordt het klantnummer gebruikt voor het versturen en ontvangen van data zodat RDC kan zien wie wat aan het doen is. Op die manier kan de software altijd inloggen en hoeft XRAY de wachtwoorden van zijn klanten niet meer te weten. NAP is weliswaar gratis, maar met het wachtwoord kunnen alle diensten die een eindgebruiker afneemt worden aangesproken, dit noemt Frank een beveiligingslek, hij wil de wachtwoorden van de klanten helemaal niet weten. Omdat NAP een gratis dienst is, zou het handig zijn om elke klant van RDC automatisch aan te melden voor NAP. Nu moet Frank nog elke gebruiker apart aanmelden bij RDC, dit kost ook weer tijd en zou gemakkelijk kunnen worden geëlimineerd door iedereen standaard hiervoor aan te melden.


HTS Autotechniek 29


30 september 2009 Tweede interview 11:00 – 12:00 Autoflex, Midden Engweg 15b, Putten Bert Schuit, Benjamin Janssen en Ehsan Anwari

Autoflex Autoflex ontwikkelt software voor een brede groep binnen de automotive branche. Ze werken met vier basispakketten. Deze pakketten kunnen naar de wensen van de eindgebruiker aangevuld worden met extra diensten. De extra diensten kunnen bestaan uit facturering of accountancy pakketen tot planning tools en RDW communicatie pakketen. Zo betaalt de klant niet voor diensten die hij/zij niet nodig heeft. Autoflex onderscheidt zich van de concurrentie door gebruik te maken van een grafische lay-out. Dit maakt de software gebruiksvriendelijk en erg overzichtelijk. Testomgeving Autoflex heeft momenteel alleen de transactionele dienst ROB draaiende en hebben dus niet heel veel ervaring met de testomgeving van RDC. Wat ze hierbij hebben gemist is voorbeelddata die in de test zit. Welke gegevens zitten er in de test en welke berichten kan ik terug ontvangen? ROB geeft soms ‘rare’ foutmeldingen, bijvoorbeeld als in het beginscherm het bankrekeningnummer niet goed is ingevuld is de respons ‘dealernummer niet bekend’, dat kan niet kloppen volgend Bert. Een ander voorbeeld is als er een of meerdere velden niet correct is ingevuld, dan is de respons ‘een van de velden is niet goed ingevuld’. Dit is weinig bruikbare informatie, want welk veld is niet goed ingevuld? Autoflex zou graag een testomgeving hebben die altijd bereikbaar is en goede foutmeldingen geeft. Daarnaast zou het een grote vooruitgang zijn als er bij RDC iemand direct te bereiken zou zijn die hulp kan bieden als er vragen en/of problemen zijn in het testtraject, in plaats van het KCC die alles in tweede lijn zetten. Afhandeling problemen / communicatie De communicatie met RDC noemt Bert erg stroef. Zo zijn ze al bijna een jaar bezig om ook andere diensten van RDC te integreren in de software, maar het duurt heel erg lang voordat ze hiervoor de juiste gegevens krijgen (documentatie, (voorbeeld)testdata). Hiervoor is al meerdere malen contact geweest met RDC, maar nog steeds hebben ze nog niets ontvangen waarmee ze verder kunnen! Dit kost RDC ook klanten, omdat iedereen die software afneemt bij Autoflex nu overstapt naar VWE. De afhandeling van problemen is ook niet ideaal te noemen volgens Bert. Hij vindt het raar dat de softwareleveranciers bij RDC binnenkomen op het KCC. Softwareleveranciers zijn geen klanten, aldus Bert. Calls duren veel te lang en hij heeft veel liever een direct contactpersoon die hem meteen, of in ieder geval binnen een acceptabele termijn, antwoord kan geven. Het praat ook gemakkelijker met iemand die dezelfde ‘taal’ spreekt (van een programmeur). Storingen hebben ze over het algemeen weinig mee te maken gehad. Als er iets mis gaat bij RDC zouden ze graag een e-mail willen ontvangen met daarin de aard van de storing, de gevolgen dan van de storing en hoelang het duurt voordat het is opgelost. Bij VWE gaat dit zo en dat werkt heel goed.


HTS Autotechniek 30

Documentatie De huidige documentatie is niet heel handig, er zit weinig structuur in. Maar omdat Autoflex hier (nog) niet heel veel ervaring mee heeft kunnen ze hier niet heel veel over zeggen. In de documentatie zouden ze graag willen zien welke foutmeldingen er kunnen voorkomen en welke berichten je terug kunt verwachten bij bepaalde vraagberichten. Een andere wens is om de voorbeelddata die in de testomgeving gebruikt wordt te ontvangen zodat er sneller en beter kan worden getest. Commerciële informatie is ook handig voor in de documentatie, maar dit moet wel duidelijk gescheiden zijn van de technische informatie. Informatiedag Bert had geen ideeën voor de informatiedag, hij zou wel komen. Overige nvt


HTS Autotechniek 31


07 oktober 2009 Tweede interview 10:00 – 11:30 MivarGroup, De Hofstede 30, Lienden Arjan Moen en Benjamin Janssen

MivarGroup Mivar is opgericht in 1990 als automatiseringsbedrijf en is inmiddels uitgegroeid tot een zeer gespecialiseerde groep van bedrijven op het gebied van structureren van informatiestromen binnen diverse branches. De MivarGroup is internationaal actief voor diverse klanten. De MivarGroup bestaat uit: Mivar ICT Systemen MivarAutomotive ICT & Automotive Informatie systemen Driver Automotive Business Software Testomgeving De testomgeving die RDC nu heeft is te beperkt. Vooral de testen met betrekking tot de RDW diensten is heel beperkt. Er zijn maar heel weinig kentekens in deze test en ook de functionaliteit van de test is niet handig. Zo kan Arjan maar een keer per dag een bepaalde test draaien (APK afkeuren met als melding terug: steekproef), terwijl hij dit wel tien keer wil proberen, daardoor wordt zijn doorlooptijd erg lang. Arjan geeft aan dat hij in principe aan drie kentekens genoeg heeft: een diesel, een benzine en een kenteken die moet wachten op een steekproef, maar nu weet hij niet welk kenteken staat voor welke specificatie en dat maakt het testen lastiger. Als voorbeeld geeft hij de testomgeving van VWE, daar kan hij met actuele gegevens werken, dus met alle kentekens. Als er bij een klant dus iets niet werkt, kan hij het zelf testen met datzelfde kenteken en precies zien waarom het bij de klant niet werkt. Arjan zou graag zo vaak kunnen testen met een kenteken zoals hij dat wilt, niet dat hij een dag moet wachten voordat hij opnieuw met eenzelfde kenteken kan testen, en een database van kentekens die op de realiteit is gebaseerd. Afhandeling problemen / communicatie Over het KCC is Arjan zeer ontevreden. Liever neemt hij helemaal geen contact op met KCC en neemt hij direct contact met iemand op die hem meteen kan helpen, maar omdat hij in tweede lijn geen mensen meer kent moet hij het wel via KCC doen. Als hij belt met een vraag of deze e-mailt dan weet hij van tevoren al dat het heel lang gaat duren, binnen drie weken een antwoord van RDC noemt hij ‘snel’. Hij laat me enkele voorbeelden zien van e-mailverkeer waar erg veel tijd overheen gaat. Ook de kwaliteit van de antwoorden is vaak niet goed en daar kan Arjan dan weinig mee. MivarGroup werkt (net als RDC) met Topdesk, dus Arjan weet hoe goed deze tool kan werken. Zo is er de mogelijkheid in Topdesk om klanten (extern) in bepaalde mate toegang te verlenen tot het programma, zodat deze zelf zijn call kan ‘volgen’ en op die manier kan zien wat en of er iets mee gebeurt.


HTS Autotechniek 32

Door deze gang van zaken kunnen de programmeurs van de MivarGroup weinig motivatie opbrengen om updates of nieuwe producten voor RDC te ontwikkelen, liever werken ze met/voor VWE. Documentatie Arjan geeft toe dat er ontzettend veel kennis is binnen RDC, maar tegelijkertijd heeft hij het gevoel dat niemand weet waar die kennis te vinden is. De documentatie zoals die nu op de site van RDC staat is waardeloos, gedateerd en ongestructureerd. Veel bestanden zijn al twee jaar oud (of nog ouder) en het staat er ook in verschillende formaten (.doc/.pdf/.html). Wederom haalt hij VWE erbij om te laten zien hoe ze het daar doen (XML Mode, Bible for clients). Dit boekwerk zou een goed voorbeeld voor RDC zijn zegt Arjan. Voor elke dienst vraag- en antwoordberichten en actueel, dat is wat hij graag zou willen zien, ook van RDC. Informatiedag Tijdens de informatiedag zou hij graag mee willen praten over de manier van informatieverstrekking. Het maakt hem in principe niet uit hoe lang het duurt (“al kom ik natuurlijk niet voor tien minuten naar Amsterdam”) als het maar nuttig is, de frequentie hiervan is afhankelijk van de wijzigingen en updates, in principe moet een keer per jaar voldoende zijn denkt hij. Overige Arjan had nog enkele punten die hij graag kwijt wilde: - MivarGroup is een tijd geleden begonnen met het ontwikkelen van de TVI dienst, hier hebben ze destijds documentatie aangevraagd en ook meerdere keren gevraagd of deze dienst nog draaide en of de documentatie die hij had ontvangen de juiste was, hier twijfelde hij namelijk aan. Op beide vragen werd bevestigend geantwoord. De eerste versie was klaar en hij bleek toch niet de juiste documentatie te hebben en moest het weer terug naar de tekentafel. Toen hij met de tweede versie wilde gaan testen bleek de hele dienst niet meer te draaien en had hij dus alles voor niets gemaakt! - MivarGroup wordt niet op de hoogte gehouden van updates en nieuwe producten, via zijn klanten moet hij vernemen dat er kennelijk een update is geweest omdat de software niet meer functioneert. Via dit e-mailadres wil hij graag op de hoogte worden gebracht van updates etc.: [email protected]


HTS Autotechniek 33

Bijlage IX Marktaandeel per dienst In deze bijlage is te zien hoeveel procent van de markt door RDC wordt bediend. Hierbij is gekeken naar het aantal klanten en niet het aantal transacties. Tevens is in het onderstaande tabel ook te zien hoeveel klanten RDC bedient. Zowel het percentage van het marktaandeel als het aantal klanten zijn per dienst uiteengezet. Diensten APK/Tagasas service BPM service DVS service INDI service GPS service ORB service ROB service VER service NAP service

Marktaandeel 2009 Aantal klanten RDC ± 62% 2101 ± 30% 685 ± 30% 132 100% Geen gegevens 100% Geen gegevens ± 62% 1707 100% 1859 100% Geen gegevens ±78% 5004

Tabel 1: Marktaandeel en het aantal klanten van RDC per dienst


HTS Autotechniek 34

Bijlage X

Prijsinformatie RDC tov concurrentie

In deze bijlage zijn de prijzen die RDC hanteert voor haar producten en diensten te zien. Daarnaast is ook te zien welke prijzen de concurrenten hanteren en waar het omslag punt ligt. Alle bedragen zijn exclusief BTW en zonder RDW leges (deze tarieven zijn voor alle providers hetzelfde). RDC Communicatiediensten

Afkorting (RDC)

Tarief per maand

Tarief per transactie

Tarief per maand

€ 0,29

Tarief per transactie

APK

Afmelden inbouw roetfilter

ROET

€ 2,15

Gratis

Afmelden inbouw LPG installatie

LPG

€ 3,00

€ 2,70

€ 0,25

Afmelden inbouw snelheidsbegrenzer

SB

€ 3,00

€ 2,70

€ 0,25

Afmelden inbouw tachograaf

TA

Gratis

€ 2,70

€ 0,25

Auto Taxatie Systeem

ATS

€ 0,78

€ 4,95

A2SP

APK afmelden

AutoLOG

€ 0,42

VWE Tarief per Tarief per transactie met maand ab.

€ 0,25 € 1,50

VDC Tarief per transactie € 0,30

€ 0,25

Geen gegevens gevonden


€ 1,56

Gratis


BOVAG Auto Registratie Systeem

BARS

€ 8,00



Raadplegen BPM bedragen

BPM

€ 4,95

Gratis

Controle bedrijfsvoorraad

CB

€ 4,85

€ 3,95

Document Verificatie Systeem

DVS

€ 6,10

Garage Polis Systeem

GPS

Gratis

Online Registratie Auto's in Demontage

ORAD

€ 14,00

€ 0,06

€ 6,80

€ 0,25

€ 0,30

Online Registratie Bedrijfsvoorraad

ORB

€ 5,75

€ 0,06

€ 6,80

€ 0,25

€ 0,30

Online Registratie Auto's voor Export

OREH

€ 3,45

€ 0,06

€ 4,95

€ 0,29

€ 0,25

€ 0,30

SMS uw klant

SMS

€ 8,35

€ 0,26

€ 5,95

€ 0,23

€ 6,50

€ 0,25

Technische Voertuig Informatie Basis

TVI

€ 0,04

€ 0,03

€ 5,00

€ 0,25

€ 0,23

€ 0,20

TV

€ 0,19

€ 0,18

€ 0,25

VKR

€ 1,09

€ 1,60

€ 0,25

Technische Voertuig Informatie Uitgebreid Tenaamstelling bij het autobedrijf Versnelde Kentekenregeling Tabel 2: Tarieven RDC, VWE, A2SP en VDC

€ 0,32

€ 4,95

€ 0,25 € 5,00 € 0,27


€ 5,00

€ 0,25


€ 0,30


HTS Autotechniek 35

Communicatiediensten

Afkorting (RDC)

RDC tov VWE Wie is goedkoper (omslagpunt)

RDC tov A2SP Wie is goedkoper (omslagpunt)

APK afmelden

APK

RDC tot 30 transacties

A2SP altijd

Afmelden inbouw roetfilter

ROET

VWE altijd

A2SP tot 3 transacties

Afmelden inbouw LPG installatie

LPG

VWE altijd


Afmelden inbouw snelheidsbegrenzer

SB

VWE altijd


Afmelden inbouw tachograaf

TA

RDC altijd

RDC altijd

Auto Taxatie Systeem

ATS

Geen vergelijk

Geen vergelijk

VWE altijd

Geen vergelijk

AutoLOG

RDC tov VDC Wie is goedkoper (omslagpunt) VDC altijd

BOVAG Auto Registratie Systeem

BARS

Geen vergelijk

Geen vergelijk

Raadplegen BPM bedragen

BPM

VWE altijd


Controle bedrijfsvoorraad

CB

VWE altijd

RDC altijd

Document Verificatie Systeem

DVS

VWE altijd

A2SP altijd

Garage Polis Systeem

GPS

Geen vergelijk

Geen vergelijk

Nationale Auto Pas

NAP

Geen verschil

Geen verschil

Online Registratie Auto's in Demontage

ORAD

VWE altijd


VDC tot 59 transacties

Online Registratie Bedrijfsvoorraad

ORB

RDC tot 14 transacties



Online Registratie Auto's voor Export

OREH

RDC altijd



SMS uw klant

SMS

VWE altijd

A2SP altijd

Technische Voertuig Informatie Basis

TVI

VWE altijd

RDC altijd

VWE altijd

Geen vergelijk

Technische Voertuig Informatie Uitgebreid Tenaamstelling bij het autobedrijf

TV

VWE altijd

RDC altijd

Versnelde Kentekenregeling

VKR

RDC altijd

Geen vergelijk

VF

Geen vergelijk

Geen vergelijk

Voorraadfinanciering Tabel 3: Prijsvergelijking RDC tov concurrentie

RDC altijd

NB: De informatie gebruikt in deze tabel is gevonden op de websites van de verschillende aanbieders, dezelfde informatie die potentiële klanten zoeken en vinden bij het maken van een keuze tussen de verschillende providers.


HTS Autotechniek 36

Bijlage XI Business case wachtwoord vergeten De procedure met betrekking tot het wachtwoordbeheer binnen RDC is al enige tijd een punt van discussie. Na een inventarisatie van deze procedure zijn er een aantal redenen die deze discussie teweeg brengt: Meldingen KCC 21 % van het aantal calls op KCC zijn WW reset calls. Dit komt neer op 25.000 calls per jaar. Dit legt dus een zware belasting op de tijd en inzetbaarheid van het KCC. Een account, meerdere keren inloggen Momenteel is het mogelijk om onder één account meerdere keren in te loggen. Probleem is dat wanneer een gebruiker het wachtwoord verandert de overige gebruikers op de hoogte moeten zijn. Is dit niet het geval dan is het zo gebeurd dat een wachtwoord drie keer fout wordt ingevoerd en het account wordt geblokkeerd waarna er contact wordt opgenomen met RDC of er wordt direct contact opgenomen met RDC. “Het Schiphol van de mobiliteitsbranchel” Om “Het Schiphol van de mobiliteitsbranche” te willen zijn is er toegang tot de portal nodig op gebruikersniveau. Momenteel worden accounts op klantniveau afgegeven. Dit houdt in dat het niet mogelijk is om diensten aan te bieden per gebruiker, zowel voor interne- als externe gebruikers. Ook de relatie tussen klantnummer en gebruikersnaam (gebruikersnaam = RDC+klantnr+gebruikersnr (bijv. RDC 123456 001)) heeft geen “openbaar” format 60 dagen WW veranderen De functionaliteit binnen het RDC systeem, mede op advies van KPMG, brengt met zich mee dat een klant na 60 dagen haar WW moet aanpassen. In combinatie met bijvoorbeeld de reden dat meerdere gebruikers kunnen inloggen op één account zorgt dit voor nog meer calls bij het KCC. Vraag en antwoord voor verkrijgen van wachtwoord Om alsnog je wachtwoord te krijgen moet er momenteel bij het kopje “wachtwoord vergeten” op rdc.nl een vraag beantwoord worden. Gebruikers weten deze vraag vaak niet (meer) en het is een omslachtige en verouderde methode. Gerelateerd klantnummer en gebruikersnaam Het klantnummer en gebruikersnaam zijn gerelateerd aan elkaar: gebruikersnaam = RDC+klantnummer+gebruikersnummer. Gebruikers zijn moeilijk te identificeren, externe gebruikersnamen zijn niet mogelijk, dit is onpersoonlijk en niet flexibel. Business case De procedure van het wachtwoordbeheer moet aangepast worden. In deze business case wordt een voorstel gedaan om tot een procedure/ proces te komen die de bovenstaande redenen aanpakt en oplost. De business case heeft als doel: De wachtwoord vergeten procedure eenvoudig te maken voor de gebruiker De wachtwoord vergeten procedure aan de beveiligingseisen te laten voldoen die door bijvoorbeeld KPMG en RDW worden afgegeven KCC calls te verlagen Oplossing die voor de toekomst is geborgd Eventuele secundaire voordelen zijn (later in dit document komen een aantal terug): Omzet verhoging voor RDC Kostenverlaging voor RDC


HTS Autotechniek 37

Klantvriendelijkheid verhogen Professionaliteit verhogen Digitale facturatie Provisioningslag (ophalen van gebruikersgegevens) Om dit te bereiken worden de volgende functionaliteiten belicht: Aanpassing proces voor het aanvragen/ wijzigen van een wachtwoord Aanpassen proces voor wijzigen/ verwijderen/ aanvragen van gebruikers Aanpassen beheer/ werking van gebruikersaccounts Verwachte opbrengsten Meldingen KCC Indien 50% minder meldingen, dan betekent dit een kostenbesparing van 0,21 FTE. (+/-50.000*0,21 = € 10.500 per jaar) Bij een afname van 75% is dit 0,32 FTE  € 16.000 per jaar De cijfers volgen uit een onderzoek wat is uitgevoerd door het KCC. De besparing van FTE kan door KCC direct ingevuld worden voor commerciële acties zoals outbound calls. Bij een 50% besparing van de calls = 12.500 calls per jaar over voor commerciële activiteiten indien de duur van het gesprek identiek is. Aanpassen proces voor wijzigen/ verwijderen/ aanvragen van gebruikers Verlaging exploitatiekosten Het staat vast dat de exploitatiekosten aan de administratieve kant worden verlaagd. De klant voert zelf gebruiker op en af, de tarieven worden niet steeds aangepast als er een gebruiker wordt toegevoegd of afgevoerd. Er is niet onderzocht hoeveel FTE dit oplevert. Aanpassen beheer/ werking van gebruikersaccounts Dit is afhankelijk van een nieuwe afrekenstructuur en wordt nog niet meegenomen in deze business case Verlagen exploitatiekosten Dit is afhankelijk van een nieuwe afrekenstructuur en wordt nog niet meegenomen in deze business case Omdat op gebruikersniveau wordt geautoriseerd, is het wel mogelijk om meer richting provisioning te gaan. De exploitatiekosten worden dus lager.

Reeds bekende risico’s en afhankelijkheden Eén concurrent user Om het “Schiphol van de mobiliteitsbranchel” te willen zijn is het rekenen van een tarief om via internet producten/ diensten af te nemen nog steeds niet geheel van deze tijd (“u wilt naar binnen om iets te kopen, dat kost u dan € X,-!!!”) Omzet verlies/ investering Omzetverlies wordt misschien niet geheel goed gemaakt door de opbrengsten die uit het project komen. Echter belangrijk zijn ook uitstraling naar de markt, professionaliteit, etc. oftewel investeren in de toekomst van RDC en haar lange termijn visie (“Schiphol van de mobiliteitsbranchel”). Ook de afrekenstructuur bepaald hoeveel investering er wordt terugverdiend.


HTS Autotechniek 38

Conclusie Het onderwerp wachtwoord vergeten en alle projecten die binnen deze business case vallen zijn jarenlang een onderwerp van gesprek. Om deze business case te realiseren moet RDC een investering doen die niet direct terug te verdien is met harde cijfers. Maar de opsomming van opbrengsten en voordelen zijn genoeg redenen om met het project van start te gaan: Schipholgedachte prediken/ toegankelijker voor externe partijen Exploitatiekosten verminderen Vooruitgang in plaats van stilstand Verhoogde beveiliging KCC ontlasten Professionaliseren e-facturatie Weet wie onze klanten zijn (gegevens op gebruikersniveau) Meer afzet online Eerste stap naar self-contracting


HTS Autotechniek 39

Bijlage XII KPI KCC KCC is een afdeling dat met duidelijke KPI’s werkt. In deze bijlage is te zien hoe de KPI’s van KCC er uitzien. Het gaat hier om de KPI rapportage van de maand oktober. De KPI ’s die hieronder zijn weergegeven, zijn tot 31 december 2009 geldig, voor 2010 worden nieuwe, meer ambitieuze, KPI’s vastgesteld. KCC neemt in 80% van de tijd de telefoon binnen 60 seconden op Mrt. < 60 sec. Wachtwoord 76 % ASP 49 % Voertuigen 42 % Andere Vragen 92 % KA 70 % ROB 41 %

Apr. < 60 sec. 82% 65% 40% 94% 71% 71%

Mei < 60 sec. 82% 74% 44% 98% 70% 43%

Juni < 60 sec. 72% 68% 36% 99% 63% 54%

Juli < 60 sec. 90% 86% 53% 99% 86% 85%

Aug. < 60 sec. 94% 91% 57% 95% 100% 87%

Sep.< 60 sec. 94% 89% 59% 99% 82% 91%

Okt. < 60 sec. 95% 91% 62% 100% 97% 90%

Tabel 4: Percentage telefoon opgenomen binnen 60 seconden per onderdeel

De maximale wachttijd in de maand is maximaal 15 minuten. Score: 5.20 min.  De gemiddelde wachttijd: 80% < 60 seconden Score: 0.33 seconden  KCC behandelt alle e-mail binnen 8 werkuren. Indicatieve score: op 2 e-mails ( 9 uur) na zijn alle e-mails < 8 uur verwerkt  KCC lost 80% van de calls zelf op. Score: 86%  KCC meldt 80% van de calls, opgelost in 2e lijn, binnen 2 uur af bij klant (als klant bereikbaar). Score: Deze rapportage is nog niet beschikbaar. Vraag is uitgezet bij Topdesk. Volledige registratie(!): 80% van de calls wordt geregistreerd in Topdesk. Score: 68%  (zoals eerder gemeld is rond de 70% de hoogst haalbare score) Juiste routering: 80% van alle berichten wordt correct gerouteerd. Score uit steekproeven: 95% correct  Inhoudelijk correct: 80% is inhoudelijk correct. Score uit steekproeven: 88% correct  Klanttevredenheidscijfer: het streven voor 2009 is een 7 (uit het PvA KCC). Score: 7,9  Toelichting bij de KPI’s en cijfers De hoogste en laagste dagmaxima langst wachtende van oktober zijn: De 5 hoogste zijn: 5.20–5.14–5.08-4.43–4.38 min. De 5 laagste zijn: 1.39–1.49–1.53–1.57–2.24 min. Klanttevredenheid en luisteren naar de klant: KTO steekproef oktober nav 130 enquetes: behaalde cijfer: 7,9 ligt boven het streven en KPI voor 2009 (=7). Aanbevelingen: 83 % heeft geen aanbeveling / vindt alles ok, 2 % vindt dat de bereikbaarheid sneller kan (opnemen telefoon, lengte menu e.d.), 3 % vindt dat de applicaties niet goed functioneren, 11 % overig


HTS Autotechniek 40

Letterlijke opmerkingen van klanten: diverse opmerkingen en ontevredenheid over WW reset, import auto’s in OBS niet goed, omschrijving “automaat” in ROB en ROB te strikt met centen, meer vrije tekstruimte gewenst in ROB, ASP traag, NAP, na correctie krijgt klant geen E-pas, Keurmeester baalt van doorverwijzing naar RDW, Postcode onthouden in NDA, tel. nr. ontbreekt bij foutmelding 801. Vergelijking in de markt, waarbij wel de opmerking moet worden geplaatst dat deze KTO onderzoeken wat uitgebreider en specifieker zijn en dat het hier gaat om B to C servicedesks. Rabobank: 7,3, Eneco: 7,1, SNS: 7,0 , ING Postbank: 6,3. Incident Coördinatie Verstoringen e.a. zaken die in oktober, service affecting zijn geweest (extra calls): 7 okt.: storing Allure/ASP: van 15.50 uur tot 16.05 (connectie server 96): klant Vanhier klaagt over verloren connectie en verlies data. Vanhier wil reden weten (!!). Extra telefoontjes: 10. 27 okt. 9.15 uur: onverwachtte (??) call-toename in combinatie met 1 niet werkende telefoon van een van de agents, zorgt ervoor dat de langstwachtende 5.20 min moest wachten. 7 okt., ochtend: telefoontoename door internetstoring bij diverse providers (KPN, XS4all e.d.), waardoor diverse klanten niet op de RDC site kunnen inloggen. Extra calls: 100 28 okt.: Problemen met inloggen door Pon dealers (reden?) in combinatie met 2 zieke agents. Extra calls: 30 (tussen 8.30 en ??) 28 okt.: probleem met tenaamstellen (probleem bij RDW): extra calls: 100 (tussen 9.00 en 13.15). Trendanalyse: Verwachtte aantal calls: kleine afname in nov. en dec. t.o.v. okt. (bron:2008). Verwacht wordt dat het aantal klantcontacten vooral in jan. zal toenemen ivm bijv. jaarafsluitingen: jan. is historisch (zie 2009)een drukke maand. Met name het aantal ASP calls verdubbelt dan bijna t.o.v. november. Verwachting is dat we de eerste weken van nov. een toename zullen zien van het ziekteverzuim. Wetenswaardigheden, vooruitblik en aanbevelingen Met verschillende 2e lijnsafdelingen de afspraak gemaakt om structurele (verbeter) zaken bij de KCC manager neer te leggen en om incidenten bij Rob/Roberto (incident coördinatoren) te placeren ter coaching bij de individuele KCC agents. Dit ter verbetering kwaliteit en om subjectieve beeldvorming te voorkomen en structurele van incidentele zaken te scheiden. In het kader van incidentmanagement en de rol van het KCC daarin zullen volgende zaken als eerst aangepakt worden: 1. Inzichtelijkheid van bijv. doorlooptijden in de keten (wekelijkse rapportage) 2. Eigenaarschap KCC agents van meldingen/incidenten (+ pro actieve communicatie naar klant). 3. Het incidentmanagement (keten) proces (verbeteringen). Kerngetallen van aantal telefoons, e-mails en Topdesk in 2009 Telefoon Telefoon Aanbod w.v. Wachtwoord w.v. ASP Beantwoord Perc. Beantw Gem.wachttijd Max. wachttijd Email

Febr. 10.838 1942 1729 7033 65% 1.51 16.38 Feb.

Mrt. 9.737 2152 1687 8349 85% 1.09 25.45 Mrt.

Apr. 9.609 2385 1608 8106 84% 0.54 9.36 April

Mei 8.406 2091 1667 7089 84% 0.51 11.10 Mei

Jun. 9606 2569 1917 8323 87% 0.44 8:58 Juni

Jul. 8594 2099 1331 7139 86% 0.38 9.00 Jul.

Aug. 7119 2327 1043 6119 86% 0.35 6.47 Aug.

Sept. 7420 2398 1462 6908 93% 0.31 6.26 Sept.

Okt. 8001 2264 1291 6948 87% 0.33 5.20 Okt.

Nov.

Nov.


HTS Autotechniek 41

VGS-Email ASP-email Email Overig KCC-Topdesk Calls behandeld KCC Oplos % Naar 2e lijn

671 1678 860 Feb. 10.242 87 % 1264

680 1355 885 Mrt. 11.269 86 % 1490

804 1305 1201 April 11.416 84% 1822

676 1243 1142 Mei 10.150 89% 1111

567 1354 1294 Juni 11.538 91% 1322

521 1365 1151 Jul. 10176 91% 1182

Afd. PF2 Klant-Adm. Inform.beh. Overig Reg.in Topdesk Reg.% Topdesk Naar Prioriteit Aantal P1 Aantal P2 Aantal P3 KTO

428 157 333 346 3860 38 % Feb. 42 132 3686 -

402 214 349 525 5935 53 % Mrt. 74 136 5725 -

359 220 361 882 6766 59% April 44 84 6638 -

279 196 299 337 5857 58% Mei 22 32 5385 -

341 236 275 470 6326 67% Juni 20 36 6256 7.7

384 155 270 373 5708 72% Jul. 28 178 5498 7.8

Tabel 5: Kengetallen telefoon, e-mail en Topdesk per maand (2009)

245 730 913 Aug. 8007 89% 872 261 121 248 242 5103 64% Aug. 52 229 4814 7.6

258 953 1157 Sept. 9276 88% 1126

402 700 1034 Okt. 9078 86% 1228

336 160 269 380 6039 65% Sept. 15 287 5737 7.6

342 170 336 380 6172 68% Okt. 66 567 5538 7.9

Nov.

Nov.


HTS Autotechniek 42

Bijlage XIII

Actieplan

Het actieplan is een hulpmiddel om de aanbevelingen te implementeren. 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 te kunnen geven.

Actieplan RDC: SWL, van klant tot relatie

Nog geen actie ondernomen Gestart Uitwerking verbetering Verbetering ingevoerd Nieuwe werkwijze is routine

Knelpunt

KCC

Acties

Wie (vervanger)

Actie ingezet

Actie voltooid

Opmerking

Technische kennis van KCC medewerkers sluit niet aan bij de 1.1 verwachtingen van de softwareleveranciers

Aanstellen van een technisch specialist bij KCC die verantwoordelijk is voor de softwareleveranciers en alle tweede lijns calls

Dio van Gils / Richard Snijders

1-feb-10

1.2 Oplostijd van calls is te lang

KCC medewerkers moeten eigenaar worden van de calls en moet deze actief op doorlooptijd bewaken. Vertragingen proactief communiceren met softwareleveranciers

Dio van Gils

1-okt-09

31-mrt-10

Afspraken maken met softwareleveranciers over oplostijd

Status van calls wordt niet naar de 1.3 softwareleveranciers gecommuniceerd

De status van de calls moeten proactief naar de softwareleveranciers worden gecommuniceerd, "Nee" is ook een antwoord

Richard Snijders/ Technisch specialist/KCC

1-okt-09

30-nov-09

KCC moet bij het aanmaken van de call aangeven wat de verwachte oplostijd is

Kennis huidige KCC medewerkers upgraden (bijvoorbeeld met trainingen en feedback op calls)

Status


HTS Autotechniek 43

Knelpunt

Acties

Nader onderzoek uitvoeren naar RDC beschikt niet over een dedicated 2.1 mogelijkheden voor een dedicated testomgeving testomgeving Testdata die beschikbaar wordt gesteld aan softwareleveranciers is Testdata beter documenteren (in PIT gids) en 2.2 niet volledig en bevat veel communiceren met SWL onduidelijkheden

Testomgeving

Het komt regelmatig voor dat de test 2.3 release verschillend is ten opzichte van de live release

Tijdig communiceren van 2.4 releasedatum van live versie (live release in productie)

Lange communicatie lijnen, de softwareleveranciers krijgen niet 2.5 direct iemand te spreken die hun vragen kan beantwoorden

Als er feedback is aan de hand van de test release de applicatie aanpassen vervolgens opnieuw testen applicatie in (live)productie gaat. Als het een kleine aanpassing is kan dit ook dmv een mail worden gecommuniceerd Tijdig de (verwachte) datum communiceren waarop een applicatie in (live) productie gaat. De geplande release datum moet naar de SWL gecommuniceerd worden voor er aan een project wordt begonnen, wordt de deadline niet gehaald, dit direct communiceren met SWL Een technische specialist bij KCC aanstellen die alle testgerelateerde vragen kan beantwoorden. Dit is dezelfde persoon als bij actiepunt 1.1

Wie (vervanger)

Actie ingezet

Richard Snijders

31-dec-09

Richard Snijders

1-okt-09

Actie voltooid

Opmerking Dit jaar wordt nog een budgetaanvraag gedaan

31-dec-09

In de PIT gids wordt hier aandacht aan besteed

Richard Snijders

1-okt-09

31-dec-09

als er aanpassingen zijn, direct per mail naar de softwareleveranciers communiceren en in PIT gids aanpassen

Werner Boldewijn

1-sep-09

Continu proces

Heeft Werner opgepakt en is inmiddels routine

Dio van Gils / Richard Snijders

1-feb-10

Status


HTS Autotechniek 44

Knelpunt

Documentatie

Acties

Wie (vervanger)

Actie ingezet

Actie voltooid

Opmerking

De huidige documentatie is 3.1 incompleet en heeft geen duidelijke structuur

PIT-Gids zo snel mogelijk afronden en delen met de SWL, iedere SWL moet een exemplaar ontvangen en er moet ook een plaats voor komen op de website van RDC

Richard Snijders / Vitor Alves da Silva

1-okt-09

31-dec-09

Concept versie van de PIT gids is inmiddels klaar (29-11)

De documentatie is voor iemand die 3.2 de website van RDC niet kent zeer moeilijk te vinden

De lay-out van de website moet aangepast worden zodat de documentatie snel te vinden is (binnen 3 klikken vanaf de homepage)

Hugo Weijers

24-nov-09

31-mrt-10

Totale website wordt vernieuwd. (rdc.nl en portal)

Continu proces

Vitor zal de PIT gids beheren. De nieuwste versie is altijd op de rdc.nl te vinden. de softwareleveranciers worden per email op de hoogte gesteld als er nieuwe versie beschikbaar is

De documentatie moet een levend bestand De huidige documentatie is verouderd zijn en moet te allen tijde up to date zijn. 3.3 en bevat hierdoor veel informatie die Hiervoor moet een eindverantwoordelijke niet meer te gebruiken is worden aangewezen die de documentatie aanpast en update wanneer dit nodig is

Richard Snijders / Vitor Alves da Silva

31-dec-09

Kennisborging

Kennis wordt intern niet goed 4.1 geborgd en gaat verloren bij het uitdiensttreden van medewerkers

De kennis die het personeel heeft moet vastgelegd en gedeeld worden in RDC-wiki, Topdesk en Microsoft Dynamics (CRM systeem)

Werner Boldewijn / Richard Snijders / 1-jan-09 Erik Nederlof / Cees Horvers

31-mar-10 routine, Continu proces

"Spread the knowledge" Bewaking van procesbeschrijving

Lange communicatie lijnen, intern is het niet onmiskenbaar duidelijk bij 4.2 wie je aan kan kloppen voor een oplossing

Tijdens het documenteren van elke dienst moet er ook vast gelegd worden wie het aanspreekpunt is voor de dienst en hoe ze bereikt kunnen worden

Werner Boldewijn / Richard Snijders / 1-jan-09 Erik Nederlof / Cees Horvers

31-mar-10 routine, Continu proces

Bewaking van procesbeschrijving

Peter Nool

nnb

Is momenteel nog niet voor alle medewerker toegankelijk

Opstellen van een CRM systeem waarin de RDC beschikt te weinig over relevante gegevens en ontwikkelingen van zowel de 4.4 marktgegevens (van klanten en van klanten als de concurrenten worden concurrenten) bijgehouden en voor alle medewerkers toegankelijk is

1-dec-09

Status


HTS Autotechniek 45

Knelpunt

Acties

Wie (vervanger)

KPI WW-beheer SLA

Onduidelijkheid over 5.1 verantwoordelijkheden door overlap tussen afdelingen

Directie / Werner Per afdeling SMART geformuleerde KPI Boldewijn / Richard opstellen en verantwoordelijkheden (grenzen) Snijders / Erik duidelijk afbakenen Nederlof / Cees Horvers

Werkzaamheden worden onnodig 5.2 uitgesteld doordat er een te lage prioriteit aan wordt toegekend.

Per afdeling SMART geformuleerde doelen opstellen (KPI)

Werner Boldewijn

Het management beschikt niet over 5.3 duidelijke rapportages over behaalde resultaten (icm doelen)

Maandelijkse rapportages (per afdeling) aan het management over de behaalde resultaten, de genomen acties en een verantwoording ervan. Het management kan aan de hand hiervan acties ondernemen

FZ moet gegevens aanvullen die MV kunnen verwerken in de rapportage

Het komt erg vaak voor dat de eindegebruikers niet kunnen inloggen bij RDC. Gebruikersnaam en 6.1 wachtwoord matchen niet meer, hierdoor wordt veelvuldig contact opgenomen met KCC

Mogelijk maken om in te loggen op gebruikersniveau en niet meer op klantniveau. Ieder bedrijf kan meerdere personen een eigen gebruikersnaam en wachtwoord geven, Hugo Weijers kans op wachtwoord vergeten of veranderd door iemand anders wordt hierdoor geminimaliseerd.

Het algemene verwachtingspatroon van de softwareleveranciers komt 7.1 niet overeen met de prestaties die RDC op dit moment kan leveren

SLA opstellen voor SWL zodat voor beide partijen duidelijk is wat ze van elkaar kunnen verwachten

Door de ervaring uit het verleden is het vertrouwen van de 7.2 softwareleverancier in RDC minder geworden

Meer de samenwerking met SWL opzoeken, dit kan bijvoorbeeld door middel van een SLA (actiepunt 7.1), betere communicatie, meetings enz

Actie ingezet

Actie voltooid

Opmerking

8-dec-09

1-mrt-10

De managers moeten de grenzen tussen afdelingen beter toelichten op de werkvloer Projecten afronden voordat er wordt gestart aan een nieuw project

1-dec-09

31-mrt-10

Wachtwoordbeheer wordt budgetaanvraag voor gedaan

Werner Boldewijn

Aanbeveling voor de toekomst, zodra organisatiestructuur op orde is (BSM roadmap incl productportfolio)

Werner Boldewijn

Aanbeveling voor de toekomst, zodra organisatiestructuur op orde is (BSM roadmap incl productportfolio)

Status


HTS Autotechniek 46

BIJLAGEN AFSTUDEEROPDRACHT 2009

Recommend Documents