Onderzoeksrapport. Beheer wijzigingsproces. Auteurs Tim Lansbergen Jan Los Richard Lagewaard Ruben van der Tas Datum Versie: 1

Onderzoeksrapport Versie: 1.0

Auteurs

Datum

Tim Lansbergen Jan Los Richard Lagewaard Ruben van der Tas 11-4-2012

Beheer wijzigingsproces

Onderzoeksrapport Versie 1.0

Voorwoord Op de Hogeschool Rotterdam vindt in het 2e jaar van de opleiding Bedrijfskundige Informatica (of tegenwoordig vaker gebruikt: Business, IT & Management) project 7/8 plaats. Tijdens dit project plegen wij onderzoek op de ICT-afdeling van het bedrijf B&S in Dordrecht. Het onderzoek heeft betrekking op het proces voor verwerking van wijzigingsverzoeken (Request For Change, of RFC) en wij zullen aan de hand van dit onderzoek een adviesrapport opstellen. Onze opdrachtgever is de heer T. Vennema en begeleider de heer R. van Loo van het bedrijf B&S in Dordrecht. Gelegen aan de Rijksstraatweg 7 en het telefoonnummer is 078-6534100. Aan het begin van het project was M. Er de begeleider vanuit Hogeschool Rotterdam, dit is later overgenomen door de heer E. Monteiro. Deze personen zullen uiteindelijk het onderzoeks- en adviesrapport gaan keuren en hier een oordeel over geven. De projectgroep bestaat uit de volgende personen: Tim Lansbergen (projectleider) Ruben van der Tas Jan Los Richard Lagewaard Het wordt vanuit meerdere oogpunten bekeken om een zo goed en efficiënt mogelijk advies te kunnen aanbieden. Dordrecht, 12 april 2012 Tim Lansbergen, Ruben van der Tas, Jan Los, Richard Lagewaard.

2


Samenvatting onderzoeksrapport Inhoud Het is van belang voor de organisatie dat het informatiesysteem goed functioneert en dat alle gebruikers hierover tevreden zijn. Mocht een persoon niet tevreden zijn of mocht er sprake zijn van een wetswijziging, nieuwe business of optimalisatie dan kan er een wijzigingsverzoek (Request For Change of RFC) worden ingediend bij een ICT-medewerker. Dit verzoek wordt allereerst geregistreerd en geprioriteerd. Vervolgens wordt het gecommuniceerd met andere belanghebbende partijen en wordt de wijziging uitgewerkt, getest en indien het goed functioneert geïmplementeerd in het draaiende systeem en afgerond. Knelpunten In dit proces van verwerken van wijzigingsverzoeken zijn de volgende knelpunten gevonden welke in dit onderzoeksrapport verder zullen worden uitgewerkt; -

Blauwdrukken Als een wijzigingsverzoek binnenkomt, moet de programmeur een blauwdruk maken. Hij moet hierbij rekening houden met o.a. de business configuratie en dan de blauwdruk uitwerken. In het geval van Impuls is er maar één programmeur beschikbaar, het is vanzelfsprekend minder efficiënt om de programmeur de blauwdrukken te laten maken aangezien hij al erg veel tijd kwijt is aan het uitwerken van de wijzigingen.

-

Meldingen blijven te lang in de wachtrij staan Er is niet genoeg tijd beschikbaar om alle wijzigingsverzoeken te kunnen voltooien. Alleen wijzigingen die verplicht zijn en met hoge prioriteit worden behandeld. Hierdoor blijven verzoeken met een lagere prioriteit staan

-

Communicatie met Delfzijl wat betreft integratie database B&S kent twee vestigingen, namelijk een in Dordrecht en een in Delfzijl. Deze vestigingen gebruiken ieder een ander systeem voor het behandelen van wijzigingsverzoeken. Mocht zich een wetswijziging voordoen dan moet dit verplicht worden behandeld. Doordat er twee verschillende systemen in gebruik zijn wordt dit in dit geval dubbel gedaan.

3


Inhoud 1.

Inleiding ........................................................................................................................................... 5

2.

Functieprofiel .................................................................................................................................. 6

3.

Huidig proces RFC ............................................................................................................................ 7

4.

Knelpunten .................................................................................................................................... 10 4.1

Overzicht knelpunten ............................................................................................................ 10

4.2

Blauwdrukken........................................................................................................................ 11

4.3

Wachtrij en prioritering ......................................................................................................... 14

4.3.1 Voorbeelden wijzigingen ...................................................................................................... 14 4.3.2 Overzicht statussen .............................................................................................................. 16 4.4 5.

Financiële toelichting ............................................................................................................ 17

Conclusie ....................................................................................................................................... 17

Literatuurlijst ......................................................................................................................................... 20 Bijlagen ............................................................................................. Fout! Bladwijzer niet gedefinieerd.

4


1. Inleiding In dit onderzoeksrapport zal een analyse beschreven worden naar het proces van verwerking van de wijzigingsverzoeken (vanaf hier genoemd als: RFC (Request For Change)). Eerst zal een probleemanalyse worden gedaan, doormiddel hiervan kunnen knelpunten in het proces benoemd en uitgewerkt worden. De onderzoeksvraag luidt dan ook: “Welke knelpunten doen zich voor in proces van verwerking van de wijzigingsverzoeken?” Het doel van dit rapport is het neerzetten waar de problemen zich bevinden en wat deze inhouden, zodat een goed overzicht kan worden verkregen in de knelpunten. Door middel van gesprekken/interviews met stakeholders kan informatie gewonnen worden over de problemen, zowel in de vorm van digitale documenten als de woorden van de personen. Ook is de officiële website van B&S gebruikt voor het verkrijgen van informatie. Het onderzoek wordt voornamelijk gepleegd op de ICT-afdeling van B&S in Dordrecht. De hierboven uitgelegde onderzoeksmethode is de meest aangewezen methode omdat er veel gebruik is gemaakt van de interne werknemers van B&S. Hieronder staat een overzicht met wat er per hoofdstuk te verwachten is: - Huidig proces RFC; In dit hoofdstuk zal het huidige proces worden beschreven van het binnenkomen van een RFC tot het implementeren van de wijziging. - Knelpunten/procesproblemen; Hierin worden de knelpunten beschreven binnen het huidig proces. - Onderzoeksresultaten; In dit hoofdstuk zullen de resultaten aan de hand van het onderzoek worden uitgelegd. - Conclusie; Hier zal een samenvatting van de knelpunten gegeven worden. Het uiteindelijke rapport is bestemd voor B&S Dordrecht.

5


