Concerns van stakeholders in de beheerorganisatie

Maat: px
Weergave met pagina beginnen:

Download "Concerns van stakeholders in de beheerorganisatie"

Transcriptie

1 Concerns van stakeholders in de beheerorganisatie Risico analyse op basis van interactie en checklists versie 0.2 Bert Dingemans

2 1 Inleiding Risico analyse is een relatief onbekend fenomeen binnen de ICT, op een aantal plaatsen kom je het tegen binnen de beheerprocessen zoals ITIL. Echter binnen de methoden voor enterprise architectuur zoals Togaf en Archimate is werken met risico s een onderbelicht onderwerp. Dit artikel zoekt naar de mogelijkheden om risico inventarisatie te implementeren binnen de kaders van Togaf en Archimate. Het beperkt zich hierbij om reden van projectscope tot de risico s van de beheerorganisatie. Vanzelfsprekend is deze scopebeperking arbitrair. Ook voor andere stakeholders is het werken vanuit risico s een interessant perspectief. 2 Stakeholders en beheer 2.1 Stakeholders in de beheerorganisatie Bij het opstellen van een enterprisearchitectuur spelen de concerns van de stakeholders een belangrijke rol. Deze bepalen de richting van de oplossing in de target architectuur. Ook is bij het uitwerken van de baseline architectuur de input van stakeholders een belangrijke bron van informatie bij inventarisatie van concerns. De beheerorganisatie is in deze een stakeholder populatie die een afwijkende rol vervuld binnen de enterprise architectuur. De beheerorganisatie maakt geen deel uit van bijvoorbeeld de werkprocessen die deel uitmaken van de uitwerking van de architectuur. Sterker nog de beheerorganisatie van ICT systemen is ingericht op basis van eigen werkprocessen. Deze processen worden omschreven als de beheerprocessen en zijn in veel gevallen gebaseerd op service libraries zoals BISL, ASL en ITIL. Bovenstaand neemt niet weg dat de betrokken beheerders in veel gevallen een heel goed beeld hebben van de knelpunten in de te modelleren organisatie en haar ondersteunende ICT. Tijdens de beheerfase van een ICT landschap komen de knelpunten van de ingezette software- en infrastructuurcomponenten pas goed aan de orde. Bijvoorbeeld omdat er veel klachten binnenkomen over applicatie componenten. Denk echter ook aan problemen van beschikbaarheid en performance rond verschillende onderdelen. Deze worden als eerste structureel geconstateerd door de beheerorganisatie. Daarnaast zijn de beheeractiviteiten feitelijk (door de afwijkende taken en processen) geen onderdeel van de enterprise. Dat maakt ze een soort van buitenstaander die daardoor in staat zijn een onafhankelijke visie te vormen. 2.2 Aspecten van de beheerorganisatie Zien we bij architectuur de focus veelal liggen op aspecten van vernieuwing en optimalisatie. Bij ontwikkelaars van software zien we een duidelijke overeenkomst met deze focus, met name gericht op optimalisatie. Beheerders hebben echter focus op hele andere aspecten van het ICT landschap. Onderstaande opsomming geeft een beeld: Continuiteit Van ICT voorzieningen wordt verwacht dat deze beschikbaar zijn op het moment dat de afnemers van de diensten van deze voorzieningen dat verwachten. Dat stelt eisen aan de 2

3 configuratie van het ICT landschap maar ook aan de implementatie van de afzonderlijke onderdelen. Reductie van complexiteit Een grote complexiteit van het ICT landschap stelt extra eisen de beheerorganisatie, bijvoorbeeld op het vlak van kennisontwikkeling, inrichting beheerprocessen en op het vlak beheeractiviteiten. Bijvoorbeeld een ICT landschap dat in hoge mate gestandaardiseerd is op het vlak van technologie (zoals één database platform) zal de introductie van een implementatie met een afwijkend platform proberen te voorkomen. Reden is dat dit afwijkende component een onevenredige eis stelt aan de beheerorganisatie. Risicoreductie Naast continuïteit in de dagelijkse uitvoering zie je dat lange termijn continuiteit een belangrijk aandachtspunt is voor de beheerorganisatie. Men zal dus veelal zoeken naar componenten die toekomstzeker zijn. Daartoe wordt bijvoorbeeld gekeken naar de leveranciers rond een component. Leveranciers op het vlak van opleidingen, ondersteuning en toekomstige releases. Hiermee wordt voorkomen dat in een later stadium de continuïteit van de ICT dienstverlening in het gevaar komt of dat onevenredige kosten gemaakt moeten worden voor het beheer van componenten. Kostenaspecten In bovenstaande punten is reeds een aantal keren het kostenaspect genoemd. Een slecht beheerd en divers ICT landschap is naast de andere aspecten veelal duur. Bijvoorbeeld omdat er meer personen ingezet moeten worden om de componenten beschikbaar te houden, maar ook doordat bijvoorbeeld vaker updates en releases nodig zijn. Ook is het op peil houden van het kennisniveau van een divers ICT landschap veelal duurder dan een homogene inrichting. Uit bovenstaande punten blijkt dat de beheerorganisatie hele andere criteria hebben voor de componenten in een ICT landschap. Neem daarnaast de afwezig dat het beheren van ICT componenten veelal vele malen duurder is dan het ontwikkelen van deze componenten. Gevolg is dat de beheeraspecten een interessante oplossingsrichting zijn om ICT architectuur te optimaliseren op het vlak van risico s en kosten. 3 Concerns, principes en requirements 3.1 Indeling van de concerns Concerns, principes en requirements zijn binnen Togaf verschillende views op de requirements die betrokken stakeholders stellen aan het applicatie en ICT landschap. Bij het uitwerken van een architectuur zijn deze requirements een belangrijk uitgangspunt voor de selectie van de verschillende onderdelen. Want afhankelijk van het belang van een requirement zal het ene ICT component beter toepasbaar zijn dan het andere. Bijvoorbeeld voor alle betrokken stakeholders geldt dat de kosten van de voorgestelde oplossing zo laag mogelijk zijn. Voor de keuze van het database platform is dan MySQL een interessantere keuze ten opzichte van bijvoorbeeld SQL-server of Oracle vanwege licentiekosten. Echter andere concerns zoals bijvoorbeeld beschikbaarheid en schaalbaarheid zijn in sommige situaties eveneens belangrijke concerns. Gevolg is dat een afweging gemaakt moet worden welk concern het zwaarst wegend is. Om bovengenoemde afweging te kunnen maken is het noodzakelijk om verschillende concerns te gaan kwantificeren en op basis van deze kwantitatieve analyse deze 3

