KL Beheer modellen

Inleiding

Na het begin van mijn stage bij de BO GDBK-KL ( Beheer Organisatie Geneeskundige DataBase Krijgsmacht te Amersfoort). Heb ik samen met mijn stage begeleider het onderwerp: KL Beheer modellen. Omdat ik nog niet zo zeer bekend was met de verschillende netwerkbeheer modellen en omdat ze bij het BO GDBK-KL met een combinatie van 2 beheer modellen werken leek het ons wel een leerzaam onderwerp.

Hierbij bedank ik Kapitein Marcel Hovens voor het verschaffen van diverse informatie en de hulp bij het maken van mijn stageverslag zowel als het nakijken en corrigeren ervan.

Amersfoort, februari 2004

Disclaimer

Dit verslag is geschreven in het kader van mijn MBO Stage bij het BO GDBK-KL.De hierin weergegeven meningen komen geheel voor rekening van de auteur, die op het moment van schrijven werkzaam was als Stagiair bij de Beheerorganisatie Geneeskundige Database Krijgsmacht van de Koninklijke Landmacht. De inhoud behoeft niet noodzakelijkerwijs de mening van deze organisatie weer te geven. Gelet op de herkomst van de ITIL methodiek wordt gebruik gemaakt van een aantal Engelse termen. Dit vergroot de leesbaarheid misschien niet, echter, dit soort termen in een gekunstelde vertaling aan te bieden is nog minder gunstig.

1

KL Beheer modellen

Wat is de Beheerorganisatie Geneeskundige Database Koninklijke Landmacht op dit moment.

In de tijd voordat er een nieuwe structuur werd gekozen bij de BO GDBK-KL maakten alle curatieve zorg gebruik van een elektronisch medisch dossier. Op elke locatie maakte men gebruik van een applicaties met een gedistribueerde database. Mutaties in dit systeem werden met een batch procedure in de centrale mainframe database opgenomen.

Doordat er op veel locaties met verouderde techniek werd gecommuniceerd waren er veel punten waarop fouten konden ontstaan. De fouten waren te herstellen maar met een behoorlijke beheer inspanning. Dit probleem is opgelost met de IT infrastructuur van de BO GDBK-KL namens het KL-Zorgnet. Waarin alle Zorg centra en Arbo centra ondergebracht worden in een groot NT Domein. Daarnaast is het oude Elektronisch patiënten dossier vervangen door een Client-Server systeem met een centrale database ( het GDBK VA 7.0 ).Dit verslag gaat over de keuzes die de BO GDBK-KL heeft moeten nemen om het KL-Zorgnet zo te krijgen zoals het nu is. Dit Verslag gaat dus over de opties die er waren en de keuzes die men kan en moet maken bij de keuze van een netwerkbeheer model en een daarbij passende beheertool .

Probleemstelling.

Welke beheermethodiek is het meest geschikt voor het beheer van het KL-Zorgnet en welke gevolgen heeft dit voor het pakket van eisen voor een beheertool?

2

KL Beheer modellen

1 Information Technology Infrastructure Library (ITIL)1.1 Historie

Met de stijgende belangstelling voor IT-beheer in het begin van de jaren ’90 kwam ITIL vanuit Engeland naar Nederland overgewaaid. ITIL werd aan het einde van de jaren ’80 door de UK Central Computer & Telecommunications Agency (CCTA) gepresenteerd als methodiek voor IT-beheer. In de ogen van velen is ITIL inmiddels de de facto standaard voor IT-beheer. Overigens is er vooral in het Verenigd Koninkrijk en Nederland, en in minder mate in België, Duitsland en Frankrijk aandacht voor ITIL. Er is sinds kort een enigszins vernieuwde versie beschikbaar.

1.2 Beschrijving methodiek

1.2.1 Inleiding

Bij het beschrijven van de methodiek zullen in eerste instantie het doel en een aantal eigenschappen van de methodiek behandeld worden. Vervolgens wordt nader ingegaan op de processen waarop de methodiek gebaseerd is. Het gehele hoofdstuk wordt na de inhoudelijke beschrijving van de methodiek afgesloten met het inventariseren van een aantal voor- en nadelen van de methodiek.

1.2.2 Hoofddoel

ITIL op zich is niets meer (maar ook niets minder) dan een stapel boekjes waarin een aantal processen van de methodiek worden beschreven. Al die processen dragen bij aan effectief, efficiënt en kwalitatief goed IT-beheer binnen een organisatie. Hiermee vormen deze processen een soort handvat om het service management van de IT en de IT-infrastructuur binnen een organisatie in te richten. Het hoofddoel van ITIL wordt omschreven als:

‘to facilitate improvements in efficiency and effectiveness in the provision of quality IT services and the management of the IT infrastructure within any organization’.

1.2.3 Eigenschappen

ITIL heeft een viertal kenmerkende eigenschappen. Voorafgaand aan de behandeling van de processen woren deze kort belicht.Om te beginnen is ITIL een raamwerk voor het inrichten van een beheerorganisatie, waarmee tegelijkertijd niet bedoeld wordt dat het als een harnas moet fungeren. Het geeft aan welke processen op enigerlei wijze in de organisatie moeten dan wel kunnen worden belegd. ITIL is nooit een doel op zich.Voorts is ITIL gestoeld op praktijkervaring bij vele ITIL-organisaties. ‘Best practice’ is een term die dan vaak gebruikt wordt. Het komt erop neer, dat men het beste van vele werelden tracht mee te nemen. Op die manier is ITIL dan ook toepasbaar op vele verschillende organisaties. ITIL voorziet bovendien in een soort gemeenschappelijke taal voor de medewerkers van een organisatie. Het

3

KL Beheer modellen

kan hierbij dus als een onderling communicatiemiddel gebruikt worden, en, mits voldoende toegelicht, als communicatiemiddel richting de klant.Als laatste (doch zeker niet het minst belangrijk) is ITIL gebaseerd op het principe van procesgericht werken.

1.2.4 Processen

De processen die in ITIL onderkend worden, zijn er allemaal op gericht de klant zo goed mogelijk te bedienen en het bedrijfsproces van de klant zo goed en efficiënt mogelijk te ondersteunen. Er wordt een onderscheid gemaakt tussen een tweetal verschillende groepen processen, te weten de Service Delivery en de Service Support processen.

Zoals men ook vaak bij het inrichten van de besturing van organisaties ziet, kan IT-beheer op een drietal niveaus beschouwd worden. Het hoogste niveau is het strategische niveau. Hier wordt het beleid op lange termijn vastgesteld, en houdt men zich met de grote hoofdlijnen van het beheer bezig. Het niveau daaronder is het tactische niveau. Op dit niveau worden beslissingen ten aanzien van het beheer voor de middellange termijn genomen. Het gaat er op dit niveau vooral om de randvoorwaarden te scheppen voor de uitvoerende beheerprocessen op het laagste, het operationele niveau. Op dit laatste niveau vinden de daadwerkelijke uitvoerende beheerprocessen plaats.

De Service Delivery processen spelen zich af op het tactisch beheerniveau en zijn gericht op afspraken met de klant voor de middellange termijn.De Service Support processen daarentegen spelen zich op het operationeel beheerniveau en zijn gericht op het daadwerkelijk nakomen van de gemaakte afspraken met de klant richting de eindgebruikers voor de korte termijn. Het mag duidelijk zijn dat de beide soorten ITIL-processen nauw aan elkaar gerelateerd zijn, en daardoor goed op elkaar afgestemd moeten zijn.De beide sets van processen bestaan uit een zestal verschillende processen. Zij zijn opgenomen in onderstaande tabel.