2. Functieprofiel Gebruikersorganisatie Deze partij bevat alle medewerkers die gebruik maken van de systemen Codeless en Impuls Unix. Zij werken elke dag met deze systemen en zien wat er verbeterd kan worden aan het systeem. Als een gebruiker een fout ontdekt of een wijziging wil doorvoeren in het systeem, geven zij dit door aan de ICT medewerker. Het is belangrijk dat gebruikers aangeven wat er beter kan in het systeem, want daardoor zal de kwaliteit van het systeem blijven verbeteren. ICT medewerker De volgende partij is het proces is de ICT medewerker. De ICT medewerker registreert de melding die gemaakt is door de gebruiker. Deze meldingen worden daarna doorgestuurd naar de wijzigingsbeheerder. Ook voert de ICT medewerker tests uit om te controleren of de fouten zijn gecorrigeerd en of de wijzigingen zijn doorgevoerd. Wijzigingsbeheer Het wijzigingsbeheer houdt het verloop van alle wijzigingen bij. Er wordt een planning gemaakt voor het uitwerken van de RFC. Dit wordt gedaan door middel van ranking. Hoe hoger de prioriteit, hoe eerder de wijziging doorgevoerd moet worden Leverancier De leverancier werkt de meldingen uit die worden doorgegeven door het wijzigingsbeheer. Als de wijziging is uitgewerkt, stuurt de leverancier de wijziging terug naar het wijzigingsbeheer. Ook installeert de leverancier de nieuwe wijziging en worden er tests opgesteld voor de ICT medewerker en de gebruiker. Als de resultaten van de tests positief zijn, installeert de leverancier de wijziging op de gehele gebruikersomgeving.

6


3. Huidig proces RFC Algemeen De beschrijving van het huidige proces zal worden ingedeeld in fasen. Elke fase zal een omschrijving bevatten met de betrokken partijen. Uiteindelijk zal doormiddel van een basisstroomdiagram alles in samenvatting worden uitgelegd. Fase 1: Communiceren gewenste wijziging Betrokken partijen: - Gebruikersorganisatie - ICT-medewerker Een medewerker van de gebruikersorganisatie wil dat er een wijziging wordt doorgevoerd in het systeem Codeless of Impuls Unix. De medewerker van de gebruikersorganisatie communiceert de gewenste wijziging door aan een ICT-medewerker. De ICT-medeweker registreert een melding in een acces-database. De melding omvat een omschrijving en een prioritering. Fase 2: Uitwerken van de wijziging Betrokken partijen: - Wijzigingsbeheer - Leverancier Voordat de leverancier kan beginnen met het uitwerken van de melding moet er eerst een planning worden gemaakt. Aan de hand van deze planning wordt er elke week bepaald, welke wijzigingen door worden gegeven aan de leverancier. De melding wordt ingepland en wordt uiteindelijk uitgewerkt door de leverancier. Wijzigingsbeheer moet nu de melding gaan inplannen voor het realiseren van de wijziging in Codeless of Impuls om het te testen. De leverancier zorgt ervoor dat gemaakte wijziging ook wordt doorgevoerd in het systeem Codeless of Impuls om te gaan testen. Fase 3: Testen van de wijziging Betrokken partijen: - Leverancier - ICT-medewerker - Gebruikersorganisatie De leverancier heeft zoals hierboven vermeld de wijziging doorgevoerd in het systeem om te gaan testen. De ICT-medewerker gaat de eerste test uitvoeren. De gebruikerstest wordt door zowel de ICT-medewerker als een medewerker van de gebruikersorganisatie uitgevoerd. Aan de hand van de testresultaten wordt er gezamenlijk een conclusie getrokken of het een succesvolle test betreft of niet. Als dit niet het geval is dan wordt feedback gegeven aan de programmeur en pakt hij het onder hetzelfde meldingsnummer weer op. Als de test wel succesvol wordt bevonden dan kan de wijziging worden geïnstalleerd.

7

Onderzoeksrapport Versie 1.0 Fase 4: Afronden van de wijziging Betrokken partijen: - Leverancier - Wijzigingsbeheer - Gebruikersorganisatie De wijziging is geïnstalleerd door de leverancier. Wijzigingsbeheer voert nog één keer een navraag uit over de wijziging. Dit doet hij natuurlijk aan de gebruikersorganisatie. Zij kunnen akkoord gaan met de wijziging of het afwijzen. In geval van afwijzen wordt er opnieuw melding geregistreerd en begint het proces opnieuw. Als er akkoord wordt gegaan met wijziging dan kan wijzigingsbeheer de wijziging afhandelen. Het proces is nu klaar. Op de volgende pagina is het proces uitgebeeld.

8


9


4. Knelpunten 4.1

Overzicht knelpunten

Hieronder zullen de knelpunten in het proces beknopt worden beschreven. In het hoofdstuk “Oplossingen voor knelpunten” worden de mogelijke oplossingen voor deze punten beschreven. 1. Blauwdrukken worden niet uitgewerkt op papier De gebruiker van het systeem ontdekt dat er een wijziging doorgevoerd moet worden. Hij communiceert dit door met een ICT medewerker en hij maakt hier melding van. Deze melding wordt doorgestuurd naar de wijzigingsbeheerder. De wijzigingsbeheerder stuurt dit vervolgens door naar de programmeur. Bij deze melding voegt de gebruiker een beschrijving toe, waarin staat wat er veranderd moet worden en hoe dit eruit zou moeten komen te zien. Deze beschrijving is zeer gering, dus de programmeur moet zelf de blauwdrukken maken voor de wijziging. Omdat er maar 1 programmeur is, heeft deze veel werk te doen. Hij moet zelf blauwdrukken maken, rekening houden met de business configuratie en vervolgens deze blauwdruk uit gaan werken. Dit kost veel tijd en dus ook geld. Op deze manier worden blauwdrukken niet snel uitgewerkt op papier. Er is maar 1 persoon die blauwdrukken maakt, in het geval van Impuls, waardoor de blauwdrukken niet snel gerealiseerd worden.

2. Meldingen blijven te lang in de wacht rij staan Op dit moment worden alle wijzigingsverzoeken gecategoriseerd in vijf type wijzigingen. Namelijk zeer hoog, hoog, gemiddeld, laag en zeer laag. Er wordt per week een planning gemaakt door het wijzigingsbeheer voor de programmeur. In deze planning staat hoelang de programmeur de tijd heeft om een bepaalde wijziging te ontwikkelen en door te voeren.

Echter is er niet genoeg tijd beschikbaar om alle wijzigingsverzoeken in de weekplanning te stoppen, omdat de programmeur daar tijd te kort voor komt. Hierdoor worden alleen de wijzigingen die een zeer hoge prioriteit hebben behandeld en blijven de minder hoog geprioriteerde meldingen liggen.

3. Communicatie met Delfzijl wat betreft integratie databases Zowel de ICT-afdeling van Dordrecht als de ICT-afdeling van Delfzijl krijgen eigen wijzigingenverzoeken binnen. Ook lopen de bedrijfsprocessen van Dordrecht en Delfzijl nog helemaal niet gelijk. De fusie bevindt zich nog in een beginnende fase. Dordrecht maakt gebruik van een acces database en Delfzijl maakt gebruik van een Sharepoint omgeving. Dit zorgt ervoor dat wijzigingen in sommige gevallen dubbel worden uitgevoerd. Als er bijvoorbeeld een nieuwe wet wordt doorgevoerd dan zou het mogelijk moeten zijn dat een wijziging tegelijker tijd wordt doorgevoerd in Dordrecht en Delfzijl. Echter verschillen de bedrijfsprocessen tussen deze twee vestingen erg veel van elkaar door onder andere verschillende IT-systemen en bedrijfsprocessen.