4 vergelijking te onderbouwen. In het volgende hoofdstuk wordt een uitwerking gegeven waarbij op basis van checklists gevraagd wordt aan de relevante stakeholders wat hun oordeel is over de score voor architectuur componenten voor een concern. In onderstaande paragraaf zijn een aantal voorbeelden van concerns beschreven. 3.2 Voorbeelden concerns Concerns liggen voor allen stakeholders op een ander vlak. Zo zullen gebruikers van de systemen concerns hebben op het vlak van gebruikersvriendelijkheid, gebruiksgemak en het ondersteunen van de werkzaamheden. Voor stakeholders betrokken bij informatiebeveiliging liggen de concerns met name op het vlak van beveiliging en beveiligingsrisico s. Voor de beheerorganisatie zijn met name non functionele aspecten als beschikbaarheid, beheerbaarheid en uitbreidbaarheid van groot belang. Hieronder een aantal relevante concerns voor stakeholders uit de beheerorganisatie. Nogmaals wordt benadrukt dat de inperking voor de beheerorganisatie een keuze is voor het ARE project. Concerns kunnen voor alle stakeholders bepaald en gekwantificeerd worden. Kosten Kosten, maar ook de opbrengsten van de componenten in een architectuur zijn vanzelfsprekend voor een groot aantal stakeholders belangrijke concerns. Een onbeperkt budget voor ICT komt niet vaak voor. Toch zie je bij de uitwerking van een architectuur dat het kostenaspect niet of maar ten dele aan de orde komt. Wordt er gekeken naar de kosten, dan zie je veelal dat dit beperkt blijft tot de initiele kosten zoals ontwikkel- en licentiekosten. Beheer- en migreerkosten zijn lastiger te berekenen en worden daarom regelmatig buiten beschouwing, of er wordt een vuistregel toegepast. Non functionals Functionele requirements zijn door stakeholders meestal wel te benoemen. Een deel van de non functionele aspecten worden vaak genoemd zoals beschikbaarheid en performance. Een goed uitgangspunt bij het uitwerken van non functionele requirements is de standaard norm ISO 9126 en de uitbreiding Quint 2 genaamd. Deze non functionele eisen kunnen goed gebruikt worden voor een inventarisatie van de concerns in combinatie met een gedetailleerde verdeling van wegingsfactoren. Software volwassenheid Een minder voor de hand liggende concern is de volwassenheid van de organisatie rond componenten. Hiermee kun je in kaart brengen hoe toekomstvast een bepaald component is. Selecteer je bijvoorbeeld een toepassing die ontwikkeld en beheerd wordt door slechts één persoon waarbij de broncode niet vrijgegeven is heeft grotere volwassenheidsrisico s dan een component dat in een veelgebruikte ontwikkelomgeving is ontwikkeld en waarvan de broncode wel beschikbaar is. Beheerlibraries Een categorie alleen relevant voor beheerorganisatie zijn de beheerprocessen in libraries zoals ITIL, ASL en BISL. Deze libraries beschrijven de beheerprocessen vanuit een verschillend beheerperspectief. Risico s hierbij liggen op het vlak van ontbreken van de inrichting van deze beheerprocessen of dat deze processen wel ingericht zijn maar dat de inrichting onvoldoende in staat is om aan de vraag vanuit de organisatie te voldoen. Hierbij speelt 4

5 vanzelf ook de beheerbehoefte van de verschillende ICT componenten een rol. Denk bijvoorbeeld aan de keuze voor een divers of homogeen applicatielandschap. 5

6 4 Risico inventarisatie en interacties Risico inventarisatie is een relatief onbekend fenomeen binnen enterprise architectuur. Binnen de beheerlibraries wordt al iets meer gedaan aan risico analyse, bijvoorbeeld door het toepassen van acceptatiecriteria. De wijze waarop risico inventarisatie kan worden ingezet binnen architectuur wordt beschreven in deze paragraaf. Hierbij worden een aantal voorbeelden van inventarisaties genoemd, echter de uitwerking is niet uitputtend. Hierbij is het aanpassen van de interacties aan de specifieke situatie voor een inventarisatie van groot belang. 4.1 Verschillen in risico inventarisatie Bij het doen van risico inventarisaties zijn verschillen in de opzet van groot belang voor de uitwerking. Een veelgebruikte indeling is de volgende: 6 Test, bij non functionele meetbare requirements wordt bijvoorbeld gemeten of aan de eis wordt voldaan, zoals performance en beschikbaarheid Review, bij non functionals zoals uitbreidbaarheid, herbruikbaarheid en onderhoudbaarheid een veel toegepaste werkwijze Checklist, vragenlijsten en checklists om te controleren of aan de gestelde eis is voldaan. Vanuit architectuur kunnen de volgende verschillende viewpoints genoemd worden: Inventarisatie van de risico in de baseline architectuur. Hierbij wordt gekeken naar welke risico s er zijn voor de huidige inrichting. Men zal in deze situatie veelal kijken voor welke componenten in de architectuur het risico het hoogst of laagst is in de bestaande situatie. Inventarisatie van de risico s in de target architectuur. Men kan in dat geval enerzijds kijken naar welke componenten in de toekomstige situatie het meeste risicovol zijn. Een andere mogelijkheid is een analyse van een target architectuur waarbij de risico s van de baseline architectuur het meest gereduceerd worden. De roadmap inventarisatie, hierbij brengt men in kaart wat de grootste verschillen zijn om de risico s van de baseline binnen target architectuur te reduceren in de target architectuur. Een grote inspanning per component heeft dan een grote impact en vormt dan een groter risico. Bij het uitwerken van risico inventarisaties zijn verschillende vormen te vinden. Een veel voorkomende werkwijze is bijvoorbeeld het opgeven van verschillende elementen en deze vervolgens te sommeren. Denk bijvoorbeeld aan het in kaart brengen van de kosten voor een bepaald component of een cluster van componenten. Een andere uitwerking is het combineren van een waardering en een score. Men scoort een component en deze score wordt vermenigvuldigd met een waardering, op basis van deze berekening kan een sommering gemaakt worden van deze berekening. Hierbij wordt een onderscheid gemaakt tussen een negatieve en een positieve sommering. Dit is gerelateerd aan de inventarisaties zoals genoemd in bovenstaande opsomming een relevante werkwijze. Bij een positief gestelde analyse zal gezocht worden naar een zo hoog mogelijk uitkomst van de score, bij een negatieve opzet is het realiseren van een zo laag mogelijke score een positief resultaat. Een meer complexe vorm is inventarisatie die gebaseerd is op eigen formules. Hierbij kunnen negatieve en positieve aspecten met elkaar gecombineerd worden en is in de ene situatie de waardering negatief en in de andere positief. Ook de uitwerking van de overall berekening kan in deze anders zijn dan een sommering. Denk bijvoorbeeld aan een sommering van de positieve onderdelen verminderd met de

7 negatieve onderdelen of het berekenen van verschillen tussen vragen en een groot verschil tussen de beantwoording positief of negatief te beoordelen. 4.2 Interactievormen Risico inventarisaties onderscheiden zich in twee interactievormen: Directe interactie, de stakeholder wordt rechtsreeks bevraagd door de architect. Veelal door middel van checklists, enquetes en vragenlijsten Indirecte interactie, de stakeholders worden bevraagd door de architect in de vorm van interviews of workshops, vervolgens bepaald de architect de risico score op basis van de uitkomsten van de toegepaste interactievorm, bijvoorbeeld bij reviews. Directe interactievormen Checklists en vragenlijsten, de meest voor de hand liggende vorm van interactie. Men stelt een aantal vragen op en de beantwoording van deze vragen bepaald in welke mate het risico geanalyseerd wordt. Bijvoorbeeld zoals hierboven genoemd met een positieve of negatieve inventarisatiewijze. Hierbij kunnen verschillende presentatievormen gebruikt worden voor het bepalen van de score voor een vraag. Zoals keuzelijsten, sliders of grafische weergaven zoals stoplichten of smileys e.d.. In onderstaande afbeelding een voorbeeld van deze interactie. Afbeelding Berekeningen en calculaties, zeker bij een kwantitatieve analyse van bijvoorbeeld kosten, opbrengsten, rendement of andere financiële aspecten van een inrichting. Invulling van deze onderdelen biedt dan vervolgens de mogelijkheid om uit te rekenen wat de financiele 7