Service Support Service DeliveryService Desk / Helpdesk Customer Relationship ManagementIncident Management Service Level ManagementProblem Management Capacity ManagementConfiguration Management Availability ManagementChange Management Financial Management for IT Services /

Cost managementRelease Management / Cost management

IT Service Continuity Management

Voor de nadere uitwerking van de processen verwijs ik naar bijlage 1.In eerste instantie zijn de Service Support processen het meest interessant, daar zij direct ingrijpen op de uitvoering van IT-beheerprocessen. In figuur 8 wordt de samenhang van de diverse Service Support processen weergegeven. Hieruit blijkt onder meer dat de basis voor al deze processen de Configuration Management Database (CMDB) is. Hierin worden alle Configuration Items (CI’s) opgenomen (Een CI is een item waarvan is bepaald dat het onder controle van het proces Configuration Management oftewel Configuratie Beheer dient te staan. Het kan hier een item betreffen behorend tot de categorie hardware, software of documentatie). Inrichting en onderhoud

4

KL Beheer modellen

van deze CMDB is onderdeel van het proces Configuration Management. Dit proces zal bij een invoering van ITIL in een beheerorganisatie dan ook als eerste moeten worden ingericht.

Figuur 1; Samenhang Support processen

1.3 Pro en contra

In de onderstaande paragraaf worden de meest opvallende voor- en nadelen van ITIL uitgelegd zonder daaraan direct conclusies te verbinden in relatie tot de probleemstelling. Wat wel duidelijk is, is dat ITIL -ondanks alle pluspunten- natuurlijk niet meteen afrekent met alle problemen op beheergebied. Het is geen tool, maar meer een soort handvat waar wel of geen gebruik van gemaakt kan worden. En ITIL zal zeker ook niet het einde betekenen van alle bureaucratische procedures en overlegfora in de organisatie.

1.3.1 Pro

ITIL heeft als methodiek heel veel te bieden, en is zeer uitgebreid. Men zou kunnen zeggen, ‘er is aan alles gedacht’. Ondanks deze uitgebreidheid is het toch relatief eenvoudig uit te leggen aan mensen, zowel beheermedewerkers als (in mindere mate) klanten en gebruikers, waar het in deze methode om draait. In feite is er dan sprake van een soort gemeenschappelijk referentiekader. Dit biedt duidelijke voordelen, zeker waar het gaat om duidelijkheid en structuur in relatie tot taken, verantwoordelijkheden. verder is de methodiek gebaseerd op procesmatig werken, wat de klantgerichtheid zeer ten goede kan komen. Tenslotte is de methodiek niet zomaar uit de lucht komen vallen, maar ontstaan uit de beheerpraktijk van verschillende organisaties. Het is dus meer universeel toepasbaar.

1.3.2 Contra

Ook aan ITIL zijn, ondanks alle positieve aspecten, nadelen verbonden. Wanneer men de methodiek naar de letter wil volgen, en dus volledig wil toepassen, zal blijken dat zij toch behoorlijk gedetailleerd is, veel bureaucratische regeltjes kent en bovendien aardig gecompliceerd is. Het leidt tot meer bureaucratie.Verder wordt ook geen raamwerk aangeboden waarmee één en ander gefaseerd ingevoerd zou kunnen worden. Onduidelijk is waarmee het best begonnen zou

5

KL Beheer modellen

kunnen worden en wat er daarna moet volgen. Voorts, mede vanwege de complexiteit, is het van belang om het aspect kennismanagement te vermelden. Hoe zorgt men ervoor dat de kennis over de methodiek niet verloren gaat, zeker in een organisatie waarin de medewerkers iedere drie jaar van functie wisselen of tussentijds de organisatie verlaten?Wat bij de voordelen als positief wordt opgemerkt, namelijk het bieden van duidelijkheid en structuur, kan voor medewerkers van de beheerorganisatie heel anders ervaren worden. Zij ervaren de overvloed aan regeltjes en structuur als benauwend. Ook met dit soort gevoelens bij medewerkers zal rekening gehouden moeten worden.Hoewel je het wellicht niet van een methodiek mag verwachten, geeft de beschrijving van ITIL geen handvatten voor de daadwerkelijke inrichting van een IT-beheerorganisatie. Welke organisatorische eenheden zou men moeten kiezen, en hoe groot moeten die dan worden? Hoeveel functieplaatsen moet men nu 'begroten' voor welk proces, en voor welke hoeveelheid werkplekken is welke hoeveelheid beheerders redelijk? Dit laatste is overigens uiteraard ook afhankelijk van het soort te ondersteunen werkplekken.Ten slotte ontbreekt het in de hele methodiek aan fundamentele aandacht voor functioneel (applicatie-)beheer. Wellicht zit het ‘verstopt’ in de methodiek doordat ook software als CI wordt aangemerkt en dus wordt beheerd. Maar het specifieke functionele beheer van een werkplek met al zijn hard- en software is van heel groot belang. Een gebruiker heeft niets aan een technisch hoogstaande werkplek als hij of zij niet ondersteund wordt in het omgaan ermee.

1.4 Deelconclusie

ITIL is een uitgebreide en beproefde methodiek die,haar nut kan bewijzen bij het stroomlijnen van het beheer zoals dat door de BO GDBK-KL over het KL Zorgnet gevoerd wordt.

6

KL Beheer modellen

2 Het drievoudig model van beheer van Looijen

2.1 Beschrijving methodiek

Volgens Looijen wordt beheer beïnvloed vanuit verschillende invalshoeken, die voorts onderling in bepaalde mate met elkaar verband houden. Één en ander wordt geïllustreerd in onderstaande figuur.

Figuur 2; Beheer in relatie met eisen, randvoorwaarden en karakteristieken van componenten

(bron: Looijen, Beheer van informatiesystemen, 2000)

Vanuit de diverse invalshoeken kan een grote hoeveelheid beheertaken naar aard en samenhang bij elkaar gebracht worden in clusters van taken, de zogenaamde taakgebieden. Vervolgens deelt Looijen de takenclusters weer in in subclusters, die door hem taakvelden worden genoemd. Een overzicht van de taakvelden en taakgebieden is opgenomen in bijlage 2.

Vervolgens gaat Looijen nader in op processen. Afhankelijk van de te beheren objecten en aspecten voegt hij een aantal dicht bij elkaar liggende taakvelden bij elkaar tot wat meer op de praktijk afgestemde gebieden van beheer. Deze gebieden noemt hij processen. Zo onderscheidt hij onder meer processen als configuratiebeheer, netwerkbeheer, probleem- en wijzigingsbeheer, risicobeheer, beschikbaarheidsbeheer, bereikbaarheidsbeheer en werkplekkostenbeheer. Logische naamgeving wanneer men de de benaming van de ITIL-processen bekijkt.Wat pleit voor Looijen is het feit dat hij door middel van het definiëren van de diverse toestanden waarin een informatiesysteem zich gedurende zijn levenscyclus kan bevinden ervoor probeerd te zorgen dat het uiteindelijke beheer in de exploitatiefase voldoende aandacht krijgt. Min of meer overeenkomstig de

7

KL Beheer modellen

methode die het Belastingdienst Automatiseringcentrum (BAC) voor zijn systemen hanteerde.

Deze methode luistert naar de naam ‘Integrated Life Cycle Management’ (ILCM) en gaat uit van een vroegtijdige bemoeienis van de beheerorganisatie bij de ontwikkeling van een nieuw systeem. Vanaf het allereerste begin van de systeemontwikkeling tot en met het uitfaseren van de applicatie is daarbij de beheerorganisatie betrokken.