10


4.2

Blauwdrukken

Voor het knelpunt ‘Blauwdrukken’ is onderzoek verricht. Er is onderzocht hoe het proces verloopt vanaf de aanvraag van een wijziging tot het moment dat de programmeur uiteindelijk gaat programmeren. Dit proces verloopt via de mail. Allereerst geeft de gebruiker aan dat er een wijziging gemaakt moet worden. Hieronder staat vermeld hoe een aanvraag eruit ziet. In dit voorbeeld gaat het om flessen wijn die nu per stuk besteld kunnen worden. Via deze wijziging moet het mogelijk zijn om de flessen wijn per x aantal stuks te kunnen bestellen.

11


Deze mail wordt gestuurd naar het wijzigingsbeheer en vervolgens wordt de programmeur ingelicht. De programmeur gaat vervolgens bepalen hoeveel tijd hij nodig heeft om de wijziging uit te werken. Dit doet hij door middel van een mail naar het wijzigingsbeheer. Hieronder volgt een voorbeeld.

Het wijzigingsbeheer registreert vervolgens het opgegeven aantal uren van de programmeur. Hierna wordt voor de programmeur een weekplanning gemaakt. Er wordt voor hem beschreven welke wijzigingen hij voor een bepaalde week moet uitvoeren, uitzoeken en uitwerken. Ook staat op deze planning welke wijzigingen hij in de testfase moet zetten en welke geïnstalleerd moeten worden.

Als de programmeur zijn werk voltooid heeft, begint de testfase. De programmeur stuurt een mail naar de gebruiker met de mededeling dat de wijziging op de testomgeving is gezet en dat de gebruiker kan gaan testen. De gebruiker kan nu gaan testen en zal de resultaten van zijn test terug mailen naar de programmeur. Als de gebruiker de wijziging heeft goedgekeurd mailt hij dit terug naar de programmeur. De programmeur kan vervolgens de wijziging op status ‘productie’ zetten en stappen zetten naar implementatie van de wijziging. Als de wijziging succesvol is geïmplementeerd, wordt de status gewijzigd naar ‘gereed’. 12


Het contact van dit proces verloopt grotendeels via mail. In het huidige proces wordt bij het aanmelden van een incident of wijziging alleen een kleine beschrijving gegeven door de gebruiker en dit wordt via wijzigingsbeheer doorgestuurd naar de programmeur. De programmeur moet aan de hand van deze kleine beschrijving bedenken en indelen hoe de wijziging eruit moet komen te zien en geprogrammeerd moet worden. Dit is een taak die standaard niet bij de functie van de programmeur hoort. Dit kost de programmeur dan ook veel tijd en moeite. Daarbij komt dan ook nog dat zo’n uitwerking niet altijd volgens wens van de gebruiker is. In veel van de gevallen bij kleinere wijzigingen wordt dit ontwerp dan ook niet op papier uitgewerkt maar heeft de programmeur deze uitwerking in het hoofd. Bij grote wijzigingen of nieuwe applicatieonderdelen wordt vaak nauw contact gehouden met de gebruiker, dit vermindert de kans dat het resultaat niet volgens wens is aanzienlijk, maar dit kost veel tijd. In de meeste organisaties zitten tussen de gebruiker en de programmeur meerdere functies. Namelijk een business analist, informatieanalist en functioneel ontwerper. De business analist en informatie analist doen aan de hand van de meldingen analyses of het wijzigingsverzoek mogelijk is, relevant is, nodig is en waar het invloed op heeft. Aan de hand van deze informatie maakt de functioneel ontwerper dan een functioneel ontwerp die voor de programmeur duidelijk laat zien wat er moet veranderen en hoe het er uit moet komen te zien.

13


4.3

Wachtrij en prioritering

In dit hoofdstuk worden de onderzoeksresultaten getoond van het knelpunt ‘meldingen blijven te lang in de wachtrij staan’. Er wordt begonnen met een kleine toelichting van het knelpunt waarna er twee wijzigingen worden toegelicht die het probleem goed uitlichten. Als laatste wordt er een overzicht gegeven van alle wijzigingen met hun status. Dit geeft namelijk een goed overzicht van probleem. Bij de gebruikersorganisatie ontstaat in de meeste gevallen de wens voor een wijzig. Er wordt dan een wijzigingsverzoek gemaild naar ‘wijzigingsbeheer’. Hier wordt dit verzoek dan geregistreerd en geprioriteerd. Hierna wordt dit verzoek doorgestuurd naar de programmeur welke hiervoor zijn tijdsbepaling terugstuurt naar wijzigingsbeheer. Hier wordt dan de planning gemaakt. Het probleem is echter dat er te weinig capaciteit beschikbaar is om alle wijzigingen uit te werken. Hierdoor worden wijzigingsverzoeken steeds verschoven en blijven ze in de planning staan. Hieronder staan twee voorbeelden van meldingen die niet afgehandeld zijn. 4.3.1 Voorbeelden wijzigingen Wijziging ‘2213’ Wijzigingsnummer 2213 is gemeld op 22-12-2010. Echter staat de status van deze wijziging nog steeds op ‘opdracht begroot’. Dit komt doordat onderstaande melding 2213 teveel tijd in beslag nemen om het te programmeren. De wijziging is aangevraagd door Rick van Loo. De wijziging is niet noodzakelijk. De wijziging zorgt er namelijk voor dat er efficiënter gewerkt kan worden door voorraad en barcodes in één keer van het ene naar het andere productnummer over te zetten. De programmeur heeft deze wijziging naast zich neer gelegd vanwege het feit dat het teveel tijd kost en niet noodzakelijk is.

14

Onderzoeksrapport Versie 1.0 Wijziging ‘2674’ Wijzigingsnummer 2674 is gemeld op 2-2-2012. De wijziging betreft een groot aantal kleine wijzigingen die in zijn totaliteit veel tijd kosten voor de programmeur om te worden uitgewerkt en gerealiseerd. Deze wijziging geeft nog maar eens goed aan dat er te weinig capaciteit aanwezig is om grote wijzigingen die veel tijd kosten te realiseren.

15

Onderzoeksrapport Versie 1.0 4.3.2 Overzicht statussen Onderstaand tabel geeft een overzicht van alle statussen die mogelijk zijn in de database van het wijzigingbeheer. Hierbij wordt ook vermeld hoeveel wijzigingen op een bepaalde status staan. De tabel geeft aan dat er tot nu toe(1 mei 2012) 2623 wijzigingen zijn aangevraagd. statusN 01 - Opdracht geregistreerd 04 - Opdracht verzonden 06 - Uitwerken (Impuls) 10 - Opdracht begroot 20 - Klaar om te plannen 30 - In behandeling (Impuls) 31 - In de planning (Impuls) 32 - In de planning voor begroting (Impuls) 36 - In behandeling (B&S)