8 risico s zijn van een architectuur configuratie. Onderstaande afbeelding geeft een voorbeeld van deze vorm. Afbeelding Score en sorteringen, Bij een analyse kan men een groep van verschillende entiteiten laten sorteren voor één of meerdere risico s. Op een as zet men aan de ene kant aan dat het risico hoog is en aan de andere kant of het risico laag is. Vervolgens laat men de stakeholder de verschillende componenten op deze as afbeelden waarmee men aangeeft welk een hoog en welk een laag risico betreft. In onderstaande afbeelding een voorbeeld. 8

9 Afbeelding Matrices, bovenstaande interactievormen hebben als nadeel dat men twee dimensies onderscheid, de componenten en de risico s, maar dat men bij één van de dimensies slechts één onderdeel kan uitwerken. Of men heeft meerdere componenten gerelateerd aan één risico of omgekeerd. In een aantal gevallen kan het verhelderend werken voor de stakeholder om het verband te zien tussen meerdere componenten en meerdere risico s. Dit kan men doen door het toepassen van een matrix waarbij op de ene as de componenten worden afgebeeld en op de andere risico s. Zie bijvoorbeeld onderstaande afbeelding. 9

10 Afbeelding Indirecte interactievormen Interviews, bij een interview worden de stakeholders geïnterviewd door de architect. Dit kan in groepen of in één op één vraaggesprekken. Het voordeel van de werkwijze is dat men specifiek in kan gaan op de antwoorden die gegeven worden tijdens het interview op de vragen. Op basis van deze antwoorden kan ook een detaillering gemaakt worden op niet vooraf bepaalde risico s. Het is een krachtige interactievorm die echter wel als nadeel heeft arbeidsintensief en duur te zijn. Workshops, een bijzondere vorm van interviews is het werken met workshops. Hierbij wordt gewerkt met groepen van stakeholders die binnen een workshop met elkaar interacteren om de risico s te bepalen. Vaak wordt er gezocht naar een combinatie van indirecte en directe werkvormen. Indirect is bijvoorbeeld het opsplitsen in kleine werkgroepen en vervolgens in een groepssessie de uitkomsten te bespreken. Vaak wordt het relateren van korte omschrijvingen van risico s op basis van Brown paper sessies gebruikt. Hierbij zie je vaak dat de interactie onderling de uitkomsten binnen de groep bepalen. Dit kan een positief maar ook een negatief effect hebben. Deze vorm is minder arbeidsintensief dan het doen van interviews maar vraagt vaardigheden van de architect in het begeleiden van deze workshops Score sessies, Een nog specifiekere vorm van interactie zijn scoresessies. In workshop vorm worden risico s in kaart gebracht. Vervolgens wordt per risico of component bepaald welke de hoogste of laagste score heeft. Hierbij kan men bijvoorbeeld kiezen voor het verdelen van een beperkt aantal scorepunten over de desbetreffende onderdelen. Een andere vorm is het in volgorde zetten van onderdelen in workshop opzet. Een bijzondere vorm, veel in agile omgevingen gebruikt, is een vorm van poker. Deze vorm van risico poker is om de deelnemers per component een kaart te laten neerleggen. Een 10

11 kaart met een laag getal betekent een laag risico, een hoog getal een hoog risico. Vervolgens lichten de deelnemers met de meest extreme score (positief en negatief) de afgegeven score toe. Combinaties van directe en indirecte interacties, bovengenoemde directe en indirecte vormen van interactie kunnen vanzelfsprekend op allerlei wijzen met elkaar gecombineerd worden. Bijvoorbeeld in eerste instantie een beeld vormen van de risico s op basis van vragenlijsten en checklist. Vervolgens kan op basis van deze uitkomsten een interactieve sessie met de stakeholders worden georganiseerd of vraagt men aan een deel van de betrokkenen om de uitkomsten te scoren. In bovenstaande beschrijving zijn een aantal interactievormen genoemd, echter dit is slechts een klein voorbeeld van de vele interactievormen die ingezet kunnen worden voor het inventariseren van de risico s 4.3 Are checklists en vragenlijsten Het kunnen doen van risico inventarisaties binnen een architectuur is een belangrijk onderdeel in de implementatie binnen de Archimate Risico Extensie. Enerzijds is het de module die zorgdraagt voor het kwantificeren van risico s en het relateren van deze kwantificatie aan de diverse architectuur elementen. Anderzijds is het een uitwerking van verschillende checklists en vragenlijsten die van waarde zijn bij het bepalen van architectuur risico s. Bij de uitwerking van ARE is een prototype ontwikkeld in de vorm van een eenvoudige webapplicatie. Deze webapplicatie kent een aantal modulen waarvan de checklist of enquete module een is. In deze module is het mogelijk om eenvoudige checklists te registreren en toe te wijzen aan relevante stakeholders. Vervolgens worden deze stakeholders uitgenodigd via deze checklist in te vullen. Deze laatste activiteit wordt ook ondersteund in het het prototype. Implementatie Implementatie van de chelcklistmodule bestaat uit een data georiënteerde webapplicatie. Dit houdt in dat er een eenvoudige gebruikersinteractie is die het mogelijk maakt om de gegevens omtrent de entiteiten binnen de checklistmodule te beheren. Gezien de opzet van het bedrijfsproces is niet gekozen voor een implementatie in de vorm van een werkprocesondersteuning. Gevolg is dat de schermen zijn gebaseerd op lijst detail interactiepatronen, waarbij via de detail interactie de gegevens van de entiteiten gemuteerd worden. In onderstaande afbeelding ziet u een voorbeeld van de webinterface 11

12 Afbeelding Ten behoeve van het invullen en verwerken van de checklists is de opbouw van de toepassing iets verder uitgewerkt. De in de databank opgeslagen checklist gegevens worden omgezet naar verschillende soorten checklist. De beheerder van de toepassing heeft de mogelijkheid de samenstelling van de vragen en evaluaties aan te passen en uit te breiden waarmee het zonder de inzet van technische expertise mogelijk is om deze beheertaken uit te voeren. Op dit moment zijn een beperkt aantal checklist implementaties mogelijk, te weten: Sommeren van antwoorden Vermenigvuldigen van waardering en score Formuleberekening Hiermee worden de directe interactievormen checklists en berekeningen geimplementeerd. Deze checklists worden dynamisch samengesteld en in de module gepresenteerd aan de gebruiker. Deze kan de vragen beantwoorden en verzenden naar de toepassing. Daar wordt vervolgens de score berekend. Objectmodel 12

13 Het objectmodel van de checklist bestaat uit de volgende entiteiten Checklist, beschrijving van het soort checklist, inclusief omschrijving voor de eindgebruiker. Daarnaast wordt hier de relatie naar de concerns van de stakeholder gelegd Vraag, eigenschappen van de vraagstelling, antwoordkeuzes, soort besturingselement en validatie Evaluatie, instantie van een checklist voor één specifieke stakeholder. Aan deze evaluaties worden de antwoorden op de vragen gerelateerd Antwoord, instantiatie en dus beantwoording van vragen door een stakeholder Evaluatie_element, koppeling tussen evalutie en architectuur element. Hiermee kunnen de behaalde scores gekoppeld worden aan de architectuur elementen. In onderstaande afbeelding een uitwerking van de objecten en hun onderlinge relaties. Architectuur proces Het proces dat ondersteunt wordt binnen het Are project omvat enerzijds de analyse van de concerns van stakeholders binnen ICT beheer. Stakeholders betrokken bij ICT beheer hebben concerns op het vlak van ICT kosten en opbrengsten, risico s op het vlak van non functionele requirements zoals performance en beschikbaarheid en dergelijke. Anderzijds wordt aandacht besteedt aan de modelleerwerkzaamheden van enterprise architecten. Dit wordt samengevoegd tot een uitbreiding van de Archimate taal waarbij in de diagrammen een extra dimensie wordt toegevoegd. Deze dimensie omvat een weergave van de risicodimensie voor de structurele elementen. Indien mogelijk wordt op basis van infrastructuur- en applicatieservices een extra ontsluiting toegevoegd aan de archimate taal. 13