De fasen of toestanden die Looijen onderkent, zijn weergegeven in onderstaande figuur.

Figuur 3; Toestandenmodel (bron: Looijen, Beheer van informatiesystemen, 2000)

In de toestanden G, W en E zijn de taakvelden ondergebracht ter ondersteuning van respectievelijk het gebruik, het wijzigen en het exploiteren van informatiesystemen. Dit leidt tot een driedeling in categorieën taakvelden die zich elk tot een specifiek gebied van beheer richten. Het gaat in concreet om de volgende gebieden: instandhouding van de functionaliteit van het informatiesysteem; instandhouding van de applicatieprogrammatuur en de

gegevensbankstructuur; instandhouding van de operationalisering van apparatuur, programmatuur en

gegevensverzamelingen.Looijen wijst deze beheergebieden toe aan drie verschillende beheereenheden, Namenlijk Functioneel Beheer (FB), Applicatie Beheer (AB) en Technisch Beheer (TB).FB ondersteunt het gebruik van de functionaliteiten, het evalueert het gebruik en het reageert op onvolkomenheden en nieuwe wensen die tot wijzigingen kunnen leiden. Looijen is van mening dat de directe relatie met het gebruik van informatiesystemen reden is om functioneel beheer aan de gebruikerszijde van de organisatie onder te brengen. AB is verantwoordelijk voor de instandhouding van alle toepassingsprogrammatuur, specifieke beveiligingsprogrammatuur, gegevensmodellering en gegevensbankstructuren. Het moet een duidelijke plaats innemen naast FB en TB.TB dient zorg te dragen voor het ‘in de lucht houden’ van alle apparatuur, programmatuur en gegevensverzamelingen die vanuit het gebruik continu

8

KL Beheer modellen

beschikbaar moeten zijn. Dit is een brede taakstelling, die zich derhalve richt tot vele aspecten van operationalisering. Looijen stelt in deze terecht dat technisch beheer geen doel op zich is, en dat veranderingen in de exploitatie nooit los gezien mogen worden van het gebruik. Voor elk van de drie beheereenheden geldt dat er taken (taakvelden) liggen op strategisch, tactisch en operationeel niveau.Uiteraard kunnen de drie beheereenheden niet los van elkaar gezien worden. In de meest eenvoudige vorm kan de samenhang worden weergegeven zoals in figuur 4.

Figuur 4; Samenhang beheereenheden (bron: Looijen, Beheer van informatiesystemen, 2000)

De beheereenheden beheren vanuit hun eigen 'beheerdiscipline', maar dat is niet voldoende om goed beheer te kunnen voeren. Zeker niet als men niet wil vervallen in taakgericht werken en derhalve niet verder kijken dan de eigen beheerinvalshoek. Sterker nog, er zullen zich in de praktijk vele situaties voordoen waarin de beheereenheden samen zullen moeten werken om het gewenste product neer te kunnen leggen. Looijen geeft aan dat de diverse beheereenheden organisatorisch niet ver uit elkaar behoeven te liggen, mits de scheiding tussen de drie vormen van beheer maar expliciet bewaard blijft.Deze samenhang kan vertaald worden naar de diverse managementniveaus binnen een organisatie. Looijen gebruikt hiervoor het logo van Mintzberg. Mintzberg onderkent hierin vijf basiselementen die in elke organisatie terugkomen. Dit zijn de strategische top, het middenkader, de technostructuur, de ondersteunende staf en de operationele kern. Looijen vertaalt deze basiselementen naar beheerelementen die ieder op zich weer op de diverse managementniveaus gepositioneerd kunnen worden. Zo komen bijvoorbeeld strategisch, tactisch en operationeel management in het model terug, evenals technische ondersteuning en personeel management en administratieve ondersteuning. Op het uitvoerende niveau, de operationele kern van Mintzberg, vindt men dan de operationele beheertaken terug zoals gebruiksbeheer, functioneel onderhoud, technische dienstverlening en onderhoud van de technische infrastructuur en operationele ondersteuning. Uiteindelijk resulteert dit in het ‘Drievoudig model van beheer’. Eén en ander is weergegeven in figuur 5.

9

KL Beheer modellen

Figuur 5; Drievoudig model van beheer (bron: Looijen, Beheer van informatiesystemen, 2000)

Legenda:SM Strategisch management GB GebruiksbeheerTM Tactisch management FO Functioneel onderhoudOM Operationeel management AO Applicatie onderhoudTO Technische ondersteuning OB Operationele besturingPM Personeel management ON Onderhoud technishe infra en

operationele ondersteuningAB Algemene

bedrijfsondersteuningTD Technische dienstverlening

Looijen laat zich ook uit over ITIL en de daarin opgenomen processen. Hij onderkent de noodzaak van een duidelijke inbedding van de processen in de organisatie van het beheer. Immers, daarmee wordt de samenhang duidelijk tussen enerzijds beheerprocessen en anderzijds de organieke eenheden die ervoor verantwoordelijk zijn.Ten slotte reikt Looijen een middel aan om de inrichting van beheer van informatiesystemen op systematische wijze gerealiseerd te krijgen. Hij noemt dit Een Beheer Stappenplan (EBS). EBS bestaat uit navolgende stappen: Stap 1: beschrijf het object van beheer; Stap 2: beschrijf de eisen vanuit de gebruikersorganisatie; Stap 3: selecteer de taakvelden benodigd om te voldoen aan de eisen gesteld

in stap 2; Stap 4: vertaal de taakvelden uit stap 3 naar beheerprocessen, bijvoorbeeld

de ITIL-processen; Stap 5: construeer elk onderkend beheerproces in zijn totaliteit op basis van

een generieke procesbeschrijving; Stap 6: beschrijf de drie beheervormen (FB, AB, TB) aan de hand van de in

stap 3 geselecteerde taakvelden; Stap 7: concretiseer de organieke beheereenheden die verantwoordelijk zijn

voor FB, AB en TB; Stap 8: breng de beheerprocessen uit stap 5 in relatie met de organisatie van

beheer, dus een inbedding van de processen in de beheereenheden uit stap 7;

Stap 9: stel de functies (inclusief benodigde kennis, inzicht en vaardigheden) vast ter uitvoering van de diverse beheertaken en wijs ze toe aan functionarissen;

10

KL Beheer modellen

Stap 10: stel dienstenovereenkomsten op tussen de gebruikers (klanten) en de beheerders van de informatiesystemen op basis van de in stap 2 geformuleerde eisen;

Stap 11: evalueer het beheer.

11

KL Beheer modellen

2.2 Pro en contra

In de onderstaande paragraaf worden de meest opvallende voor- en nadelen van het 'Model Looijen' verwoord, opnieuw zonder hieraan direct conclusies te verbinden in relatie tot de probleemstelling.

2.2.1 Pro

Het grote voordeel van het Model Looijen is dat het zich, naast een uitgebreide opsomming van beheertaken, ook nadrukkelijk buigt over de organisatie van beheer. De diverse taakgebieden bestrijken in principe alle beheervormen op zowel strategisch, tactisch als operationeel niveau, daar waar ITIL veel meer gericht is op het operationele niveau. Het Model Looijen richt zich niet alleen op het uitvoerig in kaart brengen van een grote verscheidenheid aan beheertaken (taakvelden), maar probeert deze ook in te bedden in een beheerorganisatie. Daarvoor wordt ook het eerder genoemde stappenplan (EBS) aangereikt.In de methodiek is een nadrukkelijke plaats ingeruimd voor het onderkennen van de noodzaak van de inrichting van functioneel beheer. Goed functioneel beheer is een manier om dichter bij de klant, de gebruiker te staan, en dat heeft veel toegevoegde waarde voor zowel gebruiker als beheerorganisatie.