Aantal StatusN Aantal 36 45 - In testfase (actie:B&S) 17 42 50 - Gereed na oplevering nieuwe client (ING) 2 25 55 - Gereed na oplevering nieuwe metadata 6 (ING) 26 60 - Workaround beschikbaar 1 5 70 - Installatie 5 6 80 - Gereed melding naar gebr, wacht op 10 akkoord 31 90 - Klaar voor archiveren 2173 7 95 - Hold 21 4 99 - Opdracht ingetrokken / geannuleerd

206

Om een beter overzicht te geven van alle wijzigingen worden ze ingedeeld in drie statussen, namelijk: - Klaar voor archiveren(2173) - Opdracht ingetrokken(206) - Overige wijzigingen(244) Alle overige wijzigingen bevatten dus een status die nog niet is afgehandeld of ingetrokken. Deze wijzigingen zijn dus nog in behandeling. Ze kunnen de status ‘opdracht geregistreerd’ tot aan ‘akkoord/handtekening ontvangen’ bevatten. Hier valt de status ‘opdracht ingetrokken’ niet onder. Dat 206 van deze wijzigingen nog niet zijn afgehandeld is een probleem voor de organisatie. Dit aantal zal alleen nog maar oplopen. Zoals al eerder in dit rapport vermeld is komt dat door capaciteitstekort aan programmeurs. De cirkel geeft nog maar eens goed aan dat het nodig is om tot een oplossing te komen voor dit probleem.

Status wijziging 206; 8%

244; 9% Klaar voor archiveren Opdracht ingetrokken 2173; 83%

Overige wijzigingen

16


4.4

Financiële toelichting

In dit hoofdstuk wordt er gekeken naar de begrote uren en de uren die werkelijk zijn besteed aan het verwerken van de wijzigingsverzoeken. Aan de uren is een modaal loon aan gekoppeld van €18,- per uur. Er is hiervoor gebruikt gemaakt van een MS Access database. In het jaar 2012 zijn van 1 januari tot 23 april 159 meldingen gedaan. Uit de database is ook informatie te halen over hoeveel tijd aan deze meldingen is besteed en hoeveel tijd is begroot. In totaal is er aan 82 meldingen tijd besteed en zijn er in totaal 30 meldingen begroot. Van de 82 meldingen waar tijd is besteed zijn er 24 begroot. Dit betekent dat er 6 meldingen begroot zijn waar nog geen tijd aan is besteed. Het aantal begrootte uren van de 6 meldingen waar nog geen tijd aan is besteed is 20. Het totaal aantal begrootte uren komt neer op 128. Dat betekent dat er voor 24 meldingen, 108 uur is begroot. De werkelijke tijd die is besteed aan de 24 begrootte meldingen is 98 uur. Het werkelijk aantal uren dat is besteed aan het verwerken van meldingen is 312. Van de 82 meldingen zijn er 32 gereed gemeld. Dit betekent dat er 32 meldingen afgerond zijn. Het totaal aantal uren dat aan deze 32 meldingen is besteed is 139,25. Van de 32 meldingen die gereed zijn gemeld waren er 13 meldingen begroot. De tijd die hiervoor was begroot is 49 uur. En de werkelijke tijd die aan die 13 meldingen is besteed is 39 uur. Dit betekent dat er 11 van de 24 begrootte meldingen nog niet gereed zijn en dat daar 59 uur voor is begroot en 59 uur aan is besteed. Overzichtelijk in een tabel:

Totaal aantal meldingen - Meldingen begroot - Meldingen behandeld o Meldingen niet begroot o Meldingen begroot o Meldingen begroot & nog niet gereed o Meldingen gereed o Meldingen gereed & begroot o Meldingen gereed & niet begroot

Aantal meldingen

Werkelijke uren

Begrootte uren

159 30 82 58 24 11

312 98 312 214 98 59

128 128 108 0 108 59

32 13 19

139,25 39 100,25

49 49 0

Uit deze gegevens is op te maken dat de persoon die de inschatting doet van benodigde uren, geen slechte schatting doet, maar er zijn teveel meldingen die niet zijn begroot maar waar wel tijd aan is besteed. Het begrootte aantal uren gekoppeld aan het modale uurloon komt neer op 128 x €18 = €2304,-. Hetgeen dat werkelijk besteed is aan het verwerken van de meldingen is 312 x €18 = €5616,-. Overzichtelijk in een tabel: Geplande uren Werkelijke uren

128 312

Uurloon

Totale kosten

€18,€18,-

€2304,€5616,-

5616 x 100 / 2304 = 243,75. Er is 243,75% meer tijd besteed aan het verwerken van de meldingen dan dat er gepland stond.

17

Onderzoeksrapport Versie 1.0 Uit het bovenstaande is duidelijk op te maken dat de programmeur te weinig tijd heeft om zich volledig te concentreren op het programmeren. Dit tekort aan tijd heeft te maken met de andere taken die van hem verwacht worden zoals het maken van een blauwdruk. Alle bovenstaande cijfers zijn uit de eerste 4 maanden van 2012. Dit betekent dat er 214 uur meer is besteed dan stond gepland. Daarnaast is nog maar een klein deel van alle meldingen gereed. Deze uren tekort blijven oplopen en er staan van voorgaand jaar ook nog meldingen open. In feite wordt de capaciteit van een fulltime werknemer gemist, die deze taken wellicht van de programmeur zou kunnen overnemen. Dit resulteert erin dat de programmeur werk uit handen wordt genomen en zo heeft die persoon meer tijd tot zijn beschikking om daadwerkelijk aan het programmeren te besteden.

18


5. Conclusie De afgelopen weken heeft de adviesgroep SITA onderzoek gepleegd naar het proces van verwerken van wijzigingsverzoeken. Doormiddel van dit onderzoek zijn de knelpunten opgesteld en hier is een uitgebreide uitleg aan gegeven. Meldingen blijven te lang in de wachtrij staan. Er zijn vijf klassen beschikbaar voor het prioriteren van de meldingen, namelijk zeer hoog, hoog, gemiddeld, laag en zeer laag. Iedere week wordt een planning gemaakt voor de programmeur door het wijzigingsbeheer. In deze planning wordt aangegeven hoeveel tijd de programmeur beschikbaar heeft om een melding te programmeren en te implementeren. Alleen meldingen met zeer hoge prioriteit of meldingen die verplicht moeten worden behandeld door bijvoorbeeld een wetswijziging worden uitgevoerd. Hierdoor worden meldingen met een lagere prioriteit niet behandeld en deze blijven in de wachtrij staan. Blauwdrukken worden niet uitgewerkt op papier. De gebruiker van het systeem maakt een melding van een wijziging die diegene vindt dat er doorgevoerd moet worden. Bij deze melding maakt de gebruiker een beschrijving, hierin staat wat er moet worden gewijzigd en hoe dit eruit moet komen te zien. Dit is echter een zeer geringe omschrijving dus de programmeur moet zelf nog gaan nadenken en blauwdrukken maken voor de wijziging. Het is de programmeur zijn taak om te programmeren, niet op blauwdrukken te maken. Het kost veel tijd en dus veel geld om de programmeur dit te laten doen en er gaat hierdoor tijd verloren die hij ook aan programmeren had kunnen besteden. De onderzoeksvraag luidde: “Welke knelpunten doen zich voor in proces van verwerking van de wijzigingsverzoeken?” Dit kan gerealiseerd worden door oplossingen door te voeren voor de bovengenoemde knelpunten.