14 Processen zijn uitgewerkt op basis van Togaf ADM. In onderstaande afbeeldingen wordt getoond binnen welke fasen van het ADM de risico inventarisatie wordt toegepast. Daarnaast worden ook de activiteiten benoemd relevant voor deze extensie in onderstaande afbeelding. Afbeelding Togaf ADM Risico inventarisaties worden voornamelijk uitgevoerd in de fasen van het uitwerken van de architecturen. Dit geldt zowel voor de baseline als de target architectuur. Hierbij is de risico inventarisatie een extra dimensie van de architectuur die uitgewerkt wordt en gerelateerd aan de architectuur elementen in de uitwerking. Dit proces wordt vanzelfsprekend gevoed door de requirements en concerns die door de beheerders zijn geformuleerd. Deze requirements worden gevoed door veranderingen in de omgeving, de beheerprocessen en de overige ontwikkelingen binnen de organisatie. 14

15 5 Tot slot In dit artikel is het inventariseren van risico s aan de orde gekomen. Hierbij is ingegaan op een aantal risico s die onderkend worden bij het beheren van een ICT landschap. Aspecten als toekomstvastheid, beheerprocessen en non functionele requirements zijn hierbij benoemd. Vanzelfsprekend is dit een beperkte set van risico s binnen de beheerorganisatie. De webtoepassing ingericht voor dit project biedt de mogelijkheid om zelf de risico inventarisatie uit te breiden. Daarnaast moet benadrukt worden dat deze werkwijze niet enkel toepasbaar is voor de stakeholders binnen de beheerorganisatie. Ook voor andere stakeholders kan het interessant zijn om risico s te inventariseren met behulp van checklists en vragenlijsten. Dit op vergelijkbare wijze als hierboven beschreven. Laatste aandachtspunt is dat in dit artikel alleen de risico inventarisatie en het verzamelen van gegevens aan de orde is gekomen. Net zo belangrijk als het verzamelen van de gegevens is het presenteren van de uitkomsten binnen een architectuur notatiewijze. Hierover is op de Are website een artikel te vinden. 15

De beheerrisico s van architectuur

De beheerrisico s van architectuur De beheerrisico s van architectuur Een overzicht van de ArChimate Risico Extensie versie 0.2 Bert Dingemans Inleiding Het implementeren van een (enterprise) architectuur brengt altijd risico s met zich

Nadere informatie

Archimate risico extensies modelleren

Archimate risico extensies modelleren Archimate risico extensies modelleren Notatiewijzen van risico analyses op basis van checklists versie 0.2 Bert Dingemans 1 Inleiding Risico s zijn een extra dimensie bij het uitwerken van een architectuur.

Nadere informatie

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans

Business Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum

Nadere informatie

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans

Canonieke Data Modellering op basis van ArchiMate. Canonieke Data Modellering op basis van Archimate Bert Dingemans Canonieke Data Modellering op basis van ArchiMate Canonieke Data Modellering op basis van Archimate Bert Dingemans Abstract Modelleren op basis van de open standard ArchiMate is een goed uitgangspunt voor

Nadere informatie

Stakeholder behoeften beschrijven binnen Togaf 9

Stakeholder behoeften beschrijven binnen Togaf 9 Stakeholder behoeften beschrijven binnen Togaf 9 Inventarisatie van concerns, requirements, principes en patronen Bert Dingemans Togaf 9 kent verschillende entiteiten om de behoeften van stakeholders te

Nadere informatie

De architect twijfelt over een aantal zaken in beide scenario s en stelt daarom voor een aantal analyses te doen, zoals:

De architect twijfelt over een aantal zaken in beide scenario s en stelt daarom voor een aantal analyses te doen, zoals: Kwalitatieve - en kwantitatieve analyses kunnen de dienstverlening van de enterprise-architect verbeteren. Toch is de inzet van deze analysevormen eerder uitzondering dan regel. Hoe kunnen we dit hulpmiddel

Nadere informatie

PProject Start Architectuur (PSA)

PProject Start Architectuur (PSA) PProject Start Architectuur (PSA) Archimate Risico Extensie (Are) versie 0.2 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging 0.1 Juni 2011 Bert Dingemans Geen

Nadere informatie

Keteininformatiemodellering op basis van Archimate

Keteininformatiemodellering op basis van Archimate Keteininformatiemodellering op basis van Archimate Notatie en voorbeelden versie 0.1 Bert Dingemans Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 Archimate... 3 Domeininformatiemodellen... 4 Modellering...

Nadere informatie

Project Start Architectuur (PSA)

Project Start Architectuur (PSA) Project Start Architectuur (PSA) InterActory Architectuur Service Orientatie versie 0.2 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging 0.1 Maart 2012 Bert

Nadere informatie

Stakeholders, concerns, principes en patronen in dataarchitectuur. Bert Dingemans

Stakeholders, concerns, principes en patronen in dataarchitectuur. Bert Dingemans Stakeholders, concerns, principes en patronen in dataarchitectuur Bert Dingemans Abstract Veranderingen in en rond organisatie zijn van invloed op de rol van de data-architect. Door deze veranderingen

Nadere informatie

Introductie ArchiMate

Introductie ArchiMate Introductie ArchiMate NAF Insight De Meern, 8 maart 2012 Egon Willemsz, enterprise architect UWV Programma Waarom ArchiMate? Praktijkvoorbeelden Samenvatting concepten Van start met ArchiMate Tot besluit

Nadere informatie

LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software. Versie 1

LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software. Versie 1 LNV architectuurrichtlijnen gelijke geschiktheid Open Source Software Versie 1 2 Gelijkegeschiktheid Inhoud 1 Inleiding 4 1.1 Doelstelling 4 2 Toetsing gelijke geschiktheid 5 2.1 Total Cost of Ownership

Nadere informatie

Tools voor canonieke datamodellering Bert Dingemans

Tools voor canonieke datamodellering Bert Dingemans Tools voor canonieke datamodellering Tools voor canonieke datamodellering Bert Dingemans Abstract Canonieke modellen worden al snel omvangrijk en complex te beheren. Dit whitepaper beschrijft een werkwijze

Nadere informatie

Tien tips voor canonieke datamodellering. Bert Dingemans

Tien tips voor canonieke datamodellering. Bert Dingemans Tien tips voor canonieke datamodellering Bert Dingemans Abstract Modelleren is een vakgebied gebaseerd op eenvoudige notaties. Echter op het moment dat en model opgesteld wordt blijkt de te modelleren

Nadere informatie

Kenmerken van DLArchitect

Kenmerken van DLArchitect Kenmerken van DLArchitect Bert Dingemans, e-mail : bert@dla-os.nl www : http://www.dla-os.nl 1 Inhoud KENMERKEN VAN DLARCHITECT... 1 INHOUD... 2 INLEIDING... 3 ARCHITECTUUR... 3 Merode... 3 Methode en