2.2.2 Contra

Het Model Looijen is hoofdzakelijk gericht op taken dan op processen en legt derhalve ook minder of geen nadruk op procesmatig werken. Dit is niet bevorderlijk voor de klantgerichtheid van de medewerkers. Hoewel Looijen binnen Nederland een autoriteit op het gebied van IT- beheer is, wordt zijn methode niet veel toegepast. Men kan zich dus ook afvragen in hoeverre één en ander gebaseerd is op de praktijk van alledag bij een groot aantal verschillende organisaties.Ook voor Looijen geldt dat hij, ondanks al zijn organisatiegerichtheid, geen aanzet geeft voor de hoeveelheid functieplaatsen waar men voor de diverse taakvelden en beheervormen rekening mee zou moeten houden.

2.3 Deelconclusie

Het Model Looijen is, net als ITIL, een uitgebreide methodiek die vanwege haar organisatorische gerichtheid voor met name de organisatorische aspecten gebruikt kan worden bij het opzetten van het beheer zoals dat door de BO GDBK-KL over het KL Zorgnet gevoerd wordt. Bovendien biedt het toepassen van EBS goede handvatten hiervoor.

12

KL Beheer modellen

3 Het KL-Zorgnet, IT-beheer en zorgverlening gecombineerd

3.1 Gewoon en toch specifiek…..IT-beheer in de zorg

IT-beheer en IT-beheer is twee, met andere woorden, niet alle IT-beheer is hetzelfde. IT-beheer in de zorg is daar een voorbeeld van. IT-beheer in de zorg onderscheidt zich met name door de aard van de gegevens die erin verwerkt en opgeslagen worden. Hierdoor is een flinke hoeveelheid wet- en regelgeving van kracht die zich uitlaat over de manier waarop men dient om te gaan met de toegang tot, het gebruik van en de opslag van erin verwerkte gegevens van dit soort informatiesystemen. Voorbeelden van dit soort wet- en regelgeving zijn onder meer de Europese norm op dit gebied, de Wet Bescherming Persoonsgegevens (WBP) en de Wet op de Geneeskundige Behandelovereenkomst (WGBO). Hierin wordt een groot aantal richtlijnen neergelegd waaraan de BO GDBK-KL zich dient te houden. Deze richtlijnen worden dan ook gewoon nageleefd, en zijn de basis voor het model van zorgverlening dat de KL hanteert. Dit heet ‘scheiding van zorg’ of ook wel 'professionalisering in de zorg'. Het komt er in de praktijk op neer, dat er onderscheid gemaakt wordt tussen bijvoorbeeld een curatief arts en een bedrijfsgeneeskundig arts. Deze beide (om maar in medische termen te blijven) ‘bloedgroepen’ hebben derhalve ook geen toegang tot de systemen en daarin opgeslagen gegevens van de ander. In principe krijgen de medische behandelaars uit de vier onderscheiden zorgprocessen ( Het curatief zorgproces, de arbo-dienstverlening, de ambulante geestelijke gezondheidszorg en het verzekerings geneeskundig zorgproces. ) op geen enkele wijze toegang tot de door hun collega's medische gegevens. In dit laatste aspect onderscheidt de KL zich van de rest van de krijgsmacht, waar op basis van het model van ‘integrale zorg’ geen onderscheid gemaakt wordt tussen voornoemde zorgprocessen en de daarvoor actieve informatiesystemen. Dat betekent in de praktijk bijvoorbeeld dat een medewerker van de Koninklijke Luchtmacht (Klu) zowel voor curatieve als bedrijfsgeneeskundige aangelegenheden bij één en dezelfde zorgverlener terechtkomt. Deze zorgverlener heeft inzage in beide geneeskundige dossiers van de desbetreffende militair, terwijl hij of zij wel twee verschillende rollen vervult en daarmee twee verschillende belangen vertegenwoordigt. Immers, in zijn rol als curatief arts vertegenwoordigt hij het belang van de patiënt, in zijn rol als bedrijfsarts vertegenwoordigt hij (het woord zegt het al) de belangen van het bedrijf. En niet iedere patiënt heeft er belang bij dat zijn of haar curatief medische gegevens bij een bedrijfsarts bekend worden, want daaraan zouden vanuit de werkgever uiteindelijk vervelende gevolgen kunnen zitten. Dit fenomeen heeft er onder meer toe geleid dat militairen van de Klu voor hun curatieve zorg afspraken maakten bij militaire huisartsen van de KL of bij civiele huisartsen, zodat de eigen Klu-artsen deze gegevens niet onder ogen zouden krijgen.Dit verschil in opvatting over het model van zorg en de hieraan gerelateerde wijze van omgaan met medische dossiers heeft in het verleden (en vormt dat heden ten dage nog steeds) ook tegelijkertijd één van de belangrijkste belemmeringen gevormd voor de realisatie van een krijgsmachtbrede geneeskundige database. De KL tracht alle wet- en regelgeving zo nauwkeurig

13

KL Beheer modellen

mogelijk na te leven, en heeft dat onder meer in het zorgmodel 'scheiding van zorg' en strikte toegangsregelingen tot de medische gegevens van haar medewerkers trachten te vertalen.

3.2 De beheerpraktijk

In de praktijk komt het erop neer, dat het beheren van medische informatiesystemen niet fundamenteel anders hoeft te zijn. Het zijn met name voornoemde richtlijnen die implementatie van extra maatregelen en voortdurende aandacht vereisen waar het gaat om het vaststellen en beheren van autorisaties (en daarmee toegang tot programmatuur en gegevens), fysieke beveiliging, de technische complexiteit van het beheer van een eigen domein en het aanleveren van managementinformatie uit de diverse systemen. Het feit dat het KL Zorgnet onderdeel uitmaakt van een (in ieder geval binnen Defensie) 'openbaar' netwerk, het ( Netherlands Armed Forces Integrated Network ) NAFIN, betekent dat deze aspecten ontzettend veel aandacht moeten krijgen. Als dit zou worden nagelaten, voldoet de KL niet aan hetgeen er in de wetgeving is bepaald ten aanzien van het eigenaarschap van medische informatiesystemen en de daarin opgeslagen gegevens. De registratiekamer ziet er jaarlijks op toe dat dit zorgvuldig geschiedt. Wat in de praktijk wel problematisch is, is het feit dat er een groot aantal verschillende specialismen binnen het KL Zorgnet actief is. Elk van deze specialismen heeft eigen informatiesystemen, die bovendien veelal van niet al te grote leveranciers afkomstig zijn. Immers, de afzetmarkt voor dergelijke producten, vooral voor de kleinere specialismen, is niet erg groot. Zo wordt het pakket voor de fysiotherapeuten geleverd door een bedrijf dat nog geen 10 man groot is. Dit vormt een risico voor de betrouwbaarheid en continuïteit van een dergelijke leverancier. Overigens is de keuze voor een bepaald product lang niet altijd in de hand van de KL alleen. Applicaties die door meerdere krijgsmachtdelen worden gebruikt, zoals dat voor de tandartsen en de fysiotherapeuten, worden verworven door het( Medish Geneeskundig Facilitair Bedrijf ) MGFB.