19


Literatuurlijst Geraadpleegde schriftelijke bronnen Janssen, P. (2008), IT-service management volgens ITIL(3de druk). Amsterdam: Pearson Education. Kroenke, D. M. (2007), Databases beginselen, ontwerp en implementatie. Amsterdam: Pearson Education. Geraadpleegde digitale bronnen B&S, Dordrecht (geraadpleegd vanaf 1 maart 2012 tot 30 mei 2012); http://www.bs-gg.com/ Gertjan Schop, (geraadpleegd op 11 maart 2012); http://www.gertjanschop.com/modellen/klaverbladmodel.html Database Requests For Change, B&S, Dordrecht (geraadpleegd van 24 april 2012 tot 30 mei 2012); Fedor Wagenaar, SQL (geraadpleegd van 24 april 2012 tot 30 mei 2012); http://med.hro.nl/wagfa/BIRDTB03/DTB03_pagina.htm Mumin Er, Modulewijzer (geraadpleegd van 8 februari tot 30 mei 2012); Geïnterviewde personen Stefan Overman Verkregen informatie: o Meer gestructureerde communicatie tussen Codeless en B&S o Positieve reactie op het project Rik van Loo Verkregen informatie: o Voorbeeld wijziging o Voorbeeld programmeursplanning o Huidig proces o Feedback Belinda Bakker Verkregen informatie: o Database o Huidig proces

20


Bijlagen

Bijlage I Algemene informatie B&S B&S is een internationale groothandel en distributeur. Het bedrijf levert levensmiddelen (diepgevroren, gekoeld en droog), accijnsgoederen (drank, tabaksproducten en luxe consumentengoederen) en non-food (schoonmaakproducten, toiletartikelen en wegwerpproducten) aan zeer uiteenlopende markten. Naast de grote verscheidenheid aan A-merken introduceerde B&S in 2007 het huismerk GoodBurry. Dit huismerk bevat meer dan 100 producten. De producten hebben een professionele uitstraling en het biedt een uitstekende prijs-kwaliteitverhouding. Het entrepot van B&S (het B&S Global Transit Center) heeft zich gespecialiseerd in vervoer, opslag en distributie van consumentengoederen van elke plek in de wereld naar elk gewenste eindbestemming. Bij B&S Global Transit Center wordt gewerkt volgens HACCP-richtlijnen en er worden kwaliteitscontroles uitgevoerd. Het biedt opslag bij meerdere temperaturen en diverse mogelijkheden voor vervoer. Er wordt momenteel gebruik gemaakt van de meest compacte opslagmethode die beschikbaar is en dit heeft de opslagcapaciteit met 33% verhoogd. Door te investeren in nieuwe technologieën en synergievoordelen te creëren, streeft B&S Global Transit Center naar verdere optimalisering. Als groothandel en distributeur levert B&S Fast Moving Consumer Goods aan verschillende klanten in nichemarkten als scheepsleveranciers, duty-free winkels, luchtvaartmaatschappijen, cruiseschepen en militaire posities. B&S onderscheidt zich door zijn inzet en toewijding. Typerend voor dit bedrijf zijn de betrouwbare service, waardevolle en brede kennis en bovenal de beste prijs. Hierdoor kan B&S iedere uithoek van de wereld bereiken. Het hoofdkantoor staat slechts 20 kilometer van de haven van Rotterdam, een knooppunt van kennis en state-of-the-art faciliteiten. De twee belangrijkste succesfactoren zijn de omvang van het bedrijf en de diversificatie. Door de grote diversiteit in producten die geleverd worden is de klantenkring van B&S erg groot.

21


Geschiedenis Het fundament van het succes van B&S komt voort uit een 140 jaar lange ervaring. Drie afzonderlijke organisaties die werkzaam waren in verschillende nichemarkten zijn samengesmolten tot wat nu B&S is. Deze fusie die in 2001 plaatsvond zorgde voor indrukwekkende schaalvoordelen en betekende de start van het “one-source-supply” concept. Afzonderlijke organisaties hebben met hun kennis en netwerken B&S verder uitgebreid en versterkt. Köpcke, 1872: Voormalig scheepskapitein August Köpcke start met het leveren van producten aan schepen als scheepsleverancier. Bosman, 1912: Meneer Bosman start met het leveren van zuivelproducten aan de detailhandel. Vervolgens breidt hij deze handel uit door levensmiddelen te verkopen aan scheepsleveranciers. Paul, 1948: Meneer Paul opent een duty-free handel in de haven van Rotterdam – dit maakt het voor scheepslieden mogelijk om belastingvrij sterke drank en sigaretten te kopen. B&S, 2001: Met een drievoudig netwerk, faciliteiten en expertise in huis, is er een nieuwe en veel sterkere entiteit gecreëerd: B&S.

Identiteit B&S heeft een aantal fundamentele kenmerken opgesteld waarvan het bedrijf zegt dat dit de identiteit bepaald, namelijk de volgende: Betrouwbaar: Klanten kunnen te allen tijde rekenen op een hoogwaardige kwaliteit en dienstverlening. Uniek:

B&S is uniek in zijn benadering van de markt. Door de diversificatie loopt B&S minder risico voor economische veranderingen.

Flexibel:

B&S biedt ondersteuning waar het kan. De klant komt altijd op de eerste plaats, ongeacht wat zijn probleem is.

Efficiënt:

B&S hanteert een efficiënte en doelgerichte aanpak om hun motto “Get it right the first time” te kunnen waarmaken.

Professioneel:

Om de professionaliteit te kunnen waarborgen krijgt iedere medewerker een positie die aansluit op zijn of haar persoonlijke vaardigheden.

Ambitieus:

B&S trekt intelligente en ondernemende mensen aan, ze biedt de medewerkers ruimte om te groeien met het bedrijf.

Succesvol:

B&S is vooral succesvol wat betreft het inspelen op wensen van de klant. Dankzij de grote klantenkring kan B&S kortingen geven op bestellingen met grote volumen, hier profiteert iedereen weer van. 22


Missie en visie

Missie:

“B&S aims to be the preferred partner for all niche markets around the globe that need consumer goods delivered at the right time to the right place.”

Vertaald:

B&S heeft als doel om de nummer één partner te zijn voor alle niche markten over de wereld die consumenten goederen nodig hebben op het juiste moment en de juiste plaats.

Visie:

“Our vision is to be the leader in the consumer goods wholesale industry. We strive continuously to strengthen our assortment, operations management and delivery ability.”

Vertaald:

Onze visie is om de leider te zijn in de industrie van consumenten goederen verkoop. We streven continu naar verbetering in ons assortiment, operations management en de mogelijkheid tot leveren.

23


Bijlage II Klaverblad model

Het klavermodel schetst de vier inrichtingselementen van een organisatie die met elkaar in evenwicht moeten zijn om gewenste resultaten op korte en lange termijn te bereiken. In dit model worden organisaties beschouwd als een systeem waarbij invoer wordt omgezet in output (producten of diensten) ten behoeve van klanten of afnemers. Het klaverbladmodel richt zich op de organisatie-inrichting. Het inrichtingselement processen Producten of diensten die geleverd worden aan klanten zijn de uitkomst van processen die plaatsvinden in de organisatie. De producten, diensten en de onderliggende processen geven invulling aan het bestaansrecht van een organisatie. De organisatie die deze producten en diensten tegen een voor klanten aanvaardbare prijs en kwaliteit kan aanbieden, verwerft bestaansrecht.

24

Onderzoeksrapport Versie 1.0 We onderscheiden drie typen processen: standaard, samengestelde en maatwerkprocessen (Hartog, Molenkamp en Otten, 1998). Standaard processen worden gekenmerkt door een eenduidig product en een routinematige procesgang. Deze processen kennen één standaard procesgang. Een samengesteld proces levert producten met een beperkte en vooraf gedefinieerde variatie, die tot stand komt door vooraf gedefinieerde keuzemomenten in de procesgang. Maatwerkprocessen leveren een breed productassortiment, waarbij de procesgang grotendeels, zo niet volledig, wordt bepaald door klantspecificaties. Voor het inrichten van toekomstrobuuste processen is deze opsplitsing belangrijk. Een organisatie moet in staat zijn om voor de korte termijn haar klanten een product/dienst te leveren waarmee ze concurrerend kan zijn ten opzichte van concurrenten. Als de klantenwensen stabiel zijn, dan volstaat uitsluitend een organisatie met daarin zoveel mogelijk ‘gestandaardiseerde processen’. Als de klantwensen (binnen bandbreedtes) wijzigen en op maat voor klant(groep)en moeten worden aangepast, dan moet worden gezocht naar maatwerkmogelijkheden (combinaties van gestandaardiseerde halffabricaten). Er ontstaat dan meer ‘flexibiliteit’ om productvarianten voort te brengen (samengestelde processen). Als blijkt dat de omgeving veel dynamischer en minder voorspelbaar is, dan zullen maatwerkprocessen een veel dominantere plaats hebben binnen de organisatie. Daarmee kan snel worden ingespeeld op nieuwe ontwikkelingen. De processen van een organisatie worden toekomstrobuuster ingericht als er minder wordt gestreefd naar standaardisatie. Praktisch betekent dit bijvoorbeeld dat managers meer sturen op outputspecificaties en minder op detail (werkinstructies). Dit geeft medewerkers zelf continu de mogelijkheid om het operationele proces te organiseren en bij te sturen als dat nodig is. Een tweede mogelijkheid is om de processen te beschouwen als ‘legostenen’. Ieder proces bestaat uit ‘subprocessen’ of ‘activiteiten’. De inhoud van deze subprocessen is vooraf goed gedefinieerd en de input voor en de output van deze subprocessen zijn gedetailleerd omschreven. Nu wordt het mogelijk om het proces snel aan te passen, door de subprocessen ten opzichte van elkaar te verschuiven. Dit fenomeen wordt ook wel business process management (BPM) genoemd. Ook kunnen de processen losser gemaakt worden van de onderliggende geautomatiseerde systemen, bijvoorbeeld door handmatige activiteiten uit te voeren (niet alles werkt geautomatiseerd beter) of door de proceslogica te scheiden van de software. Processen en ICT zijn dan snel aanpasbaar. Ook belangrijk in dit kader is het vrijmaken van tijd en geld voor kennisdeling (van vaak ongestructureerde kennis) tussen medewerkers, zodat zij ervaringen van elkaar kunnen uitwisselen en hergebruiken en er een gericht leerproces in de organisatie ontstaat. Het inrichtingselement personeel & cultuur In de klassieke Tayloriaanse manier van kijken naar personeel gaat het om arbeidsdeling, taken, bevoegdheden en verantwoordelijkheden van medewerkers. Deze aspecten krijgen invulling door functiebeschrijvingen op te stellen en procedures te schrijven in aansluiting op de administratieve organisatie. Deze technisch-inhoudelijke kant is maar één kant van de organisatie-inrichting. De andere (zachte) kant van organisatie-inrichting is de organisatiecultuur. De cultuur omvat de waarden en normen die worden gehanteerd; ze komen tot uitdrukking in de stijl van leidinggeven, de capaciteiten en vaardigheden van de medewerkers, de vormgeving van de onderlinge communicatie 25