Nadere informatie

Lifecycle Management: opereren onder architectuur. Jan Willem van Veen jwvveen@archixl.nl

Lifecycle Management: opereren onder architectuur. Jan Willem van Veen jwvveen@archixl.nl Lifecycle Management: opereren onder architectuur Jan Willem van Veen jwvveen@archixl.nl Agenda Introductie mijzelf en ArchiXL Korte inleiding Lifecycle Management methodiek Inzicht in status Inzicht in

Nadere informatie

CMS Ronde Tafel. Cloud Continuity. Ir. Jurian Hermeler Principal Consultant

CMS Ronde Tafel. Cloud Continuity. Ir. Jurian Hermeler Principal Consultant CMS Ronde Tafel Cloud Continuity Ir. Jurian Hermeler Principal Consultant Introductie Quint Wellington Redwood Onafhankelijk Management Adviesbureau Opgericht in 1992 in Nederland Ruim 20 jaar ervaring

Nadere informatie

Genereren van een webapplicatie op basis van DLA

Genereren van een webapplicatie op basis van DLA Genereren van een webapplicatie op basis van DLA ir Bert Dingemans DLA Ontwerp en Software info@dla-architect.nl Inleiding Bij het ontwikkelen van maatwerk software loopt men al snel tegen het probleem

Nadere informatie

De rol van een data-architect. Bert Dingemans

De rol van een data-architect. Bert Dingemans De rol van een data-architect Bert Dingemans Abstract Bij een toenemende volwassenheid van data-architectuur neemt het gebruik van generieke gegevensverzamelingen toe. Deze gegevens worden veelal beheerd

Nadere informatie

ISM: BPM voor IT Service Management

ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management Het jonge IT-vakgebied wordt bestookt met allerlei frameworks om grip te krijgen op de input en output: ITIL, ASL, BiSL, COBIT en

Nadere informatie

Integratie van Beheer en Ontwikkeling op basis van een Drielagenarchitectuur

Integratie van Beheer en Ontwikkeling op basis van een Drielagenarchitectuur Integratie van Beheer en Ontwikkeling op basis van een Drielagenarchitectuur Bert Dingemans info@dla-architect.nl www.dla-architect.nl Inleiding In de sector jeugdzorg zijn momenteel een aantal ingrijpende

Nadere informatie

Vastgoedinformatiesystemen. Thijs van der Spil

Vastgoedinformatiesystemen. Thijs van der Spil Vastgoedinformatiesystemen Thijs van der Spil Wat je wilt voorkomen is een systeem dat niet kan wat je nodig hebt dat veel te duur is in aanschaf of exploitatie dat niet kan meegroeien met je organisatie

Nadere informatie

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.

BISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V. BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2

Nadere informatie

Kwaliteitsbewaking en testen in ICT beheerorganisaties

Kwaliteitsbewaking 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 informatie

Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting

Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting xvii Invloed van IT uitbesteding op bedrijfsvoering & IT aansluiting Samenvatting IT uitbesteding doet er niet toe vanuit het perspectief aansluiting tussen bedrijfsvoering en IT Dit proefschrift is het

Nadere informatie

In een keten gaat het om de verbindingen, niet om de schakels.

In een keten gaat het om de verbindingen, niet om de schakels. Verbindingsmodel IV Serviceketen Theo Thiadens en Adri Cornelissen In een keten gaat het om de verbindingen, niet om de schakels. Verbindingsmodel IV Serviceketen Theo Thiadens Alleen een organisatie die

Nadere informatie

LoopbaanIndicator. Voor een duurzame loopbaanplanning

LoopbaanIndicator. Voor een duurzame loopbaanplanning LoopbaanIndicator Voor een duurzame loopbaanplanning 1. Inleiding LoopbaanIndicator wordt ingezet om alle relevante waarden rondom menselijke inzetbaarheid gestructureerd en genormeerd in kaart te brengen,

Nadere informatie

De complete oplossing voor uw kadastrale informatievoorziening.

De complete oplossing voor uw kadastrale informatievoorziening. De complete oplossing voor uw kadastrale informatievoorziening. Foto: Mugmedia Het Kadaster gaat de levering van kadastrale informatie ingrijpend vernieuwen. Het huidige proces van verwerken van kadastrale

Nadere informatie

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008

Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test

Nadere informatie

Project Fasering Documentatie Applicatie Ontwikkelaar

Project 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 informatie

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten

Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten Verschillen in QA aanpak tussen ERP projecten en niet-erp projecten SYSQA B.V. Almere Datum : 06 mei 2013 Status : definitief Versie : 2.0 Opgesteld door : Organisatie SYSQA B.V. Pagina 2 van 5 Overzicht

Nadere informatie

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert

UML. From weblog http://dsnippert.wordpress.com. Dennis Snippert UML From weblog http://dsnippert.wordpress.com Naam: Dennis Snippert Inhoudsopgave 1. Wat is Uml?... 3 2. UML diagrammen... 4 3. Uitleg diagrammen... 5 3.1. Usecase diagram:... 5 3.2. Class diagram:...

Nadere informatie

BeheerVisie ondersteunt StUF-ZKN 3.10

BeheerVisie 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 informatie

Hoe ver moet je gaan?

Hoe ver moet je gaan? Hoe ver moet je gaan? Requirements verzamelen in agile John Copier; Marcel Steur 8 oktober 2015 Introductie Marcel + Qquest Informatica TU Delft Bedrijfskunde HSA + VU IT combineren met bedrijfskunde Qquest

Nadere informatie

Procesmanagement. Hoe processen beschrijven. Algra Consult

Procesmanagement. Hoe processen beschrijven. Algra Consult Procesmanagement Hoe processen beschrijven Algra Consult Datum: juli 2009 Inhoudsopgave 1. INLEIDING... 3 2. ORGANISATIE VAN PROCESMANAGEMENT... 3 3. ASPECTEN BIJ HET INRICHTEN VAN PROCESMANAGEMENT...

Nadere informatie

Open Source Software community- en teruggave beleid EL&I. Versie 1

Open Source Software community- en teruggave beleid EL&I. Versie 1 Open Source Software community- en teruggave beleid EL&I Versie 1 2 Open Source Software community- en teruggave beleid EL&I Inhoud Inleiding 4 1 Inzet OSS software 4 2 Community beleid 6 2.1 Communitybeleid

Nadere informatie

Cyberpesten: social media platform mining tools

Cyberpesten: social media platform mining tools Cyberpesten: social media platform mining tools ABI team 27: Pascal Pieters, Stephaan Declerck Begeleider: dr. Rik Bos Opdrachtgever: prof. dr. ir. Remko Helms Inhoud Achtergrond Opdracht Projectaanpak

Nadere informatie

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol

Olde Bijvank Advies Organisatieontwikkeling & Managementcontrol SAMENVATTING ITIL ITIL is nog steeds dé standaard voor het inrichten van beheerspocessen binnen een IT-organisatie. En dekt zowel applicatie- als infrastructuur beheer af. Indien gewenst kan ITIL worden

Nadere informatie

Register- en sleutelbeleid Bert Dingemans

Register- en sleutelbeleid Bert Dingemans Register- en sleutelbeleid Register- en sleutelbeleid Bert Dingemans Abstract Bij een toenemende volwassenheid van data-architectuur neemt het gebruik van generieke gegevensverzamelingen toe. Deze gegevens