Het ene systeem vangt fouten in de invoer door middel van maskering af, het andere doet dat niet. Dat geeft een groot risico voor het op allerlei plaatsen in allerlei systemen opslaan van gegevens van weliswaar dezelfde persoon maar met een bijvoorbeeld steeds iets anders gespelde achternaam of iets dergelijks. Hier ligt ook een belangrijke taak voor de IT-beheerorganisatie. Begeleiden van gebruikers, bewaking van de integriteit van de gegevens en tegelijkertijd voortdurende signalering naar het management zodat dit fenomeen uiteindelijk geminimaliseerd wordt. Een oplossing in de trend van een architectuur in drie lagen (bronsystemen, doelsystemen en een transactielaag) zou al veel mogelijkheden kunnen bieden. Gedacht moet dan worden aan een reeks van doelsystemen op het niveau van de eindgebruikers. Deze doelsystemen maken gebruik van gegevens die uiteindelijk afkomstig zijn (aan de zijde van centraal systeembeheer) van een aantal bronsystemen (Hierbij moet gedacht worden aan een personeelssysteem, een financieel systeem, medische databases en systemen, enzovoorts). De tussenliggende transactielaag zorgt ervoor dat de gegegevensoverdracht op de juiste wijze plaatsvindt. Op die manier wordt ervoor gezorgd dat alle gegevens slechts op één plaats en eenduidig worden opgeslagen. Op basis van autorisatie krijgt de eindgebruiker toegang tot die (sets van) gegevens waartoe hij gerechtigd is. Deze oplossing wordt wordt op dit moment nader onderzocht vanuit de KL.

14

KL Beheer modellen

15

KL Beheer modellen

3.3 De keuze voor een methodiek van beheer

Men kan, terugkerend naar de probleemstelling, een aantal gevolgen aangeven die het voorgaande heeft voor de keuze voor een beheermethodiek. De beschouwing in de voorgaande paragraaf, de uiteenzetting over het belang van procesgericht werken en de pro’s en contra’s van ITIL en het Model Looijen in aanmerking genomen, is een eenduidige keuze voor één van de beide methodes niet opportuun. Uitsluitend met ITIL werken beperkt de scope van de processen al te zeer, geeft geen houvast voor organisatorische inbedding. En omdat de BO GDBK-KL maar met een vaste personeels groep van 12 personen werkt krijgt men problemen met het indelen van taken waardoor sommige personeels leden dan 2 management taken zouden krijgen. En dat moet verkomen worden, Conclusie: de ITIL methode is voor een kleine onderneming niet helemaal berijkbaar.

Alleen het Model Looijen toepassen legt de focus te veel op taken en dus te weinig op procesgericht werken. Hier door krijg je dat de personeels leden hun gezamenlijk doel niet meer proberen te berijken maar slechts en alleen hun eigen taak. Waardoor er taken van andere personeels leden ongemerkt zullen veranderen.

De keuze voor het beste van twee werelden, dus een combinatie van ITIL en het Model Looijen, ligt het meest voor de hand. Het gaat hier om het daadwerkelijk invoeren van een methodiek van beheer. Daar waar het gaat om het daadwerkelijke operationele beheer is implementatie van in ieder geval de Service Support processen en een gedeelte van de Service Delivery processen van ITIL een goede optie. Een gedeelte van de Service Delivery processen, want er vindt tussen de BO GDBK-KL en haar klanten vooralsnog geen financiële verrekening plaats voor de verleende diensten. Dit wordt door de KL ook niet vereist. Dat maakt ten minste één proces (Financial Management for IT Services) geheel overbodig. Voor een gedeelte van een ander (Service Level Management) geldt dat ook. Nadat de dienstenniveau-overeenkomst is opgesteld, volgt normaliter het onderhandelen over de aan de te verlenen diensten verbonden financiële vergoeding. In het geval van het KL Zorgnet zal dat vooralsnog niet gebeuren.Wel wordt bewaakt dat afgesproken parameters worden gehaald.

Het organisatorische aspect, en het onder andere daarmee inbrengen van functioneel en applicatiebeheer, wordt dan meegenomen door ook het Model Looijen erbij te betrekken. Looijen geeft zelf ook aan dat het één het ander niet hoeft te bijten, hoewel dat ook wel eens anders geweest is. In de eerdere boeken van de Dhr Looijen was er geen plaats voor de ITIL methode in zijn eigen methode, In de nieuwere uitgaven van zijn boeken en de nieuwere edities van zijn methode geeft hij aan dat dat niet geheel correct was en probeert ook de heer van Looijen geberuik te maken van de goede aspecten van de ITIL methode.

Looijen doet met EBS (Een Beheer Stappenplan) een goede suggestie om het IT-beheer gestructureerd vorm te geven. Het levert een gecontroleerd traject op dat zoveel mogelijk aspecten meeneemt, waaronder nadrukkelijk ook ITIL-processen. Als aanvulling erop dienen in ieder geval, gelet op de specifieke taken en objecten van beheer van de BO GDBK-KL, drie processen aanvullend te worden meegenomen, en wel het beheer van autorisaties voor applicaties van de diverse gebruikers, het beheer van de (gegevens van) locaties waar de diverse gebruikers zich bevinden en het opleveren van managementinformatie uit de diverse systemen.

16

KL Beheer modellen

Wat verder van belang is, is dat de te implementeren methodiek ondersteund kan worden door een goed beheertool. Het huidige tool, een door de firma Remedy ontworpen systeem luisterend naar de naam 'ITBIS', biedt hiertoe te weinig functionaliteit.

17

KL Beheer modellen

3.4 Deelconclusie

Zowel het model Looijen als ITIL zijn ieder op zich goed bruikbaar als methodiek voor het beheer van het KL Zorgnet, doch de beste oplossing biedt implementatie van een combinatie van beide methodieken aan de hand van Een Beheer Stappenplan van Looijen.

18

KL Beheer modellen

4 Gevolgen voor de geautomatiseerde ondersteuning van het beheer

7.1 IST-situatie

In de huidige situatie is er bij de BO GDBK-KL eigenlijk geen sprake van een goed tool voor het beheer. Er wordt een systeem gebruikt, luisterend naar de naam 'ITBIS’. De penetratiegraad van dat systeem binnen de BO GDBK-KL is erg gering, de enige functionarissen die er nuttig gebruik van kunnen maken zijn technisch beheerders (waaronder de medewerkers die de helpdesk bemannen). Klanten en eindgebruikers hebben er al helemaal geen inzage in. Het systeem is ook niet in staat om bijvoorbeeld de ITIL-processen goed te ondersteunen.Ten slotte komt er op korte termijn ook een einde aan de ondersteuning van de applicatie door de DTO. Deze organisatie is voor het beheer dat zij zelf voert reeds in een eerder stadium overgegaan op een ander beheertool dan het ITBIS. De DTO is destijds wel leverancier geweest van dit systeem en levert er tot op heden nog ondersteuning voor ten behoeve van andere beheerorganisaties binnen Defensie.

4.1 Eisen te stellen aan een beheertool

Gelet op het voorgaande is het onvermijdelijk dat er een nieuw beheertool zal moeten komen, dat het ITBIS kan vervangen en nieuwe functionaliteiten kan bieden die de invoering van een beheermethodiek met zich mee brengt. Een aantal functionele en technische eisen waaraan een dergelijk tool zal moeten voldoen is in de volgende paragrafen opgenomen.

4.1.1 Functionele eisen