Onderzoeksrapport Versie 1.0 en dergelijke. Enerzijds stelt de organisatie eisen in termen van kennis, vaardigheden en (kwantitatieve) beschikbaarheid. Anderzijds stellen de medewerkers zelf ook eisen in termen van zinvol, verantwoordelijk en aantrekkelijk werk en opleiding en ontwikkelingsmogelijkheden. Als je een proces gaat herontwerpen dan is het de vraag of de taken die worden gedefinieerd nog aansluiten bij de eisen van de medewerkers. Er zijn immers meerdere soorten medewerkers. We onderscheiden in dit artikel generalisten en specialisten. Generalisten overzien het hele proces en voeren liever alle activiteiten uit voor één (eind)product dan zich te specialiseren in één of een aantal activiteiten. Specialisten richten zich liever op één of een aantal taken en voeren die zeer goed uit. Tegenwoordig wordt in organisaties vaak uitgegaan van de individuele verantwoordelijkheden zelfsturing van de mens binnen een organisatie. Een voorbeeld van toekomstrobuuster worden op dit gebied is het organiseren van klant(groep)teams van generalisten en specialisten die continu samenwerken, wat zorgt voor een cultuur die zich volledig en flexibel aansluit op de wijzigende behoeften van de klant. Omdat de verdeling tussen generalisten en specialisten door nieuwe werken organisatievormen niet meer gelijk loopt met de hiërarchische taakverdeling, zijn generalisten niet meer automatisch synoniem met managers. Het inschakelen van meer (hoogopgeleide) generalisten in de processen van de organisatie zorgt ervoor dat de inhoud van werkzaamheden snel kan veranderen als de omgeving dat vereist. Deze medewerkers kunnen zich snel in een nieuw onderwerp inwerken. Volberda en Van den Bosch (2005) maken hierbij voor managers een onderscheid tussen gespecialiseerde routines en dynamische vaardigheden. Deze laatste vragen van managers en medewerkers een brede en diepe kennisbasis, een hoog absorptievermogen, brede denkkaders en veel experimenteerdrift en hogere-ordeleren. Met de mens als zelfsturend onderdeel van de organisatie wordt het mogelijk om te streven naar continue ontwikkeling en verbetering van de prestaties van een organisatie. Naast de mogelijkheid om top-down vernieuwingen en verbeteringen door te voeren geeft dit namelijk de mogelijkheid om de medewerkers bottom-up veranderingen te laten initiëren, te laten uitwerken en te implementeren. Belangrijke voorwaarden voor het ontstaan van synergie tussen deze organisatieveranderingen zijn vaak een gezamenlijk gedragen visie en krachtig leiderschap om de veranderingen op elkaar af te stemmen. Volberda en Van den Bosch (2005) onderscheiden voor innovatie in organisaties dan naast crosshiërarchische vaardigheden door verticaal management ook het ontwikkelen van crossfunctionele vaardigheden door horizontaal management (bijvoorbeeld voor kennisuitwisseling) en crossculturele vaardigheden door ideologisch management. Het inrichtingselement informatietechnologie Informatietechnologie moet vooral de benodigde flexibiliteit van processen ondersteunen. Zo worden samengestelde processen idealiter ondersteund door gebruikersvriendelijke en snel aanpasbare ICT-toepassingen (bij voorkeur aan te passen door een gebruiker of productmanager zelf), die op pc’s of via netwerken aan de gebruiker ter beschikking worden gesteld. Standaardprocessen worden idealiter ondersteund door (grootschalige) ICT-toepassingen. Deze typische backofficeprocessen worden zo veel mogelijk geautomatiseerd uitgevoerd. Deze toepassingen zijn en worden ontwikkeld volgens grootschalige en gefaseerde systeemontwikkelingsmethoden. Op plaatsen in de organisatie waar de kennis van de organisatie wordt beheerd en waar snel en flexibel moet kunnen worden ingespeeld op nieuwe ontwikkelingen, moet ICT flexibel en snel 26

Onderzoeksrapport Versie 1.0 aanpasbaar zijn. Dit speelt vaak een rol in mid-offices of innovation offices, waar de frontofficetechnologie moet worden gekoppeld aan de backofficetechnologie. We noemen deze koppeling in een technisch mid-office ook wel Enterprise Applicatie Integratie (EAI). EAI is een filosofie, een soort architectuur, waarmee applicatie-integratie nu en in de toekomst wordt vereenvoudigd, min of meer onafhankelijk van de specifieke applicatie. Vandaar de term Integratie Architectuur, die je bij EAI vaak tegenkomt. Onder druk van de behoefte om functionaliteit te integreren verschuift de focus; de nadruk komt meer op de lijmlaag tussen de componenten te liggen dan op de componenten zelf. Dit geldt voor alle lagen van de architectuur: van informatie tot technische infrastructuur. Een toekomst robuustere ICT-architectuur maakt dan ook gebruik van in recente perioden ontwikkelde ICT-elementen die hieraan tegemoetkomen. Bijvoorbeeld platforms die infrastructuurcomponenten integreren op basis van modulaire systemen, die ook eenvoudig weer ontvlochten kunnen worden. Ook het gebruik van open standaarden voor gegevensuitwisseling maakt ICT toekomstrobuuster. Immers, hiermee kan ICT-functionaliteit snel worden aangesloten op andere functionaliteiten of data, op basis van de afgesproken uitwisselingsstandaard. Dit geldt zowel binnen als buiten de organisatie. Het inrichtingselement beheersing Het traditionele antwoord op prikkels uit de omgeving is de organisatiestructuur, als ultieme ‘gestolde’ vorm van toegepaste besturingsprincipes die processen, personeel & cultuur en ICT dienen te beheersen. Hieronder bespreken we kort een aantal organisatiemodellen in relatie tot de toekomstrobuustheid binnen een organisatiestructuur. Functionele organisatiestructuur In deze organisatiestructuur worden taken verdeeld op basis van de aard van de activiteiten, ofwel de fase van bewerking. De natuurlijke samenhang tussen de opeenvolgende activiteiten wordt daarbij verbroken. In deze vorm zijn een hoge bezettingsgraad en schaalvoordelen mogelijk. Besluitvorming vindt bijna altijd centraal plaats en de medewerkers hebben een hoge inhoudelijke deskundigheid. Het risico voor toekomstrobuustheid zit in de ‘competentievalkuil’ van ingesleten routines en vaste investeringen en in de traagheid van besluitvorming over organisatiebrede vernieuwing. Product (of geografische of markt)-structuur In deze organisatiestructuur zijn de activiteiten verdeeld op basis van de producten. Alle activiteiten die moeten worden verricht voor een product(groep) worden hierbij samengevoegd. Er is een grote klantgerichtheid met veel decentrale besluitvorming, maar de bezettingsgraad en schaalvoordelen zijn relatief laag. Medewerkers hebben veelal een lage inhoudelijke deskundigheid. Het belangrijkste risico voor toekomstrobuustheid zit in een maatwerkoplossing voor klantvragen, die ook (grotendeels) standaard en goedkoper had kunnen zijn. Matrixorganisatie Het idee van de matrixorganisatiestructuur is dat de kennis van de organisatie zoveel mogelijk wordt geborgd en anderzijds dat de matrixorganisatie snel kan inspelen op nieuwe ontwikkelingen en deze 27