Nadere informatie

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept.

bedrijfsprocessen en vormt daarmee de kapstok voor de producten van andere disciplines. Het PAM is geen RUP concept. 1. 1.1. Inleiding Doel De Requirementdiscipline richt zich op het vaststellen en vastleggen van de eisen en wensen die aan een oplossing worden gesteld: de requirements. Rollen De keyrol binnen deze discipline

Nadere informatie

5 Programmastructuur

5 Programmastructuur 5 Programmastructuur Om het informatieplan en de daarin beschreven componenten is het aan te raden een programma- en projectenorganisatie in te richten. Volgend schema geeft de verschillende actoren en

Nadere informatie

Roadmap. RIE Manager

Roadmap. RIE Manager Roadmap RIE Manager Look & Feel Rapportage/ Documentatie Uploaden Documenten Major Release 3 Lokaal beheer Major Release 2 Regie in eigen hand Submodules Major Release 1 Introductie In deze roadmap geeft

Nadere informatie

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

ICT 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 informatie

Functiebeschrijving Technische Architect

Functiebeschrijving Technische Architect Functiebeschrijving 1. Algemene Gegevens Organisatie Functienaam Versie Auteur : [naam organisatie] : : 1.0 concept : Ad Paauwe a. Plaats in de organisatie De rapporteert aan de manager van het architectuurteam.

Nadere informatie

Agenda 26-4-2009. Wat zijn de gevolgen van Cloud en Gridcomputing voor de gebruikersorganisatie en de beheersfunctie.

Agenda 26-4-2009. Wat zijn de gevolgen van Cloud en Gridcomputing voor de gebruikersorganisatie en de beheersfunctie. Wat zijn de gevolgen van Cloud en Gridcomputing voor de gebruikersorganisatie en de beheersfunctie. John Lieberwerth Agenda Even voorstellen Cloud Computing De tien Plagen Gebruikersorganisatie en ICT

Nadere informatie

Het gevolg van transitie naar de cloud SaMBO-ICT & KZA. 16 januari 2014 Doetinchem

Het gevolg van transitie naar de cloud SaMBO-ICT & KZA. 16 januari 2014 Doetinchem Het gevolg van transitie naar de cloud SaMBO-ICT & KZA 16 januari 2014 Doetinchem Agenda Introductie Aanleiding Samenvatting handreiking Uitkomsten workshop netwerkbijeenkomst Afsluiting 2 Introductie

Nadere informatie

Canonieke datamodellering in de praktijk

Canonieke datamodellering in de praktijk Canonieke datamodellering in de praktijk Bert Dingemans Samenvatting Canonieke datamodellering kent vele dimensies en toepassingswijzen. Maar hoe is dit in de praktijk inzetbaar? Dit whitepaper gaat in

Nadere informatie

Gezamenlijke procesinrichting binnen de jeugdzorg

Gezamenlijke procesinrichting binnen de jeugdzorg Gezamenlijke procesinrichting binnen de jeugdzorg Samenvatting Dit artikel beschrijft de ervaringen in het project gezamenlijke proces inrichting binnen de jeugdzorg. Het is geschreven vanuit een software

Nadere informatie

Canonieke data-architectuur Bert Dingemans

Canonieke data-architectuur Bert Dingemans Canonieke data-architectuur Canonieke data-architectuur Bert Dingemans Abstract Deze whitepaper beschrijft diverse aspecten van canonieke data-architectuur. Naast de definitie van canonieke data-architectuur

Nadere informatie

Tussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011

Tussenrapportage 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 informatie

Architectuurredeneermodel Afgewogen keuzes maken

Architectuurredeneermodel Afgewogen keuzes maken Architectuurredeneermodel Afgewogen keuzes maken Robert Deckers SASG okt 2012 v3 Architectuur: technologie in perspectief Klantbehoefte Toepassing Systeem T 2 Vele wegen die naar ergens leiden Bewuste

Nadere informatie

Offective > CRM > Vragenlijst

Offective > CRM > Vragenlijst Offective > CRM > Vragenlijst Onder het menu item CRM is een generieke vragenlijst module beschikbaar, hier kunt u zeer uitgebreide vragenlijst(en) maken, indien gewenst met afhankelijkheden. Om te beginnen

Nadere informatie

Toegepaste notatiewijzen DLA software

Toegepaste notatiewijzen DLA software Toegepaste notatiewijzen DLA software Bert Dingemans info@dla-architect.nl Inleiding In de DLA Software wordt gebruik gemaakt van een aantal notatiewijzen voor het opstellen van een object- en procesmodel.

Nadere informatie

Bedrijfsarchitectuur sterker door opleiding

Bedrijfsarchitectuur sterker door opleiding Onderzoek naar het effect van de Novius Architectuur Academy Bedrijfsarchitectuur sterker door opleiding Door met meerdere collega s deel te nemen aan een opleiding voor bedrijfsarchitecten, werden mooie

Nadere informatie

Leones. Business Case Service Management Tool

Leones. Business Case Service Management Tool Leones Business Case Service Management Tool Inhoudsopgave 1. AFBAKENING... 3 1.1 DOEL... 3 1.2 AANNAMES... 3 1.3 HUIDIGE SITUATIE... 3 1.4 PROBLEEMSTELLING... 3 1.5 WAT ALS ER NIETS GEBEURT?... 3 2. OPTIES...

Nadere informatie

Syllabus FSM Introductietraining Structuur en doelen

Syllabus FSM Introductietraining Structuur en doelen Syllabus FSM Introductietraining Structuur en doelen Datum: 12-03-2014 Versie: 1.1 Functional Service Management Inhoud De FSM Introductietraining... 3 Doelgroep... 3 Leerdoelen... 3 Inhoud... 3 Werkvormen...

Nadere informatie

Centrale Voorziening Decentrale Regelgeving

Centrale Voorziening Decentrale Regelgeving Centrale Voorziening Decentrale Regelgeving Aansluiten op de CVDR. Inhoudsopgave Centrale Voorziening Decentrale Regelgeving...1 Introductie...2 De wettelijke standaard...2 Twee invoeropties...2 Invoeroptie

Nadere informatie

Informatiebeveiliging voor de requirementsanalist

Informatiebeveiliging voor de requirementsanalist voor de requirementsanalist SYSQA B.V. Almere Datum : 15 april 2013 Versie : 1.0 Status : Definitief Opgesteld door : Organisatie: SYSQA BV Pagina 2 van 11 Inhoudsopgave Inhoudsopgave... 2 1 Inleiding...

Nadere informatie

Ronde Tafel Hergebruik en uitwisseling van software bij het Rijk'

Ronde Tafel Hergebruik en uitwisseling van software bij het Rijk' Ronde Tafel Hergebruik en uitwisseling van software bij het Rijk' 29 januari 2013 Agenda 1) Uitgangssituatie 2) Voorlopige resultaten inventarisatie 3) (markt)ontwikkelingen 4) Wat is het vraagstuk? 5)

Nadere informatie

5 Opstellen businesscase

5 Opstellen businesscase 5 Opstellen In de voorgaande stappen is een duidelijk beeld verkregen van het beoogde project en de te realiseren baten. De batenboom geeft de beoogde baten in samenhang weer en laat in één oogopslag zien

Nadere informatie

PHP-OPDRACHT SITE BOUWEN