Uiteraard moet de basisfunctionaliteit beschikbaar zijn, namelijk het ondersteunen van de te implementeren ITIL-processen en dient het systeem de processen locatiebeheer en autorisatiebeheer te kunnen ondersteunen, omdat die van groot belang zijn voor de bedrijfsvoering van de BO GDBK-KL. Eveneens van groot belang is de mogelijkheid om goede managementinformatie te kunnen opleveren. Dit zijn samengevatte gegevensoverzichten of rapporten die worden samengesteld uit de database van het beheertool. Deze rapporten zijn met name voor het management van de BO GDBK-KL van belang voor het besturen van de afdeling. Voorbeelden daarvan zijn bijvoorbeeld: De hoeveelheid openstaande 'calls' op enig moment Het verloop van de ‘calls’ in de tijd gezien. De aantallen configuraties van bepaalde types die aan het einde van hun

economische levensduur zitten. Een overzicht van openstaande 'calls' van gebruikers van de Arbodienst. Daadwerkelijk gehaalde service levels voor bepaalde diensten bij diezelfde

gebruikersgroep.

19

KL Beheer modellen

Verder is er zowel voor eigen medewerkers als (mits zij toegang hebben) voor eindgebruikers een kennisbank zeer relevant. Eindgebruikers kunnen al zeer geholpen zijn met een goede zogenaamde 'Frequently Asked Questions'-lijst oftewel een FAQ. Deze zou bijvoorbeeld via het intranet ter beschikking kunnen worden gesteld als extract uit de kennisbank van het beheertool. Hierin kunnen de meest voorkomende problemen en hun oplossingen worden opgenomen. Dit kan de beheermedewerker veel tijd besparen bij de oplossing van een incident of probleem, en de gebruiker kan de oplossing voor zijn storing al voor het aanmelden opzoeken, zodat het deze wellicht niets eens hoeft te worden aangemeld. In een dergelijke kennisbank dient door het beheertool zelf te worden voorzien.Verder is er nog een aantal eisen te formuleren die zich meer richten op de eindgebruikers en de manier waarop zij met dit systeem en hun storingsmeldingen en service requests kunnen omgaan.

Indien het systeem ‘web-enabled’ en ‘Microsoft look-and-feel' is uitgevoerd, kan het ook voor een aantal aanvullende functionaliteiten beschikbaar gesteld worden aan iedere eindgebruiker. Te denken valt dan aan voorzieningen zoals: incidenten dan wel service requests indienen via intranetpagina of email; actief de voortgang controleren van 'calls' door gebruikers; gebruikers automatisch informeren indien er een wijziging is opgetreden in de

afhandeling van hun gemelde storing of service request.

4.1.2 Technische eisen

Een aantal technische eisen is relevant bij de keuze voor een beheertool. Om te beginnen moet het systeem voldoen aan de specificaties die gesteld zijn in de Defensie-brede standaard op IT-gebied, ‘LAN 2000’ geheten. In de praktijk komt het erop neer, dat het systeem moet draaien op het operating system Microsoft NT 4.0 en dat de onderliggende database een Oracle-database moet zijn. Voorts moet het systeem de oude gegevens uit het ITBIS kunnen importeren. Als laatste dient het goed te kunnen samenwerken met Microsoft Exchange gelet op de gewenste functionaliteit van het melden van en het krijgen van terugkoppeling over incidenten.

4.2 Deelconclusie

Selectie en invoering van een nieuw beheertool voor de BO GDBK-KL is onvermijdelijk en noodzakelijk.Voor het invoeren beheertool zal een nauwkeurige specificatie van functionele en technische eisen en wensen moeten worden opgesteld waarbij als basiseis geldt dat het de diverse service support processen van ITIL moet kunnen ondersteunen.

20

KL Beheer modellen

Literatuur- en referentielijst

1. Bommezijn, H., Plan, Taken, Organisatie en Werkwijze Beheer van het informatiesysteem Geneeskundige Data Base Krijgsmacht voor de Koninklijke Landmacht, beleidsdocument KL ter oprichting BO GDBK-KL, 1999.

2. CCTA, The IT Infrastructure Library, Central Computer and Telecommunications Agency, U.K., 1990.

3. Kuiper, A., 'Integrated Life Cycle Management bij het Belastingdienst Automatiserings Centrum, voordracht bij het IT-beheer congres van de ITSMF, Noordwijk, 1999.

4. Looijen, M., Beheer van informatiesystemen, Kluwer, 1997.

5. Looijen, M., Beheer van informatiesystemen, ten Hagen Stam, 2000.

6. Looijen, M., 'Een Beheer Stappenplan', in: Informatie, 3/1998.

7. Mintzberg, H., The structuring of organizations, Prentice Hall, 1979.

8. Schreuder, K., ‘Wat doet ITIL met mensen?’, in: IT Beheer Jaarboek 2001, ten hagen Stam, 2001.

9. Veld, S. van ’t, ‘Een informatie-architectuur is geen IT-architectuur’, in: Informatie, 4/2000.

10. ICTforyour business, Inrichtingsmodel IT-Beheer, www.ictforyourbusiness.nl

11. ICTforyour business, ITIL en Security , www.ictforyourbusiness.nl

12. ICTforyour business, ICT-Beheer oop basis van ITIL, www.ictforyourbusiness.nl

21

KL Beheer modellen

Bijlage 1 De processen van ITIL nader uitgewerkt

Van elk voor dit verslag relevant Service Support proces binnen ITIL wordt hieronder een korte, puntsgewijze toelichting gegeven, bestaande uit de doelstelling, de activiteiten en de kritieke succesfactoren van elk proces.

Service Desk

De Service Desk wordt binnen ITIL niet beschouwd als een proces, maar als een functie. Derhalve wordt er niet ingegaan op processtappen, er wordt alleen een beschrijving gegeven van een onderdeel van de organisatie. In zijn algemeenheid geldt, dat de service desk in actie komt bij de melding van een storing of het indienen van een service request (bijvoorbeeld een verzoek om informatie) door een gebruiker die daartoe ook geautoriseerd is.

Doelen

Het doel van de Service Desk is: Het voorzien in een ‘single point of contact’ voor de gebruikers; Het ervoor zorg dragen dat de gebruiker zo snel mogelijk weer aan de slag

kan nadat er een storing gemeld is; Het op peil houden dan wel verbeteren van het imago van de

beheerorganisatie.

Functies van de Service Desk

De voornaamste functies van de Service Desk zijn: Het onderhouden van het contact met de gebruikers; Het behandelen van incidenten en verzoeken; Voortgangscontrole, het coördineren van de tweede lijn en externe support

teams; Escalatiemanagement, escalatie van een incident naar de tweede lijn

(functionele escalatie) of naar een persoon in de organisatie met meer beslissingsbevoegdheden (hiërarchische escalatie);

Kritieke succesfactoren

De kritieke succesfactoren van de Service Desk zijn: De behoefte van de business en de klant zijn duidelijk; Investering in training van de medewerkers van de Service Desk; Hebben van heldere service doelstellingen; Hanteren van realistische service levels.

Configuration Management

Configuration Management richt zich op het onder controle brengen en houden van de relevante componenten van de IT-infrastructuur. Vanuit die

22

KL Beheer modellen

verantwoordelijkheid is het logisch dat het tevens het proces is dat de informatievoorziening over de infrastructuur verzorgt en dient als centrale informatiebron voor met name Problem Management en Change Management. In dit proces staat het Configuration Item (CI) centraal. Hieronder wordt verstaan:

Een component van de IT-infrastructuur – of een item, zoals een RFC, verbonden aan die infrastructuur – dat onder controle staat van Configuration Management.

Er worden drie soorten CI’s onderkend, te weten hardware, software en documentatie. Zij worden opgeslagen in de CMDB, een database die alle relevante gegevens bevat over ieder CI en over de relaties tussen CI’s.Configuration Management is een zodanig relevant proces voor de gehele beheerorganisatie dat het als eerste ingericht dient te worden. In feite vormt het de basis, het fundament.

Doelen

Het proces Configuration Management heeft de volgende doelstellingen: Het bewaken van alle (relevante) IT componenten en configuraties van de

organisatie; Het verschaffen van informatie ter ondersteuning van andere Service

Management processen; Het verschaffen van managementinformatie (intern en extern).

Activiteiten

De activiteiten van Configuration Management zijn de volgende:1. Planning (opstellen Configuration Management plan);2. Identification (selectie en identificatie van de CI’s en hun eigenaar);3. Control (invoeren procedurele en technische controlemechanismen opdat

alleen geautoriseerde en herkenbare CI’s in de CMDB worden geregistreerd);4. Status accounting (registratie van alle huidige en historische gegevens over

ieder CI gedurende zijn levenscyclus);5. Verification and audit (reviews en audits op het fysieke bestaan van CI’s en de

correcte registratie ervan in de CMDB).

Kritieke Succesfactoren

Binnen Configuration Management zijn navolgende kritieke succesfactoren relevant: Kwaliteit van de informatie in de CMDB; Bereik en detaillering van de CMDB; Controle op de processen (met name Change Management); Toegankelijkheid van de informatie; Bewustzijn bij alle betrokken partijen (medewerkers beheerorganisatie,

management, gebruikers, klanten); Beschikbaarheid van een goede beheertool die bovendien op de juiste manier

wordt ingezet.

Incident Management

Dit proces wordt voor een groot deel door de Service Desk uitgevoerd. Het proces houdt zich, het woord zegt het al, bezig met het oplossen van incidenten. In deze context wordt een incident omschreven als:

23

KL Beheer modellen

Iedere gebeurtenis die afwijkt van de standaardwerking van een service en die een onderbreking of een vermindering van de kwaliteit van de service veroorzaakt of kan veroorzaken.

Binnen een organisatie kunnen verschillende soorten incidenten worden onderscheiden, te weten: Applicatie-incidenten; Hardware-incidenten Service requests.

Doelen

Doel van het proces Incident Management is: Het zo snel mogelijk herstellen van het normale serviceniveau; Het minimaliseren van het negatieve effect van een verstoring op het

bedrijfsproces van de klant.Dit alles om de afgesproken servicekwaliteit en –beschikbaarheid te waarborgen. Het verschil met de Service Desk is dat de Service Desk een organisatieonderdeel is en Incident Management een proces.

Activiteiten

De achtereenvolgende activiteiten binnen Incident Management worden ook wel de ‘levenscyclus van een incident’ genoemd. Het gaat hier om de volgende activiteiten:1. Incident detection and recording;2. Classification and initial support;3. Investigation and diagnosis;4. Resolution and recovery;5. Incident closure;6. Ownership, monitoring, tracking and communication (activiteit ter

coördinatie).

Kritieke Succesfactoren

Ook Incident Management kent een aantal kritieke succesfactoren: Goede inrichting van de Service Desk; Een up to date CMDB; Een up to date problem/error database; Een goede, passende Incident Management Tool (‘beheertool’); Een goede relatie met Service Level Management.

Problem Management

Het proces Problem Management houdt zich bezig met het behandelen van structurele problemen en known errors. Het proces heeft een nauwe relatie met het proces Incident Management. In deze context wordt onder een ‘problem’ verstaan:

Een onbekende onderliggende oorzaak van één of meer incidenten.Voorts wordt onder een ‘known error’ verstaan:

Een incident of een problem waarvan de dieperliggende oorzaak bekend is en waarvoor een tijdelijke workaround of een permanent alternatief bekend is.

Doelen

24

KL Beheer modellen

Doel van het proces Problem Management is: Het minimaliseren van het negatieve effect van gebreken in de IT-

infrastructuur op het bedrijfsproces van de klant (reactief); Het voorkomen van nieuwe incidenten die aan deze fouten gerelateerd zijn

(pro-actief).Bovenstaande doelstellingen worden bereikt door het achterhalen en wegnemen van de dieperliggende oorzaak van incidenten.

Activiteiten

De activiteiten van Problem Management worden verdeeld in drie soorten, en wel reactieve activiteiten (Problem en Error Control), proactief Problem Management en Informatie en Communicatie.Problem en Error Control1. Problem Identification and recording;2. Problem classification;3. Problem investigation and diagnosis;4. Request for change (RFC), problem resolution and closure;5. Error identification and recording;6. Error assessment;7. Record error resolution;8. Close error and associated problem(s);9. Problem/error tracking and monitoring;Proactief Problem Management1. Trendanalyse;2. Doelgericht preventief actie ondernemen;3. Opstellen van probleemevaluaties.Informatie en communicatie1. Informatievoorziening aan de rest van de support organisatie over

geïdentificeerde problemen, bekende fouten en RFC’s;2. Informatievoorziening aan het management over de tijd gespendeerd aan het

onderzoeken en oplossen van problemen en bekende fouten.

Kritieke Succesfactoren

De kritieke succesfactoren van het proces Problem Management zijn:1. Accurate registratie en classificatie van incidenten;2. Commitment van het management om tijd en geld vrij te maken;3. Realistische doelstellingen;4. Goede samenwerking met Incident Management;5. Relatie met Change Management;6. Beschikken over een up to date Configuration Management Data Base

(CMDB).

Change Management

Change Management houdt zich bezig met het gecontroleerd doorvoeren van geautoriseerde wijzigingen in de IT infrastructuur. Deze wijzigingen of changes hebben altijd betrekking op een CI. Onder een change wordt verstaan:

Het proces van overgang van één bepaalde gedefinieerde staat naar een andere.Deze changes worden altijd planmatig, beheerst en gecontroleerd uitgevoerd, zodat de informatievoorziening voldoet en blijft voldoen aan de criteria in de dienstenovereenkomst.

25

KL Beheer modellen

De beslissingsautoriteit binnen Change Management is de Change Advisory Board, een geheel van vertegenwoordigers van klanten, gebruikers, ontwikkelaars, service medewerkers, experts en eventuele externe partijen.

Doelen

Het doel van Change Management is het zekerstellen van het efficiënt en effectief afhandelen van alle changes op de IT infrastructuur met gebruikmaking van gestandaardiseerde methoden en technieken teneinde de impact van uit changes voortvloeiende incidenten op de servicekwaliteit te minimaliseren.

Activiteiten

De activiteiten binnen Change Management zijn:1. Change logging and filtering;2. Allocation of priorities;3. Change categorisation;4. Impact and resource assessment;5. Change approval;6. Change scheduling;7. Change building, testing and implementation;8. Change review9. Close10.Management reportingUrgente changes kunnen een korter traject doorlopen.

Kritieke Succesfactoren

Kritieke succesfactoren voor dit proces zijn: Kwaliteit van de RFC; Minder risico door betere risico assessment; Beter assessment van de kosten; Betere alignment van IT services met de bedrijfsprocessen van de klant; Hogere zichtbaarheid en communicatie van changes; Lagere impact op de kwaliteit van services en dienstenovereenkomsten.

Release Management