Onderzoeksrapport Versie 1.0 snel kan implementeren in de organisatie. Deze structuur verenigt de verticale functionele indeling met een horizontale productstructuur. Deze structuur wordt wel toegepast in organisatieonderdelen waar veelal projectmatig wordt gewerkt, zoals in research- en developmentomgevingen. In horizontale richting wordt gewerkt aan producten of markten. De verticale richting levert de expertise vanuit verschillende disciplines. Het risico voor toekomstrobuustheid zit in de interne gerichtheid. De medewerkers in de organisatie hebben namelijk te maken met twee bazen, een vakinhoudelijke en een projectbaas. De organisatie zelf brengt inefficiency met zich mee omdat er veel afhankelijkheden worden gecreëerd. Hierdoor ontstaan veel informele verticale en horizontale afstemmingen over zowel huidige prestaties als over verandering. Frontoffice-, innovation office- en backofficemodel In figuur 6 worden het frontoffice, de backoffice en de innovation office naast elkaar geschetst in een ‘organisatiehuis’. Het frontoffice is vaak ingericht naar klantgroepen of producten en het doel is om via één kanaal zoveel mogelijk aan de verschillende klantwensen tegemoet te komen. Met de frontofficeprocessen moet de organisatie in staat zijn snel en flexibel in te spelen op de (veranderende) eisen en wensen van de klant. Frontofficeprocessen zijn vaak uit standaardbouwstenen samengestelde processen. In het frontoffice is sprake van zeer brede taakspecialisatie en lage formalisatie van gedrag. Om dit type structuur mogelijk te maken is een hoge graad van opleiding noodzakelijk. Het innovation office, of ook wel het mid-office, is de plaats in de organisatie waar de kennis van de organisatie wordt beheerd. Ingewikkelde vragen vanuit het frontoffice (tweedelijnsvragen) worden hier afgehandeld.. Daarnaast heeft het mid-office de taak om nieuwe ontwikkelingen of mogelijkheden snel te signaleren, te beoordelen op passendheid en risico’s en te realiseren in de bestaande organisatie. De processen hebben hier als kenmerk een hoge mate van flexibiliteit. Het backoffice voert voornamelijk standaardprocessen uit. Er is dan sprake van een relatief smalle taakspecialisatie: het betreft routinematige werkzaamheden die minder brede kennis vereisen. Taken zijn relatief eenvoudig; de beperkte mate van opleiding en training die hiervoor nodig is, is gericht op het (nog) efficiënter uitvoeren van het takenpakket. De backofficeprocessen zijn grotendeels geautomatiseerd. Recente onderzoeken laten zien dat structuur eenvoudig moet zijn (Nohria, Joyce en Roberson, 2003) en in lijn met de strategie (en omgekeerd) (Roberts, 2004). Meer toekomstrobuustheid ontstaat dan ook vooral door de organisatie te beschouwen als een doos legoblokken. Deze hoeven zeker niet elk dezelfde vorm en ook niet dezelfde besturing te kennen. We zien dat ook steeds vaker gebeuren in bijvoorbeeld business process outsourcing en in het vormen van shared service centers. Belangrijk is dat de structuur meebeweegt met een besturing die gericht is op de balans tussen korte en lange termijn. Bronnen: - Noordam, P, et al, Managen van toekomstrobuustheid: de paradox van besturing en beheersing, Management Executive, juli/augustus 2006 - Atos Consulting, White paper: transformaties in de verzekeringsbranche, 2007

28


Bijlage III

29


Bijlage IV

Format ‘Aanmelden Incidenten / Wijzigingen’ Versie: 0.1 Status: Concept

30


Revisies Versie 0.1

Datum 14-07-2010

Door Stefan Overman

Omschrijving Eerste opzet

31


Inhoudsopgave 1

Inleiding .......................................................................................................................................................................

2

Aanmelden Incidenten ................................................................................................................................................

3

Aanmelden Wijzigingen ...............................................................................................................................................

32


1. Inleiding Dit document beschrijft welke informatie Codeless nodig heeft om incidenten en wijzigingen te kunnen behandelen. Indien deze informatie bij de initiatie van een melding beschikbaar is, dan kan er sneller en beter een inschatting gemaakt worden van de te besteden tijd. Ook zullen er achteraf minder vragen gesteld worden, waardoor de oplostijd verkort wordt. Het aanleveren van de informatie die gevraagd wordt in hoofdstuk 2 en 3 zal het proces versnellen en verbeteren. Het kan wel voorkomen dat er achteraf om extra informatie gevraagd wordt, met name bij grote wijzigingen kan dit voorkomen. Dit document is opgesteld met de visie op Codeless, maar kan ook gebruikt worden bij Unix meldingen.

2. Aanmelden Incidenten Een incident betreft een fout (bug) in de software. Hierbij kan gedacht worden aan foutmeldingen die getoond worden op een scherm, fouten in de software waardoor de data onjuist is en dergelijke. Om een incident goed te kunnen behandelen is de volgende informatie nodig: 1. Titel melding De titel bestaat uit een korte duidelijke omschrijving van het probleem of wijziging. 2. Reproductiestappen: Geef stap voor stap aan welke handelingen nodig zijn om tot hetzelfde resultaat te komen die in de melding beschreven wordt. 3. Verwacht resultaat: Na de reproductie stappen wordt aangegeven wat het verwachte resultaat is van de reproductiestappen. Wat zou het resultaat moeten zijn als het systeem correct werkt? 4. Daadwerkelijk resultaat: Beschrijf wat het daadwerkelijke resultaat is van de reproductiestappen. De fout wordt hier beschreven en eventueel volgt er extra uitleg over het verschil met het verwachte resultaat. 5. Ondersteunende bestanden: - Screenshots van foutmelding helpen vaak om de reproductiestappen of het resultaat te ondersteunen. - Foutmeldingen van Codeless worden in de Eventlog geregistreerd. De inhoud van deze meldingen helpt Codeless de oorzaak van het probleem te vinden. - Overige bestanden die gebruikt zijn in het proces zoals import/export bestanden. 6. Impact:

33

Onderzoeksrapport Versie 1.0 Geef aan hoe belangrijk het is om dit probleem op te lossen, dit kan aan de hand van een prioriteit. Een omschrijving van andere processen die door deze fout worden geblokkeerd, kan helpen bij de beeldvorming van de fout. Ook graag vermelden of er een workaround mogelijk is, dit kan invloed hebben op de impact.

34


3. Aanmelden Wijzigingen Een wijziging is een toevoeging of een aanpassing in de huidige functionaliteit van de software. Een wijziging is geen fout in de software, maar kan wel ontstaan uit een Incident. Bij een wijziging is de volgende informatie belangrijk: 1. Titel melding De titel bestaat uit een korte duidelijke omschrijving van het probleem of wijziging. 2. Beschrijving van gewenste functionaliteit: Wat moet de nieuwe functionaliteit doen, en welke eisen zijn hieraan verbonden. Denk hierbij aan statussen, veld controles, berekeningen e.d. 3. Invloed van en op andere processen: Welke processen worden door deze nieuwe functionaliteiten beïnvloed en andersom, welke processen hebben invloed op de nieuwe functionaliteit. 4. Locatie van nieuwe functionaliteit: Waar in het proces wordt deze functie aangesproken? 5. Data omschrijving: Welke data wordt er in de nieuwe functionaliteit gebruikt en waar komt deze vandaan (uit andere functies, zelf in te vullen door de gebruiker, velden die berekend worden). 6. Worden er ergens knoppen voor gebruikt of worden er batch verwerkingen gedaan (grote selecties). 7. Eventueel een schermprintje met daarop aangegeven waar bepaalde velden moeten komen.

35


Bijlage V Type Request For Change In dit hoofdstuk worden de soorten RFC’s toegelicht. Wetgeving Als er een wetswijziging wordt gemaakt door de overheid/regering zal het systeem hierop moeten worden aangepast. Fout Als er een fout zich in het systeem bevindt moet er een request for change worden aangevraagd. Nieuwe business Als B&S een nieuwe markt gaat betreden moet er een request for change worden aangevraagd. Optimalisatie Als B&S het systeem wil optimaliseren moet er een request for change worden aangevraagd.

36

Onderzoeksrapport. Beheer wijzigingsproces. Auteurs Tim Lansbergen Jan Los Richard Lagewaard Ruben van der Tas Datum Versie: 1

Recommend Documents