PHP-OPDRACHT SITE BOUWEN PHP-OPDRACHT SITE BOUWEN PERIODE 4 LEERJAAR 1 Opleiding: Duur: Applicatieontwikkelaar 1 onderwijsperiode (4-8 weken) Voorkennis: Basiscursus PHP 5.4 Victor Peters (978 90 125 8499 9) Basiscursus XHTML,

Nadere informatie

Containermanagement. Fotobijschrift Schematisch overzicht WinConsyst WMSbeheersoftware. Pagina 28 van 39

Containermanagement. Fotobijschrift Schematisch overzicht WinConsyst WMSbeheersoftware. Pagina 28 van 39 Containermanagement Met de functionele WinConsyst WMS-beheersoftware verkrijgt u een multifunctioneel platform dat schaalbaar is u een groeimodel biedt voor de toekomst. U gebruikt alleen die functionaliteit

Nadere informatie

kwaliteitsmeterplus 4

kwaliteitsmeterplus 4 kwaliteitsmeterplus 4 Testen voor de toekomst Eenvoudig en intuïtief Werkproces georiënteerd Scheiding bevindingen en issues Hertest methode Schermafdruk en -opnames SaaS Open platform kwaliteitsmeterplus

Nadere informatie

Impressie ICT Benchmark Gemeenten 2012 Inzicht in prestaties door benchmarking van ICT-kosten met andere gemeenten

Impressie ICT Benchmark Gemeenten 2012 Inzicht in prestaties door benchmarking van ICT-kosten met andere gemeenten Impressie ICT Benchmark Gemeenten 2012 Inzicht in prestaties door benchmarking van ICT-kosten met andere gemeenten Impressie ICT Benchmark Gemeenten 2012 Inzicht in prestaties door benchmarking van ICT-kosten

Nadere informatie

Digikoppeling adapter

Digikoppeling adapter Digikoppeling adapter Versie 1.0 Datum 02/06/2014 Status Definitief Van toepassing op Digikoppeling versies: 1.0, 1.1, 2.0, 3.0 Colofon Logius Servicecentrum: Postbus 96810 2509 JE Den Haag t. 0900 555

Nadere informatie

Een overzichtsraamwerk voor beheermethoden

Een overzichtsraamwerk voor beheermethoden Een overzichtsraamwerk voor beheermethoden De enorme ontwikkeling die het beheer van ICT in de afgelopen jaren doormaakt, heeft een scala aan beheermethoden opgeleverd. Het gaat om een groot aantal methoden

Nadere informatie

Last but not least. Hoofdstuk 35. Bijlagen

Last but not least. Hoofdstuk 35. Bijlagen Last but not least Hoofdstuk 35 Bijlagen V1.2 / 01 februari 2016 Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van

Nadere informatie

Hoe haalt u het maximale rendement uit uw WMS? Arjen Lagerweij a.lagerweij@evo.nl +31 6 2191 7307

Hoe haalt u het maximale rendement uit uw WMS? Arjen Lagerweij a.lagerweij@evo.nl +31 6 2191 7307 Hoe haalt u het maximale rendement uit uw WMS? Arjen Lagerweij a.lagerweij@evo.nl +31 6 2191 7307 Wat gaan we doen? 1. Introductie 2. Wat willen we bereiken met WMS? 3. Voorbereiding aanschaf WMS 4. Samenvatten

Nadere informatie

Resultaten EAM Barometer 2010

Resultaten EAM Barometer 2010 1 van 14 Resultaten EAM Barometer 2010 Beschikt Onderhoudend Nederland over een onderhoudsbesturingssysteem? Onderdeel Opgenomen Toelichting Rappotage resultaten onderzoek Individuele resultaten deelnemer

Nadere informatie

MVO-Control Panel. Instrumenten voor integraal MVO-management. Intern MVO-management. Verbetering van motivatie, performance en integriteit

MVO-Control Panel. Instrumenten voor integraal MVO-management. Intern MVO-management. Verbetering van motivatie, performance en integriteit MVO-Control Panel Instrumenten voor integraal MVO-management Intern MVO-management Verbetering van motivatie, performance en integriteit Inhoudsopgave Inleiding...3 1 Regels, codes en integrale verantwoordelijkheid...4

Nadere informatie

Rapportage Lineage. Introductie. Methode. J. Stuiver

Rapportage Lineage. Introductie. Methode. J. Stuiver Rapportage Lineage Rapportage Lineage J. Stuiver Introductie In elk project is het essentieel om informatie over het project en haar activiteiten voor alle partijen beschikbaar te stellen. Deze informatie

Nadere informatie

Samenwerken aan goede requirements met UXinstrumenten

Samenwerken aan goede requirements met UXinstrumenten UX Samenwerken aan goede requirements met UXinstrumenten Samenwerking is vaak de sleutel om te komen tot IT-oplossingen waar mensen blij van worden. Als UX Lead bij spir-it (het ICT-bedrijf voor de rechtspraak)

Nadere informatie

Stappenplan Social Return on Investment. Onderdeel van de Toolkit maatschappelijke business case ehealth

Stappenplan Social Return on Investment. Onderdeel van de Toolkit maatschappelijke business case ehealth Stappenplan Social Return on Investment Onderdeel van de Toolkit maatschappelijke business case ehealth 1 1. Inleiding Het succesvol implementeren van ehealth is complex en vraagt investeringen van verschillende

Nadere informatie

14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling

14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Je kunt hier (optioneel) ook een gratis tool downloaden

Nadere informatie

Registreren, analyseren en verantwoorden

Registreren, analyseren en verantwoorden Registreren, analyseren en verantwoorden Inhoud DAS in het kort DAS in het kort 3 De voordelen voor u 4 Effecten meten 4 Uw opdracht verantwoorden 5 Werkwijze methodiseren 6 Samenwerking bevorderen 7 Kosten

Nadere informatie

Sparse columns in SQL server 2008

Sparse columns in SQL server 2008 Sparse columns in SQL server 2008 Object persistentie eenvoudig gemaakt Bert Dingemans, e-mail : info@dla-os.nl www : http:// 1 Content SPARSE COLUMNS IN SQL SERVER 2008... 1 OBJECT PERSISTENTIE EENVOUDIG

Nadere informatie

WHITE PAPER. Agile/Scrum

WHITE PAPER. Agile/Scrum WHITE PAPER Agile/Scrum Belangrijkste kenmerk van Scrum is de ontwikkeling via een serie van korte - iteraties, in Scrum terminologie sprints genoemd. Introductie Heel in het kort gezegd is Scrum een Agile

Nadere informatie

15 Mate van dekkingsgraad, een eerste aanzet tot baten

15 Mate van dekkingsgraad, een eerste aanzet tot baten 15 Mate van dekkingsgraad, een eerste aanzet tot baten Sanneke van der Linden Sinds 2007 organiseert M&I/Partners de ICT Benchmark Ziekenhuizen. Op hoofdlijnen zijn de doelstellingen en aanpak van de ICT

Nadere informatie

ARE methodiek Het ontwikkelen van Informatie Elementen

ARE methodiek Het ontwikkelen van Informatie Elementen ARE methodiek Het ontwikkelen van Informatie Elementen WI1: Het opstarten van het project Milestone 1 WI2: Ontwikkel een Vison WI3: Modelleer het Business Domain WI4: Creëer een Glossary WI7: Beheer wijzigingen

Nadere informatie

Succesvolle toepassing van 360 graden feedback: De keuze van het 360 instrument en de voorbereiding op het 360 traject