Dit proces houdt zich bezig met het voorbereiden en implementeren van nieuwe of aangepaste versies hardware en software. Het voert changes uit op IT services door middel van releases. Onder een release wordt verstaan:

Een verzameling nieuwe en/of gewijzigde, geteste CI’s die gezamenlijk worden geïntroduceerd in de exploitatie-omgeving.

Hierbij moet wel het volgende onderscheid gemaakt worden: een release is altijd een change, maar een change is niet altijd een release.Voorts worden releases onderverdeeld in: Grote software en hardware upgrades; Kleine software releases en hardware upgrades; Emergency software and hardware fixes.

Doelen

Het doel van Release Management is: Het plannen en begeleiden van de uitrol van hardware en software;

26

KL Beheer modellen

Het ontwerpen en in werking stellen van efficiënte procedures voor implementatie en distributie van hardware en software;

Het zekerstellen dat alleen correcte en geautoriseerde hardware en software versies uitgerold worden;

Het zekerstellen dat de aan te passen hard- en software beheerd wordt; Het bewaken en beheren van de inhoud van de Definitive Software Library

(DSL).

Activiteiten

Binnen het proces Release Management worden de volgende activiteiten onderscheiden:1. Release policy en planning;2. Release design, build, configuration;3. Release acceptance;4. Rollout planning;5. Communication, preparation and training;6. Distribution and installation (in de vorm van een full release, partial release of

package release);7. Management reporting.

Kritieke Succesfactoren

De kritieke succesfactoren van dit proces zijn: Het belang voor de business helder maken; Controle van de operationele software, ook in grote gedistribueerde

omgevingen; Bewaken van licenties van ingekochte software; Voorkomen van virussen; Relatie met Change Management en Configuration Management.

Service Delivery processen

De processen van Service Delivery worden hier niet verder uitgewerkt, daar de processen van Service Support in dit stadium voor de BO GDBK-KL relevanter (zouden kunnen) zijn. Het betekent echter niet, dat aspecten en taken die tot deze processen behoren niet moeten worden uitgevoerd. Een aantal voorbeelden: Klanten, gebruikers en medewerkers van de BO GDBK-KL zijn erbij gebaat, te

weten welke diensten ze eventueel van de BO GDBK-KL zouden kunnen betrekken (Service Level Management);

Het monitoren en waarborgen van de beschikbaarheid van de IT infrastructuur (Availability Management) moet natuurlijk altijd geschieden;

Het vaststellen en in de gaten houden van toekomstige eisen voor wat betreft opslag- en verwerkingscapaciteit door de zich ontwikkelende ‘business’ van de klanten (Capacity Management) is eveneens van groot belang.

27

KL Beheer modellen

Bijlage 2 Uitwerking taakgebieden model Looijen

In deze bijlage zijn de diverse taakgebieden en de daartoe behorende taakvelden opgenomen. Ook voor deze bijlage geldt dat dit puntsgewijs geschiedt.

Taakgebied ManagementTaakvelden zijn: Strategisch management; Tactisch management; Operationeel management

Taakgebied Personeelsmanagement (PM)Taakveld is eveneens personeelsmanagement en omvat de reguliere personeelsmanagementstaken.

Taakgebied Technische ondersteuning (TO)Taakvelden zijn: Apparatuur- en basisprogrammatuurondersteuning; Communicatie-ondersteuning; DBMS-ondersteuning; Beheer van (PC-) toepassingspakketten; Onderzoek; Beheer van technische en bouwkundige voorzieningen.

Taakgebied Algemene bedrijfsondersteuning (AB)Taakvelden zijn: Administratief beheer; Kwaliteitsbewaking; Capaciteitsplanning; Operationele opdrachtenbeheersing; Begroting; Doorberekening; Verwerving van automatiseringsmiddelen.

Taakgebied Operationele besturing (OB)Taakvelden zijn: Acceptatie; Besturing; Apparatuurconfiguratie beheer; Programmatuurconfiguratie beheer; Fysiek gegevensbeheer; Gebruiksanalyse; Prestatiemanagement;

28

KL Beheer modellen

Afstellen.

Taakgebied Onderhoud technische infrastructuur en operationele ondersteuning (ON)Taakvelden zijn: Wijziging technische infrastructuur; Probleembehandeling; Bewaking beschikbaarheid; Uitwijken; Beveiliging.

Taakgebied Technische dienstverlening (TD)Taakvelden zijn: Beheer van dienstenscala en dienstenniveau; Gegevensverwerking; Advies en participatie; Informatieverstrekking.

Taakgebied Gebruiksbeheer (GB)Taakvelden zijn: Gebruikersondersteuning; Functioneel systeembeheer; Inhoudelijk beheer bedrijfsgegevens.

Taakgebied Functioneel Onderhoud (FO)Taakvelden zijn: Onderhoud handmatige procedures; Functioneel onderhoud informatiesystemen; Gegevensdefinitiebeheer.

Taakgebied Applicatie-onderhoud (AO)Taakvelden zijn: Onderhoud applicatieprogrammatuur; Gegevensbankbeheer.

29

KL Beheer modellen

Bijlage 3 Termen en afkortingen1 GNC 1 German Netherlands Corps, het gezamenlijk Duits Nederlandse LegerkorpsAB Applicatie Beheer (model Looijen)AIH Afdeling Individuele HulpverleningASL Application Services LibraryBKA Basis Kantoor AutomatiseringBLS Bevelhebber der LandstrijdkrachtenBO GDBK-KL Beheerorganisatie Geneeskundige Database Krijgsmacht (KL-gedeelte)CCTA Central Computer & Telecommunications AgencyCI Configuration ItemCMDB Configuration Management Data BaseCO Centrale Organisatie, de staf van het Ministerie van DefensieCOTS Commercial of the ShelveDBMS DataBase Management SystemDP&O Directie Personeel en OrganisatieDPKLU Directie Personeel Koninklijke LuchtmachtDSL Definitive Software LibraryDTO Defensie Telematica OrganisatieEBS Een Beheer StappenplanFAQ Frequently Asked QuestionsFB Functioneel Beheer (model Looijen)FSP Forensisch Sociale PsychiatrieGDBK Geneeskundige Database KrijgsmachtHIS Huisarts Informatie SysteemHMA Hoogste Medische AutoriteitIGDKL Inspecteur Geneeskundige Dienst KLIP Internet ProtocolIT Informatie TechnologieITIL Information Technology Infrastructure Library (verdere uitleg zie hoofdstuk 4)IVR Informatie Voorzienings RaadKL Koninklijke LandmachtKlu Koninklijke LuchtmachtKM Koninklijke MarineLAN Local Area NetworkMGFB Militair Geneeskundig Facilitair BedrijfMIMU Multi International Medical UnitNAFIN Netherlands Armed Forces Integrated Network, in feite het WAN van

het Ministerie van DefensieNATCO Nationaal CommandoPC Personal ComputerPDA Personal Digital Assistant, ook wel Pocket PC of Handheld Computer

genoemd, kleine doch relatief krachtige en zeer handzame PC’s met enigszins uitgeklede versies van de bekende besturingssystemen en kantoortoepassingen die eenvoudig met PC’s van regulier formaat kunnen communiceren

RFC Request for changeSNA Single Network AccessTB Technisch Beheer (TB)

30

KL Beheer modellen

VA Verrichtingen AdministratieVGDKL Verzekerings Geneeskundige Dienst KLVPN Virtual Private NetworkWAN Wide Area NetworkWBP Wet Bescherming PersoonsgegevensWGBO Wet op de Geneeskundige Behandelovereenkomst

31