Adviesrapport. Auteurs Tim Lansbergen Jan Los Richard Lagewaard Ruben van der Tas Datum Hogeschool Rotterdam, Business, IT & Management
|
|
- Jonas Jacobs
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 Auteurs Tim Lansbergen Jan Los Richard Lagewaard Ruben van der Tas Datum Hogeschool Rotterdam, Business, IT & Management Opdrachtgever: B&S Dordrecht Begeleider B&S: Rik van Loo Begeleider school: Ed Monteiro Beheer wijzigingsproces Dordrecht, juni 2012
2 Voorwoord Op de Hogeschool Rotterdam vindt in het 2e jaar van de opleiding Bedrijfskundige Informatica (of tegenwoordig: Business, IT & Management) project 7/8 plaats. Tijdens dit project plegen wij onderzoek op de ICT-afdeling van het bedrijf B&S in Dordrecht. Dit adviesrapport is geschreven als projectopdracht. De aanleiding van dit project is het feit dat het proces voor verwerking van wijzigingsverzoeken (Request For Change, of RFC) niet vlekkeloos verloopt. Wij zullen aan de hand van een onderzoek een adviesrapport opstellen Onze opdrachtgever is de heer T. Vennema en begeleider de heer R. van Loo. De begeleider vanuit Hogeschool Rotterdam was de heer M. Er en is vervangen door de heer E. Monteiro. Deze personen zullen uiteindelijk het onderzoeks- en adviesrapport gaan keuren en hier een oordeel over geven. Wij willen R. van Loo en E. Monteiro expliciet bedanken voor hun ondersteuning en begeleiding De projectgroep wordt geleid door Tim Lansbergen. Ruben van der Tas is verantwoordelijk voor het projectdossier, Jan Los is proces- en financieel deskundige en Richard Lagewaard zorgt voor allround ondersteuning. De keuze is gevallen op B&S Dordrecht omdat B&S deskundige werknemers in dienst heeft die geïnteresseerd zijn in onze opdracht en daarbij ook een steentje hebben bijgedragen. Wij proberen de zaak vanuit verschillende oogpunten te bekijken 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
3 Managementsamenvatting Projectgroep SITA heeft voor B&S een onderzoeksrapport opgesteld waarin onderzoek werd gedaan naar het proces van het verwerken van een wijzigingsverzoek. Er werden 3 knelpunten gevonden. Deze knelpunten waren: Blauwdrukken komen niet op papier te staan` Meldingen blijven te lang in de wachtrij staan Communicatie met Delfzijl wat betreft integratie database Voor deze knelpunten zijn de volgende oplossingen bedacht: - Blauwdrukken Voor het knelpunt van de blauwdrukken adviseert SITA om het werk van de programmeur te verminderen en over te dragen aan andere partijen. In het nieuwe proces komt een functioneel ontwerper die voor elk wijzigingsvoorstel een analyse gaat uitvoeren. Uit een informatie- en business analyse wordt een functioneel ontwerp gemaakt. Dit ontwerp gebruikt de programmeur om de wijziging te programmeren. - Meldingen blijven lang in de wachtrij staan Er bestaan meldingen die al een aantal jaar in de wachtrij staan, daardoor zullen deze meldingen mogelijk niet meer relevant zijn en zullen wellicht niet meer worden behandeld. Door het maken van een functioneel ontwerp voor een wijzigingsvoorstel, bespaart dit de programmeur tijd. Deze extra tijd kan de programmeur gebruiken om meer wijzigingen te programmeren. Hierdoor zal de wachtrij voor wijzigingen reduceren en kunnen er meer wijzigingen worden doorgevoerd. Andere oplossingen zijn dat een wijzigingsformulier voortaan gestructureerd is. Een gebruiker kan een formulier invullen, zodat duidelijker wordt omschreven wat de gebruiker wil met de wijziging. Ook wordt een wijziging voortaan geïmplementeerd door de ICT medewerker. Dit scheelt de programmeur tijd die hij nodig heeft voor het programmeren van de wijziging. Als laatste oplossing wordt het proces aangepast. De functioneel ontwerper maakt bij zijn ontwerp een testplan. Aan de hand van dit testplan kan de programmeur beter de geprogrammeerde wijziging testen en controleren of het voldoet aan de gestelde eisen. - Integratie met Delfzijl Na onderzoek is gebleken dat B&S locatie Dordrecht weinig integratie heeft met de werkzaamheden binnen Holland Trading Group Delfzijl. Hierdoor is het niet mogelijk ons advies door te voeren op locatie Delfzijl. 3
4 Inhoud 1. Inleiding Methode Leeswijzer Functieprofiel Functies Organigram Stakeholders Verbetering knelpunten Blauwdrukken worden niet uitgewerkt op papier Meldingen blijven te lang in de wachtrij staan Structureren van wijzigingsformulieren Implementeren door ICT-medewerker Testen aan de hand van testplan Integratie met Delfzijl Nieuw proces RFC Nieuw procesbeschrijving RFC Conclusie / aanbeveling Literatuurlijst
5 1. Inleiding In dit adviesrapport zal een advies geformuleerd worden voor het verbeteren van het proces van verwerking van de wijzigingsverzoeken (vanaf hier genoemd als: RFC (Request For Change)), dit wordt geschreven naar aanleiding van het onderzoeksrapport. Met behulp van de in het onderzoeksrapport beschreven knelpunten zullen verbeteringen worden geformuleerd. De onderzoeksvraag luid: Hoe kan het proces van verwerking van wijzigingsverzoeken worden geoptimaliseerd? Het doel van dit rapport is duidelijk neerzetten wat de verbeteringen inhouden en wat er moet gebeuren om de verbeteringen te kunnen implementeren. Dit moet gebeuren om een duidelijk overzicht hiervan te krijgen. 1.1 Methode Voor het maken van dit rapport hebben wij onderzoeken uitgevoerd op de ICT-afdeling van B&S Dordrecht. Door middel van de onderzoeken en interviews zijn er oplossingen gevonden voor de knelpunten die beschreven staan in het onderzoeksrapport. Er is gesproken met Belinda van het wijzigingsbeheer, Rik van het applicatiebeheer en met de programmeur. 1.2 Leeswijzer Hieronder staat een overzicht met wat er per hoofdstuk te verwachten is: - Functieprofiel; Hier wordt een overzicht gegeven van de betrokken partijen met een omschrijving van hun werkzaamheden. - Verbetering knelpunten; In dit hoofdstuk zullen de verbeteringen voor de knelpunten worden omgeschreven. - Nieuw proces RFC; Hier zal het vernieuwde proces voor het verwerken van RFC s worden uitgelegd. - Conclusie / aanbeveling; In dit hoofdstuk zal een conclusie worden gegeven in de vorm van een samenvatting van de verbeteringen en welke baten het bedrijf hierbij al hebben. Het uiteindelijke rapport is bestemd voor B&S Dordrecht. 5
6 2. Functieprofiel 2.1 Functies In dit hoofdstuk wordt een functieprofiel beschreven van alle betrokken partijen in dit proces. Er wordt toegelicht wat de taken zijn van elke functie. Gebruikersorganisatie Het functieprofiel van de gebruikersorganisatie van het nieuwe proces zal weinig verschillen met het functieprofiel van het nieuwe proces. De gebruiker voert nog steeds een gebruikerstest uit. Echter communiceert hij niet door via de mail wat er gewijzigd moet worden. De gebruiker vult nu een basisformulier in. Dit basisformulier bevat vragen die het voor een programmeur of functioneel ontwerper makkelijker maken om een wijziging te begrijpen. ICT-medewerker De ICT-medewerker is in het nieuwe proces alleen nog maar verantwoordelijk voor het uitvoeren van een gebruikerstest en het implementeren van de wijziging in het nieuwe systeem. De ICTmedewerker vult geen wijzigingsverzoeken meer in het systeem. Dit wordt gedaan door wijzigingsbeheer. Wijzigingsbeheer Het wijzigingsbeheer is verantwoordelijk voor het registeren van alle RFC s. Zij vraagt de tijdsduur op van zowel het functioneel ontwerp als het realiseren van de aanpassing. Aan de hand van de opgegeven tijdsduur van de functioneel ontwerper en de programmeur maakt zij dan een planning voor beide partijen. Als laatste houdt zij de status bij van alle wijzigingenverzoeken zodra er aanpassingen zijn gemaakt. Functioneel ontwerper De functioneel ontwerper bepaalt of een wijziging wel reëel is. Daarna bepaalt de functioneel ontwerper of het een grote wijziging betreft. Is dit niet het geval dan vult de functioneel ontwerper een ontwerpformulier in voor kleine wijzigingen. De programmeur programmeert dan aan de hand van het ontwerpformulier aan de wijziging. Als het wel een grote wijziging betreft, wordt de wijziging ingepland voor het uitwerken van een functioneel ontwerp. De functioneel ontwerper zal nu een business & informatie analyse uitvoeren waarna er een functioneel ontwerp wordt opgemaakt. Programmeur De programmeur bepaalt aan de hand van het functioneel ontwerp de benodigde tijd die nodig is om de wijziging te realiseren. Hij heeft ook nog de mogelijkheid om een functioneel ontwerp af te blazen. Als hij het wel goedkeurt gaat hij het functioneel ontwerp uitwerken. De programmeur zal nog wel de wijziging installeren in een testomgeving omdat hij daarna zijn wijziging als eerste zal testen. Een programmeur wil natuurlijk zijn eigen werk ook testen. 6
7 2.2 Organigram Op deze afdeling is het onderzoek verricht en zal het advies invloed hebben als het wordt doorgevoerd. 2.3 Stakeholders Ton Vennema: Dit is de belangrijkste stakeholder omdat hij de manager van de ICT afdeling. Hij bepaalt uiteindelijk of het advies in behandeling zal worden genomen. Wijzigingsbeheer: Als het advies wordt doorgevoerd zal het wijzigingsbeheer de grootste veranderingen ondervinden. De programmeur wordt werk uit handen genomen en er komt een extra functie bij; de Functioneel ontwerper. Programmeur: De programmeur zal werk worden ontnomen door de functioneel ontwerper, hierdoor houdt hij meer tijd over voor zijn primaire werk, namelijk programmeren. Functioneel ontwerper: De functioneel ontwerper is de nieuwe functie binnen de ICT afdeling van B&S. Deze persoon zal de wijzigingen gaan beoordelen en classificeren en daarna de informatie zal doorgeven aan de programmeur. Het is belangrijk dat de functioneel ontwerper en programmeur elkaar goed leren kennen omdat er tussen deze twee functies erg veel communicatie zal zijn. Personen die de meldingen insturen: De personen die de meldingen insturen zullen sneller resultaat krijgen omdat het proces van verwerken van wijzigingsverzoeken sneller zal verlopen. 7
8 3. Verbetering knelpunten 3.1 Blauwdrukken worden niet uitgebreid uitgewerkt op papier De wijzigingen die worden aangevraagd door een gebruiker van het systeem Impuls of Codeless worden niet uitgebreid uitgewerkt op papier. Er wordt een kleine beschrijving gegeven door de gebruiker zelf. Wijzigingsbeheer mailt deze wijziging door naar de programmeur. De programmeur moet aan de hand van een kleine beschrijving zelf bepalen hoe de wijziging eruit moet zien. In het vernieuwde proces komt er tussen wijzigingsbeheer en de programmeur een functioneel ontwerper die de programmeur gaat ondersteunen. De functioneel ontwerper gaat voor elke wijziging een business&informatie analyse uitvoeren. Vanuit de business&informatie analyse maakt hij dan een functioneel ontwerp. Het functioneel ontwerp is in feite dus een blauwdruk van de aangevraagde wijziging. Het voordeel hiervan is dat de programmeur niet meer hoeft na te denken over het ontwerp van het programma. Betreft het maar een kleine wijziging dan wordt er geen business&informatie analyse uitgevoerd. Dat zou namelijk niet efficiënt zijn om een business&informatie analyse uit te voeren voor een kleine wijziging. Dit zou in sommige gevallen zelfs meer tijd kosten om een functioneel ontwerp te maken. Wijzigingsbeheer is verantwoordelijk voor het maken van een planning voor de functioneel ontwerper. Eigenlijk dezelfde planning als voor de programmeur wordt gemaakt. Het volgende figuur geeft de plek van de functioneel ontwerper aan in de nieuwe situatie. 3.2 Meldingen blijven te lang in de wachtrij staan Doormiddel van het uitwerken van blauwdrukken door de functioneel ontwerper en het structureren van wijzigingsformulieren wordt de gebruiker en de functioneel ontwerper gedwongen om na te denken over de technische kant van de wijziging. De programmeur kan zich hierdoor volledig richten op het programmeren van de wijziging. Doordat taken van de programmeur over worden genomen door de gebruikers van de systemen en de functioneel ontwerper 3.3 Structureren van wijzigingsformulieren De wijzigingsformulieren worden in het leven geroepen om een duidelijkere omschrijving te geven over de wijziging. Zodra de gebruikersorganisatie een wijziging wil indienen moet er een basisformulier worden ingevuld. Op dit formulier moet worden ingevuld wie er betrokken zijn bij de wijziging en welke afdeling(en). Een globale omschrijving van deze wijziging is ook nodig. Ook geeft de gebruiker aan hoe hoog de prioriteit voor diegene is. Vervolgens wordt dit formulier naar het wijzigingsbeheer gestuurd. Na het indienen van het verzoek wordt door de Functioneel ontwerper/business analist gecheckt of het een grote of kleine wijziging betreft. Aan de hand hiervan wordt een technisch formulier ingevuld. Bij een kleine wijziging zal een klein ontwerpformulier worden ingevuld waarin een kleine omschrijving van de wijziging worden gegeven, bij een grote wijziging zal het een groter formulier worden ingevuld, ook wel het functioneel ontwerp genoemd. 8
9 3.4 Implementeren door ICT-medewerker Momenteel wordt de wijziging geprogrammeerd, getest en geïmplementeerd door de programmeur. Om de programmeur werk uit handen te nemen wordt het implementeren van de wijziging verzorgd door de ICT-medewerker. Als er na het testen een akkoord is gegeven door zowel de ICTmedewerker als de gebruikersorganisatie wordt de status veranderd in Goedgekeurd en kan de wijziging worden geïmplementeerd. 3.5 Testen aan de hand van testplan Als de programmeur klaar is met programmeren en de wijziging in de testomgeving heeft geïnstalleerd gaat hij de wijziging testen aan de hand van het testplan. Hierin staan verschillende tests omschreven die de programmeur succesvol zou moeten kunnen uitvoeren. Mocht de programmeur tijdens het testen fouten ontdekken dan worden deze direct opgelost en opnieuw getest totdat deze succesvol zijn. Dit testplan wordt gemaakt door de functioneel ontwerper. Door dit testplan hoeft de programmeur niet meer na te denken over welke testen hij gaat uitvoeren. Dit scheelt tijd. 3.6 Integratie met Delfzijl Locatie B&S Dordrecht heeft erg weinig integratie met de werkzaamheden binnen Holland Trading Group Delfzijl. Hierdoor is het onmogelijk om ons advies door te integreren op locatie Delfzijl. Dit komt door zowel Dordrecht als Delfzijl gebruik maken van een eigen informatiesysteem. Als Delfzijl dezelfde capaciteitsproblemen heeft als in Dordrecht dan kan er in Delfzijl ook geadviseerd worden om een functioneel ontwerper te plaatsen in het wijzigingsproces. 9
10 4. Nieuw proces RFC Hieronder staat het nieuwe proces afgebeeld in een Visio Flowchart. 10
11 11
12 5. Nieuw procesbeschrijving RFC Algemeen De beschrijving van het gewenste nieuwe proces van de RFC zal worden ingedeeld in verschillende fasen. Elke fase zal omschreven worden inclusief de partijen die bij elke fase van het proces betrokken zijn. Uiteindelijk zal door middel van een stroomdiagram het proces samenvattend uitgelegd worden. Fase 1: Door communiceren gewenste wijziging Betrokken partijen: Gebruikersorganisatie Wijzigingsbeheer Een medewerker van de gebruikersorganisatie wil dat er een wijziging wordt doorgevoerd in het systeem Codeless of Impuls Unix. Een medewerker van de gebruikersorganisatie communiceert de gewenste wijziging door aan het wijzigingsbeheer door middel van een basisformulier. Het wijzigingsbeheer registreert een melding in een Accesdatabase. De melding omvat een korte omschrijving en een prioritering. Fase 2: Plannen en ontwikkelen functioneel ontwerp Betrokken partijen: Wijzigingsbeheer Functioneel ontwerper Nadat de melding voor een wijziging is binnen gekomen en geregistreerd, moet de functioneel ontwerper eerst bepalen of het uitvoeren van de wijziging reëel is. Doet dit hij door middel van een analyse. Als uit de analyses blijkt dat het wijzigingsvoorstel niet reëel is, wordt de status van het verzoek op afgekeurd gezet. Als het verzoek wel reëel is, gaat de functioneel ontwerper na of de wijziging groot is of niet. De wijziging wordt als groot beschouwd als er voor de wijziging meer dan 7 uur geschat wordt om aan te brengen. Als de wijziging groot is voor de organisatie, gaat de functioneel ontwerper bepalen hoeveel tijd hij nodig heeft voor het maken van het functioneel ontwerp. Dit wordt gestuurd naar het wijzigingsbeheer en deze afdeling maakt de planning voor de functioneel ontwerper. In deze planning wordt vermeld wat de functioneel ontwerper per week moet maken voor bepaalde meldingen. Vervolgens gaat de functioneel ontwerper een business en informatie analyse maken voor de wijzigingsmeldingen en wordt aan de hand van deze analyses een functioneel ontwerp gemaakt. Als het wijzigingsvoorstel klein is, kan de functioneel ontwerper ervoor kiezen om een klein ontwerp formulier in te vullen voor de melding. Hierbij wordt geen business en informatie analyse gemaakt, maar er wordt gebruik gemaakt een standaard ontwerpformulier. 12
13 Fase 3: Plannen en ontwikkelen wijziging Betrokken partijen: Wijzigingsbeheer Functioneel ontwerper Programmeur Als het functioneel ontwerp of standaard ontwerpformulier is opgeleverd, wordt er door de functioneel ontwerper een testplan gemaakt. Hierin komt te staan hoe de wijziging getest moet worden aan de hand van het ontwerp dat ervoor gemaakt is. Vervolgens levert de functioneel ontwerper zijn testplan op en verandert het wijzigingsbeheer de status van de wijziging naar Klaar voor programmeren. Het wijzigingsbeheer stuurt na het aanpassen van de status een bericht naar de programmeur met de vraag hoeveel tijd hij nodig heeft voordat een bepaalde melding kan worden getest. De programmeur analyseert het functioneel ontwerp en gaat hierna de tijd bepalen die hij nodig heeft. Als de programmeur akkoord gaat met het functioneel ontwerp, meldt hij dit aan het wijzigingsbeheer wederom maakt deze afdeling de planning voor de functioneel ontwerper. Als de programmeur niet akkoord gaat met het ontwerp, dan moet het functioneel ontwerp worden aangepast of opnieuw gemaakt worden. Aan de hand van de planning die gemaakt wordt door het wijzigingsbeheer gaat de programmeur het ontwerp uitwerken, welke door de functioneel ontwerper is gemaakt. Als de programmeur zijn uitwerking heeft voltooid, installeert hij de wijziging in de testomgeving en kan er getest worden. Fase 4: Testen wijziging Betrokken partijen: Wijzigingsbeheer Programmeur ICT medewerker Gebruikersorganisatie Nadat de gemaakte wijziging van de programmeur is geïnstalleerd op de testomgeving, kan de programmeur zijn werk testen aan de hand van het testplan dat opgesteld is door de functioneel ontwerper. Na deze test wordt door het wijzigingsbeheer de status van de wijziging aangepast naar klaar voor gebruikerstest. Vervolgens wordt het gemaakte werk van de programmeur getest door de gebruikersorganisatie en door de ICT medewerker. Beide partijen moeten akkoord gaan met deze wijziging. Als er bij één van de partijen of allebei de partijen niet akkoord gaat met de wijzigingen, wordt de status van de wijziging door het wijzigingsbeheer op afgekeurd gezet en moet er opnieuw een functioneel ontwerp gemaakt worden. Gaan beide partijen wel akkoord, dan wordt de status van de wijziging door het wijzigingsbeheer gezet op Goedgekeurd. Fase 5: Implementatie wijziging Betrokken partijen: ICT medewerker Wijzigingbeheer Zodra de wijziging is goedgekeurd, kan de implementatiefase beginnen. De ICT medewerker implementeert de wijziging op de draaiende applicatie. Vervolgens past het wijzigingsbeheer de 13
14 status aan naar afgehandeld. Uiteindelijk volgt alleen nog de nazorg van de wijziging, dit houdt in dat er een controle plaatsvind of de applicatie werkt zoals het zou moeten werken, of de gebruiker tevreden is met de applicatie en of er nog eventuele updates benodigd zijn. Daarna wordt het proces afgerond. 6. Conclusie / aanbeveling De studentengroep SITA heeft afgelopen maanden voor B&S onderzoek gedaan naar de mogelijkheden om het proces van Request for Change te verbeteren. De onderzoeksvraag luidt dan ook: Hoe kan het proces van verwerking van wijzigingsverzoeken worden geoptimaliseerd? Hierover is een onderzoeksrapport gemaakt. Naar aanleiding van het onderzoeksrapport is de adviesgroep SITA in dit adviesrapport ingegaan op de knelpunten die zijn gevonden: Blauwdrukken komen niet op papier te staan` Meldingen blijven te lang in de wachtrij staan Communicatie met Delfzijl wat betreft integratie database De belangrijkste bevinding is dat uit het gevoerde onderzoek bleek dat de programmeur onvoldoende capaciteit heeft om alle wijzigingsverzoeken te verwerken. In de huidige situatie moet de programmeur bij een wijzigingsvoorstel een informatie analyse uitvoeren, zijn plan gaan programmeren en vervolgens zijn gemaakte werk testen en implementeren. Dit kost de programmeur teveel tijd en dit zorgt ervoor dat de wachtrij voor wijzigingen alleen maar groeit. Uit het onderzoek heeft SITA een aantal adviezen opgesteld. 1. Ten eerste adviseert adviesgroep SITA om een functioneel ontwerper in het proces te plaatsen. De functioneel ontwerper maakt aan de hand van business- en informatie analyse een ontwerp, zodat de programmeur dit niet meer hoeft te doen. Vervolgens stelt hij een testplan op zodat de programmeur niet zijn eigen testplan hoeft op te stellen om te gaan testen. Hierdoor wordt er een deel van het werk van de programmeur overgenomen zodat hij zich meer kan focussen op het programmeer werk. Kosten en baten functioneel ontwerper. Dit is een indicatie van de kosten die de functionele ontwerper met zich mee zal brengen en de opbrengsten/besparingen die deze extra functie zal opleveren. Het verwachte uurloon dat de functioneel ontwerper zal ontvangen is een modaal uurloon van 20,- per uur. Aangezien het een full-time functie betreft zal dit 4x38x20 = 3040,- per maand kosten. Door deze extra ingebrachte functie zullen de wijzigingen in een kortere tijd kunnen worden verwerkt. Verwacht wordt dat de tijd voor het verwerken van wijzigingen met 35% zal afnemen. In de toekomst, als functioneel ontwerper en programmeur goed op elkaar zijn ingespeeld kan de verwerkingstijd wellicht nog verder worden teruggeschroefd. 14
15 2. Ten tweede adviseert SITA om een standaard formulier in te voeren voor de gebruikersorganisatie waarop wijzigingsverzoeken kunnen worden ingevoerd. Hiermee kan de gebruiker meer gespecificeerd aangeven welk onderdeel in het systeem veranderd moet worden en wat er precies veranderd moet worden. 3. Ten derde adviseert SITA om na verzoekbeoordeling (Prioritering, realiseerbaarheid, grootte) de verzoeken aan de hand van grootte op te delen in een ontwerpformulier voor kleine wijzigingen, of een volledig functioneel ontwerp. Dit kan bij kleine wijzigingen de functioneel ontwerper tijd besparen, omdat deze persoon dan geen volledig functioneel ontwerp hoeft te maken. 4. Ten slotte adviseert SITA de taak van implementatie van de wijzigingen uit handen van de programmeur te nemen. Dit zal dan worden gedaan door de ICT medewerker. SITA hoopt dat de gegeven oplossingen zullen bijdragen aan het oplossen van de genoemde knelpunten. 15
16 7. Literatuurlijst Geraadpleegde schriftelijke bronnen Janssen, P. (2008), IT-service management volgens ITIL(3 de 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); Gertjan Schop, Klaverbladmodel (geraadpleegd op 11 maart 2012); 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); Mumin Er, Modulewijzer (geraadpleegd van 8 februari tot 30 mei 2012); Geïnterviewde personen 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 16
Intake <applicatie> Conclusie & Aanbevelingen. <Datum> 1.0. <Auteur> ###-#######
Intake Conclusie & Aanbevelingen Datum Versie 1.0 Auteur Telefoon ###-####### Inhoudsopgave 1. VOORWOORD... 1 2. BESCHRIJVING APPLICATIE... 2 2.1. FUNCTIONEEL ONTWERP... 2
Nadere informatieCompetenties Luuk van Paridon. Analyseren
Competenties Luuk van Paridon Overzicht waar ik nu sta: Afbeelding 1: Spinnenweb competenties De groene lijn geeft aan welke competenties ik tot nu toe behaald heb (zie Afbeelding 1). De competenties die
Nadere informatiePROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D
PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT
Nadere informatieAdviesrapport. 5%-regeling. Plaats: Rotterdam Maand & jaar: Juni 2011. Identificatie YUME
YUME Adviesrapport 5%-regeling Rotterdam Roteb Adviesrapport 5%-regeling Plaats: Rotterdam Maand & jaar: Juni 2011 Identificatie YUME Tim Lansbergen Ruben van der Tas Noud Seegers Richard Lagewaard 0836930@student.hr.nl
Nadere informatieHandleiding Plug and Payroll t.b.v. opdrachtgevers. Inhoudsopgave
Handleiding Plug and Payroll t.b.v. opdrachtgevers Inhoudsopgave 1. Inlog opdrachtgever... 3 a. Een nieuwe opdracht aanmaken... 3 2. Een nieuwe opdracht... 4 a. Gegevens medewerker... 4 b. Gegevens opdracht/contract...
Nadere informatieHandleiding GBO Helpdesk voor aanmelders
Inhoud 1 Inleiding... 2 2 In- en uitloggen... 3 2.1 Webadres GBO Helpdesk... 3 2.2 Inloggen... 3 2.3 Wachtwoord wijzigen... 4 2.4 Uitloggen... 4 3 Incidenten... 5 3.1 Incident aanmelden... 5 3.2 Bijlage
Nadere informatiePROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN
PROJECT: ONTWIKKELOMGEVINGEN VIRTUELE TESTOMGEVINGEN ( Project Initiation Document ) Datum voltooid: 20/03/2013 Auteur: Kevin Sanders Studentnummer: 2148839 Versie: 0.1 Status: Concept Documenthistorie
Nadere informatieSocial Action Research Plan
Social Action Research Plan Social media project Studenten Dennis Visschedijk 438332 Aileen Temming 474094 Stefan Ortsen 481295 Niels Konings 449822 Renee Preijde 482835 Opdrachtgever Stal te Bokkel Daniëlle
Nadere informatieDefinitiestudie Pizzaketen
Definitiestudie XXXXXXXXXXXX Assen 06-10-2008 xxxxxxxxxxx Pagina 0 Inhoudsopgave Inhoudsopgave ------------------------------------------------------------------------------------------- 1 Inleiding --------------------------------------------------------------------------------------------------
Nadere informatieGeef de titel van het wijzigingsverzoek zo kort mogelijk weer.
Naam indiener WIJZIGINGSVOORSTEL Nummer: xxx Datum: dd-mm-jj Status: stap 1, 2, 3, 4 of 5 Bedrijfsonderdeel/afdeling/ functie Naam projectmanager Naam wijzigingsbehandelaar (indien van toepassing) Het
Nadere informatieTaak 2.1.4 Eerst zien dan geloven... 1. Inhoud
Taak 2.1.4 Eerst zien dan geloven Inhoud Taak 2.1.4 Eerst zien dan geloven... 1 Inhoud... 1 Inleiding... 2 Modules van urenregistratiesysteem (Blokboek)... 3 Module applicatiebeheer... 3 Module projectbeheer...
Nadere informatieAdvies. Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie
DIENST Advies over en ondersteuning bij het (initieel) inrichten/optimaliseren van de structuur van de(it Service Management)organisatie Advies over en ondersteuning bij het initieel inrichten/optimaliseren
Nadere informatieProcesbeschrijving Punch out aansluiting DigiInkoop
Procesbeschrijving Punch out aansluiting DigiInkoop Versie 1.1 Datum 28 mei 2014 Status Definitief Colofon Projectnaam DigiInkoop Versienummer 1.1 Contactpersoon Centraal Functioneel Beheer DigiInkoop
Nadere informatieProject 2 Maze Driver. Plan van Aanpak TI1A
Plan van Aanpak TI1A 1 Inhoudsopgave Achtergronden... 3 Projectopdracht... 4 Projectactiviteit... 5 Projectgrenzen... 6 Tussenresultaten... 7 Kwaliteit... 8 Projectorganisatie... 9 Planning... 10 Kosten
Nadere informatieReleasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken
Releasen met een druk op de knop: Met behulp van Continuous Delivery sneller uw doel bereiken De business organisatie heeft altijd stijgende verwachtingen van uw IT organisatie. Meer dan ooit is het van
Nadere informatieKwaliteitskosten onderzoek. Aanpak. Algemene informatie voor medewerkers van: SYSQA B.V.
Kwaliteitskosten onderzoek Aanpak Algemene informatie voor medewerkers van: SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 8 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2 VERSIEBEHEER... 3 2 KWALITEITSKOSTEN...
Nadere informatieChange Management. beschrijving van procedures
Change Management beschrijving van procedures Aan: Projectgroep Ontwikkeling FlorEcom (PROF) Van: G. Heemskerk Betreft: FlorEcom change management Versie: 1.3 Datum: 31 januari 2002 1. Inleiding Deze notitie
Nadere informatieArchitecture Governance
Architecture Governance Plan van aanpak Auteur: Docent: Stijn Hoppenbrouwers Plaats, datum: Nijmegen, 14 november 2003 Versie: 1.0 Inhoudsopgave 1. INLEIDING... 3 2. PROBLEEMSTELLING EN DOELSTELLING...
Nadere informatie14/11/2010. Voorbeelden van productrisico s. Omschrijving bevindingenanalyse. Productrisicoanalyse (1)
Project- en productrisico s RISICO- ANALYSE & TESTSTRATEGIE No. 24 Project- versus productrisico s No. 25 Voorbeelden van projectrisico s Business Project overschrijding Tijd Budget Slechte testomgeving
Nadere informatieDe ontwikkeling van een gebouwbeheersysteem
De ontwikkeling van een gebouwbeheersysteem Een afstudeeropdracht elektrotechniek Auteurs: R. Hulzebos S.H. de Lange Opleiding: Hanzehogeschool faculteit techniek De ontwikkeling van een gebouwbeheersysteem
Nadere informatieVoorwoord bij de tweede druk
7 Voorwoord Er zijn veel verschillende bedrijven die werkzaam zijn in de productiesector of de dienstensector en die elk hun sterke en minder sterke zijden hebben. Een bedrijf probeert zich te onderscheiden
Nadere informatieInstituut Broers. Plan van Aanpak. Zubin Mathoera & Tomas Berends. Zubin Mathoera Tomas Berends Maarten van Mensvoort Tim van Berkel
Instituut Broers Plan van Aanpak Zubin Mathoera & Tomas Berends Zubin Mathoera Tomas Berends Maarten van Mensvoort Tim van Berkel 00-00-0000 VOORWOORD Dit plan van aanpak hebben wij volgens het boek van
Nadere informatieDe nazorg van pleegzorg voor pleegouders
2014 Onderzoek en Innovatie Projectresultaat Dit onderzoek is verricht ten behoeve van het studieonderdeel Onderzoek &innovatie van de opleiding Pedagogiek aan de HAN te Nijmegen De nazorg van pleegzorg
Nadere informatieFloraHolland Ketenreleaseproces
Florecom Software Leveranciers Lunch FloraHolland Ketenreleaseproces Afgestemd met Florecom en Samenwerkingsverband Kwekersoftware 19 januari 2011 Ketenreleaseproces op hoofdlijnen 2 Processtappen 1. RFC
Nadere informatieOpleiding Technische Informatica 2007-2008 Ontwerp Gericht Onderwijs 1.1 (2IO05) Handleiding
Opleiding Technische Informatica 2007-2008 Ontwerp Gericht Onderwijs 1.1 (2IO05) Handleiding Eindhoven, 24 augustus 2007 Gemaakt door: Meulemans, W. Dinkla, K. Coördinator: Sidorova, dr. N. 2 Inhoudsopgave
Nadere informatiePlan van Aanpak Pilot
Plan van Aanpak Pilot DBK-applicaties Beproeven compatibiliteit DBK-applicaties op innovatieplatform voor de Veiligheidsregio s Status : concept Versienummer : V0.2 Datum : Augustus 2012 Blad : 2 / 6 Inhoudsopgave
Nadere informatieNIS Notarieel Informatie Systeem
INSTALLATIEHANDLEIDING CONVISO ID-SCAN NIS Notarieel Informatie Systeem Sportlaan 2h, 818 BE Heerde T (0578) 693646, F (0578) 693376 www.vanbrug.nl, info@vanbrug.nl 2014 Van Brug Software B.V. Hoewel deze
Nadere informatieOm gebruik te maken van de Realmark OSRE Groep Servicedesk dient u een account aan te maken. Het aanmaken van een account stelt u in staat om:
Inleiding In deze handleiding leggen wij het basisgebruik van de Realmark OSRE Groep Servicedesk uit. Mocht er naar aanleiding van het lezen van deze handleiding nog vragen en/of opmerkingen zijn, neem
Nadere informatieProject Fasering Documentatie ICT Beheerder. Auteurs: Angelique Snippe Tymen Kuperus
Project Fasering Documentatie ICT Beheerder Auteurs: Angelique Snippe Tymen Kuperus Datum: 31 Januari 2011 Kerntaak 1 Ontwikkelen van (onderdelen van) informatiesystemen De volgordelijke plaats van de
Nadere informatieStageplan. Stageplan v0.3 10-03-11 Dennis Wagenaar
Stageplan Stageplan v0.3 10-03-11 Dennis Wagenaar 1 Inhoudsopgave Inleiding...3 Organisatorische aspecten...3 Gegevens van de student...3 Gegevens van de stageorganisatie...3 Gegevens van de stagebegeleider...3
Nadere informatiePrototype/Usability testverslag
Prototype/Usability testverslag Save Energy Leiden Dennis Wagenaar 19-04-10 v1.0 Inhoudsopgave Inleiding...3 1 Opdracht...4 1.1 Probleemstelling...4 1.2 Doelstelling...4 1.3 Onderzoeksvraag...4 1.4 Deelvragen...4
Nadere informatiePraktijkinstructie Helpdesk 3 (ICT08.3/CREBO:53269)
instructie Helpdesk 3 (ICT08.3/CREBO:53269) pi.ict08.3.v1 ECABO, 1 april 2002 Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd, overgenomen, opgeslagen of gepubliceerd in enige
Nadere informatieService portaal. Handleiding voor klanten
Service portaal Handleiding voor klanten Inhoud... 1 Inhoud... 2 1. Inleiding... 3 2. Toegang... 3 3. Servicedesk... 4 3.1. Indienen van een vraag...4 3.2. Indienen van een incident...4 4. Ontwikkeling...
Nadere informatieVan stapels papier naar digitaal machtigen. Informatie over het machtigingenportaal voor mondzorg
Van stapels papier naar digitaal machtigen Informatie over het machtigingenportaal voor mondzorg Voor wie? Tandartsen, kaakchirurgen, implantoloog, tandprotheticus tandartsspecialist, centra bijzondere
Nadere informatieNaam: Draaiboek decentrale implementatie PAUW en Tridion
Programma Aanpak Universitaire Website (PAUW) Draaiboek decentrale implementatie PAUW en Tridion Inleiding In het kader van het Programma Aanpak Universitaire Website (PAUW) is afgesproken dat alle decentrale
Nadere informatieAugustus 2012 gestart om de certificaten, Bisl, Prince 2, ITIL en IT- servicemanagement te behalen.
Riemke Oosterhof Nicolaas Beetsstraat 127 9721 RM Groningen Geboortedatum: 21-01-1978 Geboorteplaats: Delfzijl Email: riemke.oosterhof@gmail.com Telefoonnummer: 050-7508119 Mobielnummer: 06-10543868 Rijbewijs:
Nadere informatieHANDLEIDING. Emjee ICT diensten Ticketsysteem
HANDLEIDING Emjee ICT diensten Ticketsysteem Inhoud Snel aan de slag... 3 Wachtwoord opvragen... 3 Inloggen... 4 Ticket aanmaken... 4 Schermopbouw... 4 Inleiding... 5 Ticket maken of bellen?... 5 Inloggen...
Nadere informatieEnterprise Resource Planning. Hoofdstuk 3 Planning, ontwerp en implementatie van Enterprise Resource Planning-systemen
Enterprise Resource Planning Hoofdstuk 3 Planning, ontwerp en implementatie van Enterprise Resource Planning-systemen Pearson Education, 2007; Enterprise Resource Planning door Mary Sumner Leerdoelstelling
Nadere informatieHandleiding. Support & Helpdesk
Handleiding Support & Helpdesk Inhoudsopgave Handleiding... 1 Inhoudsopgave... 2 Introductie... 3 Wat is de Techtwo helpdesk?... 3 Waarom gebruikt Techtwo deze helpdesk?... 3 Waarom deze handleiding?...
Nadere informatieOpleidingsgebied ICT. 2 e beoordeling: Eindbeoordeling:
Opleidingsgebied ICT Kwalificatiedossier en kerntaak Applicatie- en mediaontwikkeling 2012-2013, 2013-2014 Kerntaak 3: Implementeren van de applicatie of (cross)media-uiting Kwalificatie en crebocode Applicatieontwikkelaar
Nadere informatieInhoud. Handleiding RT voor klanten. 1 Wat is RT? Voor wie is RT? Het aanwijzen van Manager en Melder...2
Inhoud 1 Wat is RT?...2 2 Voor wie is RT?...2 3 Het aanwijzen van Manager en Melder...2 4 Hoe werkt RT?...3 Een probleem melden...3 5 RT statussen...7 Huijsmans en Kuijpers Automatisering BV handleiding
Nadere informatieReview op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging
Review op uitgevoerde risico-inventarisatie implementatie resultaatgerichte bekostiging mr. drs. E.P.J. de Boer Rotterdam, Aanleiding en opzet van de review In opdracht van de GR Jeugdhulp Rijnmond is
Nadere informatieMajor Design This! Me and My. Guillaume May Studentnummer: 0751863 Klas: 4A
Major Design This! Me and My Guillaume May Studentnummer: 0751863 Klas: 4A Inhoudsopgave OPDRACHT OMSCHRIJVING: 3 ME AND MY 3 LEERDOELEN, COMPETENTIES EN GEDRAGSINDICATOREN. 3 LEERDOELEN 3 COMPETENTIES
Nadere informatieBeschrijving functioneel en technisch design van de website
Bespreking Punten: Beschrijving functioneel en technisch design van de website Nr. Punt 1 Student 2 Bedrijf 3 Algemene lay out 4 Technologieën 5 Webruimte en datatrafiek 1. Student Registratie Bij de registratie
Nadere informatieSjabloon testplan o.b.v. situationeel testen. <<Organisatie>>
Sjabloon testplan o.b.v. situationeel testen SYSQA B.V. Almere Datum : Status : Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 11 Over dit sjabloon Dit
Nadere informatieICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden
Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer
Nadere informatieHandleiding Simon. 5 juni Schouw Informatisering B.V. Danny Cevaal. Versienummer 1.0
Handleiding Simon 5 juni 2015 Schouw Informatisering B.V. Danny Cevaal Versienummer 1.0 2 Schouw Informatisering BV. behoudt zich het recht voor veranderingen in deze publicatie te allen tijde uit te voeren.
Nadere informatieBijlage 3: Master testplan
Bijlage 3: Master testplan KIS Testplan Inaxion Lelystad Adres: Jol -20 Postbus : 609 Postcode Plaats 8483 ED Lelystad I www.inaxion.nl Plaats Lelystad Datum 22 maart 200 Auteur Saidou Diallo Status Finaal.0
Nadere informatieBeheerVisie ondersteunt StUF-ZKN 3.10
Nieuwsbrief BeheerVisie Nieuwsbrief BeheerVisie 2015, Editie 2 Nieuws BeheerVisie ondersteunt StUF-ZKN 3.10 BeheerVisie geeft advies MeldDesk App Message Router MeldDesk Gebruikers Forum Nieuwe MeldDesk
Nadere informatieEindbeoordelingsformulier (Applicatieontwikkelaar 4)
Eindbeoordelingsformulier (Applicatieontwikkelaar 4) Eindbeoordeling werkprocessen Naam stagiair BPV bedrijf Datum BPV Begeleider Praktijkopleider Periode Kerntaak 1: Ontwerpen van de applicatie, (cross)media
Nadere informatieAnalyse Document. Release notes. Colofon Contactpersoon: Raymond Schram Releasenotes LCMS 2018v2 Datum: 5 oktober 2018
Release notes Analyse Document Colofon Contactpersoon: Raymond Schram Titel: Releasenotes LCMS 2018v2 Datum: 5 oktober 2018 Status: Definitief Versie: 1.1 Auteurs: Raymond Schram [IFV] Projectleider: Review:
Nadere informatie2de bach HIB. Systeemanalyse. Volledige samenvatting. uickprinter Koningstraat Antwerpen ,70
2de bach HIB Systeemanalyse Volledige samenvatting Q www.quickprinter.be uickprinter Koningstraat 13 2000 Antwerpen 152 8,70 Online samenvattingen kopen via www.quickprintershop.be Systeemanalyse Deel
Nadere informatieOpleidingsgebied ICT. Niveau Beginnend *zie omschrijving beoordelingscriteria Gevorderd* Bekwaam* Werkproces(sen) Beoordeling* 1 e 2 e eind
Opleidingsgebied ICT Kwalificatiedossier en kerntaak ICT- en mediabeheer 2012-2013 Kerntaak 1: Ontwikkelen van (onderdelen van) informatie- of mediasystemen Kwalificatie en crebocode ICT-beheerder 95321
Nadere informatiePlan van aanpak Toogle
Plan van aanpak Toogle Gemaakt door, Kevin Donkers Paul v.d. Linden Paul Eijsermans en Geert Tapperwijn 1 Inhoudsopgave 1 Inhoudsopgave...2 2 Inleiding...3 3 Projectopdracht...4 4 Projectactiviteiten...5
Nadere informatieInhoud: Inleiding tot Taak 1.1.14 1 Omschrijving van vacatures 2 Matrix van benodigde 5 Bronvermeldingen 7
Inleiding Taak 10 gaat over het oriënteren op het vakgebied van onze toekomst. Als we straks afgestudeerd zijn zullen we automatisch werk moeten gaan zoeken. Maar welk werk of in welke sector? Dat gaan
Nadere informatieSTARTFASE SYSTEEM IN GEBRUIK BIJ/DOOR P&O Melden namens. Gemeentelijk Incidenten Registratiesysteem GIR
STARTFASE SYSTEEM IN GEBRUIK BIJ/DOOR P&O Melden namens Gemeentelijk Incidenten Registratiesysteem GIR Handleiding voor de startfase Versie 1.0 Hengelo, 18 december 2008 Inhoud 1. Inleiding 3 1.1 Wat is
Nadere informatieFunctiebeschrijving. Applicatiebeheerder. Graad B1-B3
Functiebeschrijving Applicatiebeheerder Graad B1-B3 1 1 Applicatiebeheerder 1.1 Rol Als applicatiebeheerder ben je het aanspreekpunt voor het ontwerp, beheer en de instandhouding van de toegewezen applicaties.
Nadere informatieKwaliteitsbewaking en testen in ICT beheerorganisaties
DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt
Nadere informatieProjectplan. Elektronica-ICT Artesis. Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce
Elektronica-ICT Artesis Projectplan Auteur: Coopman Tom Interne Promotor: Peeters Tom Externe Promotor: Delepierre Bruno, Adforce Projectplan ter voorbereiding van de bachelorproef en stage Academiejaar
Nadere informatieInhoud. Woord vooraf 9
5 Inhoud Woord vooraf 9 1 Use case en begrippen 11 1.1 Inleiding 11 1.2 ICT-begrippen 11 1.3 De ICT-shop 17 1.4 Detach 19 1.5 De fusie: Eniac 22 1.6 Samenvatting 25 Case Eniac 25 2 De servicedesk 28 2.1
Nadere informatieOfferte / Gemeente Breda / Versie 2.0
Gemeente Breda t.a.v. mevrouw J de Bruijn Postbus 90156 4800 RH BREDA Breda, 9 juli 2007 Betreft : Referentie: Offerte ontwerpfase websites GemeenteBreda002 Geachte mevrouw De Bruijn, Met plezier sturen
Nadere informatieHANDLEIDING SERVICEDESKPORTAL
HANDLEIDING SERVICEDESKPORTAL SCHOUW INFORMATISERING B.V. 11-10-2018 HANDLEIDING SERVICEDESKPORTAL Schouw Informatisering B.V. behoudt zich het recht voor veranderingen in deze publicatie te allen tijde
Nadere informatieTussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011
Universitair Informatiemanagement Kenmerk: SECR/UIM/11/0914/FS Datum: 14-09-11 Tussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011 1. Inleiding Begin 2011
Nadere informatie1.0 Inleiding Testplan Testdoelen Navigatie Lay-out en prioriteit Interactie
Inhoudsopgave 1.0 Inleiding 3 2.0 Testplan 4 2.1 Testdoelen 4 2.1.1 Navigatie 4 2.1.2 Lay-out en prioriteit 4 2.1.3 Interactie 4 2.1.4 Content 4 2.1.5 Formulieren en foutafhandeling 5 2.1.6 Snelheid 5
Nadere informatieBeleid Opdrachten. Versie 1.0 augustus 2017
Beleid Opdrachten Versie 1.0 augustus 2017 Inhoud Voorwoord... 3 De procedure uitgelegd... 4 E-mail naar afdeling Support... 4 Opdrachtomschrijving... 4 Impact... 4 Impact akkoord... 4 Impact niet akkoord...
Nadere informatieMELDDESK. Het systeem voor het registreren, afhandelen en rapporteren. van meldingen in de gemeente!
MELDDESK Het systeem voor het registreren, afhandelen en rapporteren van meldingen in de gemeente! MELDDESK WANT UW BURGER IS TOCH GEEN BIJZAAK! MeldDesk is een toonaangevend informatiesysteem voor gemeenten
Nadere informatie1 Inleiding. 3 Handmatig... invoeren zaken basis 4 Verwerken... zaken 5 Afhandelen... van zaken. 7 Uitgebreidere... zaak opties
2 Supportdesk Pro Introductie Inhoudsopgave I Supportdesk Pro 3 1 Inleiding... 3 2 Werkwijze... 3 II Zaken 4 1 Introductie... 4 2 Zaken beheren... 4 3 Handmatig... invoeren zaken basis 4 4 Verwerken...
Nadere informatieBusiness-ICT-Alignment en functioneel beheer Een nuchtere kijk op functioneel beheer
Business-ICT-Alignment en functioneel beheer Een nuchtere kijk op functioneel beheer Inleiding Functioneel beheer, dat klinkt wellicht als een ICT-activiteit. En ICT-activiteiten, dat zijn zaken voor de
Nadere informatieEnterprise Resource Planning
Enterprise Resource Planning Hoofdstuk 2 Re-engineering en systemen voor Enterprise Resource Planning Pearson Education, 2007; Enterprise Resource Planning door Mary Sumner Leerdoelstellingen De factoren
Nadere informatieTesten. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2
Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt
Nadere informatieHulpmiddelen bij implementatie van Digikoppeling
Hulpmiddelen bij implementatie van Digikoppeling Versie 1.0 Datum 23/05/2014 Status Definitief Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555 4555 (10 ct p/m) e. servicecentrum@logius.nl
Nadere informatiexpression stappen voor succesvolle implementatie en migratie! ITvisors is gecertificeerd implementatiepartner van EMC xpression
xpression Klanten willen steeds vaker via internet of mobile devices met organisaties communiceren. Organisaties zijn dus genoodzaakt om hun communicatie hierop aan te passen. Want een betere communicatie
Nadere informatieRLBS (robbert Location based services)
RLBS (robbert Location based services) Functioneel ontwerp Robbert Brussaard 22-02-2010 Versie 1.0 Robbert Brussaard (62391) 22-02-2010 Inhoudsopgave 1.1 Samenvatting...2 1.2 Samenvatting...2 1.3 Versiebeheer...2
Nadere informatieBIJLAGE A: TAAK 1: IMPLEMENTATIE PECKELSHEIM Voor de uitvoering van deze taak waren in het projectvoorstel de activiteiten in Tabel B.1 gedefinieerd. Tabel A.1: Activiteiten Taak 1 1.1. Aanpassen en complementeren
Nadere informatieTitel: Projectdocumenten niveau 4. Versie: 0.6. Datum: 28 augustus 2008. Auteur: Harmen Steenbergen / Titia Brouwer. Projectdocumenten Niveau 4
Titel: Projectdocumenten niveau 4 Versie: 0.6 Datum: 28 augustus 2008 Auteur: Harmen Steenbergen / Titia Brouwer Pagina 1 van 10 Inhoudsopgave Inleiding...4 Algemeen...4 Planning en logboek...4 Definitiestudie...4
Nadere informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1
Nadere informatieProblematiek in projecten
Problematiek in projecten Het project bouwt andere producten dan afgesproken Het project valt duurder uit dan begroot Het project loopt langer dan gepland Het product sluit niet aan bij de werksituatie
Nadere informatieToelatingsassessment. Portfolio. Assessment t.b.v. toelating tot de deeltijdopleiding HBO-ICT. Naam Adres Telefoon Datum
Toelatingsassessment Portfolio Assessment t.b.v. toelating tot de deeltijdopleiding HBO-ICT Naam Adres Telefoon E-mail Datum 1 Persoonlijke gegevens en c.v. Neem hieronder uw persoonlijke gegevens en curriculum
Nadere informatieInformatiemanager. Doel. Context
Informatiemanager Doel Ontwikkelen, in stand houden, evalueren, aanpassen en regisseren van het informatiemanagement, de digitale informatievoorziening en de ICT-facilitering van de instelling en/of de
Nadere informatiePeridos. Registreren voor Zorgportaal. Datum: Landelijk beheer Peridos. Versie: 1.3
Peridos Registreren voor Zorgportaal Plaats: Utrecht Datum: 22-05-2019 Auteur: Landelijk beheer Peridos Versie: 1.3 Status: Definitief Inhoudsopgave Inhoudsopgave 2 Wijzigingsbeheer 3 1. Inleiding 4 1.1
Nadere informatieLeerjaar 1/2 ICT-Academie. Niveau 4. Applicatie ontwikkeling
Databases SQL Leerjaar 1/2 ICT-Academie Niveau 4 Applicatie ontwikkeling Auteur: R. Meijerink Datum: Januari 2013 0. Inleiding Databases / SQL In deze lessen wordt je geleerd databases te bouwen in SQL-code.
Nadere informatieHandleiding voor aansluiten op Digilevering
Handleiding voor aansluiten op Digilevering Versie 1.0 Datum 1 augustus 2013 Status definitief Colofon Projectnaam Digilevering Versienummer 1.0 Contactpersoon Servicecentrum Logius Organisatie Logius
Nadere informatieGebruikershandleiding. Ouder Login TSO De Kring
Gebruikershandleiding Ouder Login TSO De Kring Gebruikershandleiding ouder login Maakt u gebruik van of wilt u gebruik maken van de tussenschoolse opvang op PCBS De Kring, dan kunt u zich via de website
Nadere informatieOndersteuning proces Prestatiemeten door IV. Wat is nieuw en wat blijft hetzelfde
Ondersteuning proces Prestatiemeten door IV Wat is nieuw en wat blijft hetzelfde Ondersteuning proces Prestatiemeten door IV Wat is nieuw en wat blijft hetzelfde Datum 30 april 2015 Status Definitief Inhoudsopgave
Nadere informatieSoftware Test Plan. Yannick Verschueren
Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren
Nadere informatieTopicus Jeugdzorg VVE- UP. Functionele beschrijving
Topicus Jeugdzorg VVE- UP Functionele beschrijving Topicus Jeugdzorg, 17 mei 2013 2 1 Inhoudsopgave 1 Inhoudsopgave...2 Versiebeheer...2 2 Inleiding...3 3 Instellingen VVE- UP...4 4 Beheer...5 5 Smartobject
Nadere informatieUitgebreide implementatieondersteuning
Uitgebreide implementatieondersteuning Overstappen op een nieuw leermiddel of een digitaal concept brengt altijd enige onzekerheid met zich mee. Om deze onzekerheid te minimaliseren begeleidt ThiemeMeulenhoff
Nadere informatieehealth binnen de thuiszorg van Noorderbreedte
ehealth binnen de thuiszorg van Noorderbreedte De ontwikkeling van de ehealth-koffer Naam : Seline Kok en Marijke Kuipers School : Noordelijke Hogeschool Leeuwarden Opleiding : HBO-Verpleegkunde voltijd
Nadere informatieopvolgingsonderzoek re-integratie en voortijdig schoolverlaten
opvolgingsonderzoek re-integratie en voortijdig schoolverlaten juli 2012 1 inleiding 1-1 aanleiding De rekenkamer voert onderzoeken uit naar de doelmatigheid, doeltreffendheid en rechtmatigheid van het
Nadere informatieProject Fasering Documentatie Applicatie Ontwikkelaar
Project Fasering Documentatie Applicatie Ontwikkelaar Auteurs: Erik Seldenthuis Aminah Balfaqih Datum: 31 Januari 2011 Kerntaak 1 Ontwerpen van applicaties De volgordelijke plaats van de documenten binnen
Nadere informatieVoortgangsverslag werkend leren
Voortgangsverslag werkend leren EDP1 Rens Brouwer Voortgangsverslag werkend leren EDP1 Rens Brouwer Delft December 2012 Haagse Hogeschool Voorwoord Op dit moment ben ik duaal student. Dit houdt in dat
Nadere informatieEENVOUDIG EN SNEL OP WEG MET LEERLINGENVERVOER.NU
EENVOUDIG EN SNEL OP WEG MET LEERLINGENVERVOER.NU INTRO Elke gemeente heeft jaarlijks vele aanvragen voor leerlingenvervoer te verwerken. Vaak is dit een complex en arbeidsintensief proces, met een enorme
Nadere informatieBeheervoorziening BSN - Use Case Specificatie 16: Toets of nummer een BSN is
Beheervoorziening BSN - Use Case Specificatie 16: Toets of nummer een BSN is Versie 3.1 Datum 3 maart 2015 Inhoud Inhoud 2 Inleiding 4 1 Hoofdscenario 4 1.1 Initiatie 4 1.1.1 Ontvang bericht toets of nummer
Nadere informatieHANDLEIDING LOKALE UITVOERBAARHEID VOOR EEN INTERNE INDIENER. Werken in het METC Management-Systeem METC Erasmus MC
HANDLEIDING LOKALE UITVOERBAARHEID VOOR EEN INTERNE INDIENER Werken in het METC Management-Systeem METC Erasmus MC METC Erasmus MC versie 1 augustus 2018 Inhoud 1. Inleiding... 2 2. Toegang tot het METC
Nadere informatieIncore Solutions Learning By Doing
Incore Solutions Learning By Doing Incore Solutions Gestart in November 2007 Consultants zijn ervaren met bedrijfsprocessen en met Business Intelligence Alle expertise onder 1 dak voor een succesvolle
Nadere informatieInlichtingenbureau Voortgangsrapportage April Realisatie van het Sectorloket-systeem
Inlichtingenbureau Voortgangsrapportage April 2004 Realisatie van het Sectorloket-systeem Opdrachtgever: stichting Inlichtingenbureau Status Versie Datum Definitief 1.0 27 april 2004 Inhoudsopgave Inhoudsopgave...
Nadere informatie