Succesvolle toepassing van 360 graden feedback: De keuze van het 360 instrument en de voorbereiding op het 360 traject Succesvolle toepassing van 360 graden feedback: De keuze van het 360 instrument en de voorbereiding op het 360 traject Augustus 2011 Waar werknemers onderdeel zijn van een organisatie, wordt beoordeeld.

Nadere informatie

januari TTNWW Handleiding TST tools voor het Nederlands als Web services in een Workflow Meertens Instituut, Joan Muyskensweg 25, 1096 CJ Amsterdam

januari TTNWW Handleiding TST tools voor het Nederlands als Web services in een Workflow Meertens Instituut, Joan Muyskensweg 25, 1096 CJ Amsterdam januari 2013 TTNWW Handleiding TST tools voor het Nederlands als Web services in een Workflow Meertens Instituut, Joan Muyskensweg 25, 1096 CJ Amsterdam Table of Contents Inleiding... 3 Gebruik van de

Nadere informatie

WAT IS DE FOCUS VAN JE WENS TOT VERBETERING BEHOEFTE BEPALEN INNOVATIEVERKENNER AANLEIDING ACHTERGROND INNOVATIEVRAAG

WAT IS DE FOCUS VAN JE WENS TOT VERBETERING BEHOEFTE BEPALEN INNOVATIEVERKENNER AANLEIDING ACHTERGROND INNOVATIEVRAAG WAT IS DE FOCUS VAN JE WENS TOT VERBETERING BEHOEFTE BEPALEN INNOVATIEVERKENNER AANLEIDING ACHTERGROND INNOVATIEVRAAG WAT IS HET PROBLEEM ACHTER HET PROBLEEM BEHOEFTE BEPALEN 5X WAAROM PROBLEEMSTELLING:

Nadere informatie

Omschrijving enquête module VervangingsManager webapplicatie

Omschrijving enquête module VervangingsManager webapplicatie Omschrijving enquête module VervangingsManager webapplicatie OnderwijsApps B.V. Innovatieweg 26-03 7007 CD DOETINCHEM Tel. 0314-368250 Postbus 704 7000 AS DOETINCHEM KvK 51377888 www.onderwijsapps.nl info@onderwijsapps.nl

Nadere informatie

Architectuur, Organisatie en Business Cases

Architectuur, Organisatie en Business Cases Architectuur, Organisatie en Business Cases Ervaringen uit de praktijk Jan de Baat CMG Trade, Transport & Industry B.V. Inleiding In de Dynamiek track van LAC 2000 is de problematiek omtrent de alignment

Nadere informatie

Procesmanagement. Waarom processen beschrijven. Algra Consult

Procesmanagement. Waarom processen beschrijven. Algra Consult Procesmanagement Waarom processen beschrijven Algra Consult Datum: 22 oktober 2009 Inhoudsopgave 1. INLEIDING... 3 2. WAAROM PROCESMANAGEMENT?... 3 3. WAAROM PROCESSEN BESCHRIJVEN?... 3 4. PROCESASPECTEN...

Nadere informatie

Kwaliteitsmanagement: de verandering communiceren!

Kwaliteitsmanagement: de verandering communiceren! Kwaliteitsmanagement: de verandering communiceren! (de mens in het proces) Ronald Vendel Business Development manager Ruim 20 jaar ervaring Gestart in 1990 Software specialisme: Procesmanagement (BPM)

Nadere informatie

Informatiebeveiliging voor functioneel beheerders. SYSQA B.V. Almere. Datum : 16-04-2013 Versie : 1.0. Opgesteld door :

Informatiebeveiliging voor functioneel beheerders. SYSQA B.V. Almere. Datum : 16-04-2013 Versie : 1.0. Opgesteld door : voor functioneel beheerders SYSQA B.V. Almere Datum : 16-04-2013 Versie : 1.0 Status : Definitief Opgesteld door : Organisatie: SYSQA B.V. Pagina 2 van 11 Inhoudsopgave 1 Inleiding... 3 1.2 Doel en veronderstelde

Nadere informatie

IT beheer: zelf doen is geen optie meer. Ed Holtzer Jurian Burgers

IT beheer: zelf doen is geen optie meer. Ed Holtzer Jurian Burgers IT beheer: zelf doen is geen optie meer Ed Holtzer Jurian Burgers Het leven is te kort om zelf iets te doen wat men tegen betaling ook door anderen kan laten verrichten. William Somerset Maugham Engels

Nadere informatie

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten

8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over

Nadere informatie

Factsheet CMS & DIGITAL MARKETING BEHEER Managed Services

Factsheet CMS & DIGITAL MARKETING BEHEER Managed Services Factsheet CMS & DIGITAL MARKETING BEHEER Managed Services CMS & DIGITAL MARKETING BEHEER Managed Services We zorgen voor een gegarandeerd stabiel, snel en schaalbaar digitaal platform. Efficiënt beheer

Nadere informatie

ITIL en/of eigen verantwoordelijkheid

ITIL en/of eigen verantwoordelijkheid ITIL en/of eigen verantwoordelijkheid Leo Ruijs 20 SEPTEMBER 2011 INNOVATIEDAG MANSYSTEMS Service8 B.V. Stelling ITIL BEPERKT DE EIGEN VERANTWOORDELIJKHEID VAN MEDEWERKERS EN HEEFT DAARMEE EEN NEGATIEVE

Nadere informatie

SWOT - analyse. november 2007 van Dromen naar Scoren 1

SWOT - analyse. november 2007 van Dromen naar Scoren 1 SWOT - analyse Een handige methode om uw organisatie te leren kennen en te kijken waar uw organisatie staat en naartoe moet, is de SWOT-analyse. De vier letters staan voor Strengths, Weaknesses, Opportunities

Nadere informatie

User experience voor projecten

User experience voor projecten User experience voor projecten In de PS module zijn er een aantal nieuwe mogelijkheden beschikbaar voor het werken met projecten. Zo is in EhP 6 de Project Editor uitgebreid met de mogelijkheid om Gannt

Nadere informatie

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International

Succes = Noodzaak x Visie x Draagvlak 2. Case: Implementatie Requirements Lifecycle management bij Rabobank International Succes = x Visie x Draagvlak 2 Case: Implementatie Requirements Lifecycle management bij Rabobank International dinsdag 3 oktober 2006 Spider Congres Agenda Inventarisatie SPI-knelpunten Implementatie

Nadere informatie

20 mei 2008. Management van IT 1. Management van IT. Wat is dat eigenlijk? IT organisaties: overeenkomsten en verschillen

20 mei 2008. Management van IT 1. Management van IT. Wat is dat eigenlijk? IT organisaties: overeenkomsten en verschillen Management van IT Han Verniers PrincipalConsultant Han.Verniers@Logica.com Logica 2008. All rights reserved Programma Management van IT Wat is dat eigenlijk? IT organisaties: overeenkomsten en verschillen

Nadere informatie

De verborgen schatten van ERP Een onderzoek naar ERP-optimalisatie bij middelgrote bedrijven. succeed IT. better results together

De verborgen schatten van ERP Een onderzoek naar ERP-optimalisatie bij middelgrote bedrijven. succeed IT. better results together De verborgen schatten van ERP Een onderzoek naar ERP-optimalisatie bij middelgrote bedrijven succeed IT better results together Een onderzoek naar ERP-optimalisatie bij middelgrote bedrijven in handel

Nadere informatie

Incore Solutions Learning By Doing

Incore 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 informatie