Homepage : EBI : automatisering van de informatievoorziening : beheer van de informatievoorziening

Automatisering van de informatievoorziening

Sectie III
Prof. dr. D.B.B. Rijsenbrij

8. Beheer van de informatievoorziening vorig artikel volgend artikel
Download de illustraties
behorende bij het college:
214 KB

Inleiding

In het vorige hoofdstuk hebben we gezien hoe informatiesystemen ontwikkeld worden. Deze informatiesystemen zullen na ontwikkeling echter ook beheerd moeten worden, om ze optimaal draaiende te houden.

In dit hoofdstuk beschrijven we uit welke onderdelen het beheer van de informatievoorziening bestaat, en welke organisaties daarbij betrokken zijn.

Leerdoelen

Na het bestuderen van dit onderwerp wordt verwacht dat u weet :

  • Wat beheer is en waaruit het is opgebouwd en wat dient te worden beheerd.
  • Welke organisaties betrokken zijn bij beheer en op welke wijze.
  • Wat Service Level Agreements zijn, waaruit ze opgebouwd zijn en waarvoor ze gebruikt worden.

Beheer

Vanaf de jaren tachtig groeit de ontwikkeling en het gebruik van informatiesystemen en technische infrastructuren meer dan ooit. De afhankelijkheden tussen de bedrijfsprocessen enerzijds en de geautomatiseerde informatievoorziening anderzijds wordt alsmaar sterker. Ook moeten bestaande informatiesystemen steeds vaker aangepast worden aan nieuwe wensen. Sinds het begin van de jaren negentig groeit het besef, dat de kosten tijdens gebruik en beheer van informatiesystemen ver uitstijgen boven de ontwikkelkosten. Bovendien ontwikkelt de software-markt zich op zo’n manier, dat zij steeds meer hulpmiddelen aanbiedt voor de ondersteuning van het gebruik en beheer. De implementatie van deze middelen vergt forse inspanningen van met name personele aard. Dit geheel leidt tot de overtuiging dat de informatievoorziening een adequaat beheer vereist. Een beheer dat niet alleen op operationeel niveau, maar ook op strategisch en tactisch niveau is ingevuld, zoals u kunt zien in onderstaand model van Mintzberg. In het model van Mintzberg wordt onderscheid gemaakt tussen topmanagement, middenkader, ondersteunende eenheden en het productieapparaat. Op het strategisch niveau worden beslissingen genomen die van strategisch belang zijn voor het beheer, bijvoorbeeld " het beheer wordt zoveel mogelijk uitbesteed buiten het bedrijf". Op tactisch niveau bevinden zich de taken die gerelateerd zijn aan het beschikbaar stellen van materiële, personele en financiële middelen met betrekking tot het beheer. Op operationeel niveau tenslotte bevinden zich de taken die essentieel zijn voor de directe uitvoering van het beheer.

Zoals uit onderstaand figuur blijkt, neemt beheer een belangrijke plaats in tijdens de bedrijfsvoering van de informatievoorziening. Om het de gebruikers mogelijk te maken de informatievoorziening voortdurend te gebruiken dient de informatievoorziening zowel geëxploiteerd als onderhouden te worden.

Om duidelijk te maken wat we nu feitelijk onder beheer verstaan, zullen we het totale beheer van de informatievoorziening in drie beheervormen opsplitsen:

  • Functioneel beheer
  • Applicatiebeheer
  • Technisch beheer

In de volgende drie paragrafen wordt verder ingegaan op bovengenoemde soorten beheer op operationeel niveau.

Functioneel beheer
 

We beginnen met de volgende definitie van functioneel beheer: alle beheertaken die nodig zijn voor het dagelijks gebruik van informatiesystemen en de gegevensinfrastructuur en wijziging van de specificaties daarvan.

In de dagelijkse praktijk omvat functioneel beheer het volgende:

  • Het begeleiden en opleiden van gebruikers met betrekking tot het gebruik van informatiesystemen.
  • Het toekennen van autorisaties.
  • Het beheer van applicatie-gebonden gegevens.
  • Het inhoudelijk beheer van gegevensverzamelingen.
  • Het bewaken van het juiste gebruik van het informatiesysteem.
  • Onderhouden van de handmatige procedures.
  • Onderhouden van de functionele specificaties.
  • Uitvoeren van een acceptatietest

Applicatiebeheer

         

      Er kunnen zich tal van situaties voordoen waardoor wijzigingen in de oorspronkelijke applicatieprogrammatuur of gegevensbankstructuren moeten worden aangebracht. Situaties die zich kunnen voordoen zijn bijvoorbeeld het constateren van programmafouten, de noodzaak delen van programmatuur te verwijderen of nieuwe aan te brengen, de functionaliteit uit te breiden, of gegevens en/of relaties daartussen in de gegevensbanken aan te passen. Telkens wanneer zo’n situatie zich voordoet, wordt applicatie-onderhoud uitgevoerd. Ook echter wanneer er geen directe aanleiding is om applicatie-onderhoud uit te voeren, is het vanwege de continuïteit toch noodzakelijk om een volledige beheervorm in stand te houden, inclusief management en staftaken. Deze beheervorm heet applicatiebeheer. Een onderdeel van applicatiebeheer dat op operationeel niveau voorkomt noemen we onderhoud. Onderstaand figuur laten u zien welke soorten onderhoud we onderscheiden.

       

      Onder correctief onderhoud verstaan we het oplossen van ad hoc problemen in onderdelen van de informatievoorziening, bijvoorbeeld het verwijderen van bugs. Met preventief onderhoud wordt bedoeld het onderhouden van de informatievoorziening om eventueel optredende fouten voor te zijn. Met adaptief onderhoud bedoelen we het aanpassen van onderdelen van de informatievoorziening en de bijbehorende documentatie als gevolg van wijzigingen in de omgeving van die aangepaste onderdelen. Bijvoorbeeld bij een bankapplicatie moet het rentepercentage aangepast worden, omdat de landelijke rente gezakt is. Met perfectief onderhoud wordt het aanpassen van een deel van de informatievoorziening aan veranderende eisen van de gebruikers bedoeld. Het onderhouden van functionaliteit tenslotte is het uitbreiden of wijzigen van de functionaliteit van de informatievoorziening.
       

    Technisch beheer
     

    Voor technisch beheer kennen we de volgende definitie: alle beheertaken die nodig zijn voor het accepteren, installeren en operationeel maken en houden van informatiesystemen en technische infrastructuren.

    Tot het technisch beheer horen onder andere de volgende zaken:

    • Beschikbaar stellen en onderhouden van pakketten voor persoonlijke ondersteuning.
    • Beschikbaar stellen en onderhouden van informatiesystemen voor de ondersteuning van groepswerk.
    • Een helpdesk-functie
    • Onderhouden van de technische infrastructuur
    • Aanbieden van verwerkingscapaciteit
    • Aanbieden van opslagcapaciteit.

    Het technisch beheer is dus met name gericht op het technisch platform, bestaande uit apparatuur met bijbehorende basisprogrammatuur, en de operationalisering van de hierop gebouwde informatiesystemen.

    Onderhoud kost geld. Het is voor een onderneming daarom belangrijk om te bepalen wanneer onderhoud nog lonend is. Na verloop van tijd is het namelijk vaak goedkoper om een nieuw informatiesysteem te laten bouwen i.p.v. het informatiesysteem te blijven onderhouden. Dit onderscheid wordt vaak aangegeven door een zogenaamde badkuipkromme. Zie bijvoorbeeld onderstaand figuur. Het figuur maakt duidelijk dat de totale kosten van een informatiesysteem worden bepaald door de kosten voor de ontwikkeling van het informatiesysteem en door kosten voor het onderhoud van het informatiesysteem.

    Vlak na de ingebruikneming zien we vaak een verhoogd onderhoud door allerlei kinderziektes die nog in het informatiesysteem zitten ( correctief onderhoud ). Gedurende de levensloop van het informatiesysteem nemen de echte fouten hopelijk af maar beginnen de andere vier vormen van onderhoud toe te nemen. Door onderhoudswerkzaamheden zal in het algemeen de structuur van het informatiesysteem langzamerhand steeds slechter worden, waardoor de onderhoudbaarheid zal afnemen. Voorts is onderhoud net als nieuwbouw nog steeds mensenwerk dus is er een kans dat er nieuwe fouten worden geïntroduceerd. De verslechterende structuur en de nieuw geïntroduceerde fouten geven wat wij noemen ouderdomsverschijnselen waardoor op een gegeven moment wordt beslist dat het onderhavige informatiesysteem economisch gesproken beter aan zijn einde kan komen.

Beheerorganisaties

In deze paragraaf wordt de in de vorige paragraaf aangebrachte differentiatie in drie beheervormen vertaald naar drie soorten organieke beheereenheden. Hierbij wordt aangesloten op literatuur van EDP-auditors, waarin drie soorten organisaties worden onderscheiden, te weten: de gebruikersorganisatie, de systeemontwikkel- en onderhoudsorganisatie en de verwerkingsorganisatie. Onderstaand figuur laat u zien welke beheervorm bij welke organieke beheereenheid hoort.

Gebruikersorganisatie

         

      De gebruikersorganisatie wordt gedefinieerd als het geheel van mensen en middelen dat zich bezighoudt met de bedrijfsprocessen. Binnen zo’n gebruikersorganisatie treft men dan ook in de eerste plaats primaire bedrijfsfuncties aan en pas in de tweede plaats ondersteunende zaken als de gebruiks- en beheerfuncties ten aanzien van de informatievoorziening. Met beheerfuncties wordt het functioneel beheer bedoeld, dat vanwege de materiekennis, de verantwoordelijkheid en de kennis van de eigen gebruikersorganisatie die ermee gemoeid zijn, niet kan worden uitbesteed. Meestal gaat men uit van een aparte beheerorganisatie binnen de gebruikersorganisatie, omdat zoals eerder gezegd, de gebruikersorganisatie zich niet alleen met beheer bezig houdt.

    Onderhoudsorganisatie

         

      Volgens [Kocks] is een onderhoudsorganisatie het geheel van mensen en middelen dat zich bezighoudt met het ontwikkelen en onderhouden van applicaties. Binnen een onderhoudsorganisatie komen meestal aparte eenheden voor ten behoeve van applicatie-ontwikkeling en applicatie-onderhoud. Een verschil tussen beide is, dat ontwikkeling meestal wordt uitgevoerd door een eenmalige projectorganisatie, terwijl de organisatie voor het onderhoud permanent is.
       

    Verwerkingsorganisatie

         

      Een verwerkingsorganisatie is het geheel van mensen en middelen dat zich bezighoudt met het operationeel maken en houden van informatiesystemen en de technische infrastructuur. Dit soort organieke eenheden kan variëren van een groot reken-, communicatie- en servicecentrum tot een kleinschalige verwerkingsorganisatie op een afdeling binnen de gebruikersorganisatie.

    Samenwerking tussen de beheereenheden

    Het functioneel beheer, het applicatie-onderhoud en het technisch beheer kunnen binnen een en hetzelfde bedrijf op diverse plaatsen afspelen. Het is daarom van groot belang dat de drie beheerorganisaties, zoals beschreven in de vorige subparagrafen onderling samenwerken. Bij het wijzigen van een informatiesysteem bijvoorbeeld is nauwe samenwerking vereist tussen alle drie de organisaties. We maken onderscheid tussen wijzigingen in verband met adaptief en perfectief onderhoud en/of onderhoud van functionaliteit enerzijds en wijzigingen voor correctief en preventief onderhoud anderzijds. Bij de eerste categorie wijzigingen verandert het gebruik en/of de exploitatie van de informatievoorziening, en is gezamenlijke besluitvorming door het management van alle drie de organisaties vereist. Deze eerste categorie van wijzigingen noemen we wijzigingsbeheer. Het beheer van de tweede categorie wijzigingen, die van het correctief en preventief onderhoud, heet probleembeheer. Bij dit soort wijzigingen veranderen het gebruik en de exploitatie van de informatievoorziening niet. Daarom is coördinatie op operationeel niveau, zoals een helpdesk, hier veelal voldoende.

    De onderlinge samenhang tussen probleembeheer en wijzigingenbeheer laten wij u zien in onderstaand figuur.

     

Uitbesteding en services

Het uitvoeren van beheer wordt meestal door de organisatie zelf gedaan, maar soms worden delen van beheer uitbesteed aan een externe organisatie. We onderscheiden een tweetal vormen van uitbesteed beheer, namelijk:

  • Facilities management: het uitbesteden van (een deel van) het technisch en/of applicatiebeheer aan een externe organisatie.
  • Outsourcing: het uitbesteden van (een deel van) het technisch en/of applicatiebeheer, inclusief (een deel van) de technische infrastructuur aan een externe organisatie.

Bij het uitbesteden van beheer wordt vaak een contract getekend met de externe partij die het beheer overneemt. Zo’n contract wordt een Service Level Agreement (SLA) genoemd. Een SLA is een stelsel van afspraken over het kwaliteitsniveau van een dienst. Zo kan er bijvoorbeeld een afspraak gemaakt zijn om het operationeel beheer volledig uit te besteden aan een externe partij. Het komen tot zo’n servicecontract en het naleven ervan wordt Service Level Management (SLM) genoemd. SLM is het afstemmen en vastleggen van afspraken en het zorgdragen voor het nakomen daarvan. Overigens kan er ook sprake zijn van een SLA en SLM binnen een bedrijf, verschillende bedrijfsonderdelen spreken dan bijvoorbeeld met elkaar af zich te houden aan een SLA.

Met SLA’s wordt beoogd aan de hogere eisen te voldoen van de volwassener wordende markt van de IT-dienstverlening. Klanten verwachten dat IT-leveranciers verantwoordelijk blijven voor de werking en de prestaties van IT-producten na oplevering. Bij het opstellen van een SLA, zoals onderstaand figuur laat zien, is het daarom van belang dat afspraken over diensten en verantwoordelijkheden zorgvuldig dienen te worden gespecificeerd. De praktijk liet namelijk lange tijd een aantal belangrijke tekortkomingen zien. Zo bevatten veel servicecontracten een inspanningsverplichting, terwijl de klant juist meer gebaat is bij een resultaatverplichting.

Ook waren contracten vaak onvolledig en onduidelijk in de afspraken die gemaakt werden.

Als een SLA eenmaal tot stand is gekomen, bevat het de volgende onderdelen:

  • Doel van de SLA.
  • Looptijd van de service.
  • Betrokken partijen.
  • Relatie tussen betrokken partijen.
  • Verantwoordelijkheden bij betrokken partijen.
  • Rapportage-methoden, zogenaamde Service Level Reports.
  • Bijstellingsprocedure.
  • Te leveren diensten.
  • Prestatiecriteria, zogenaamde Service Level Measurement.
  • Te betalen prijs.

Uit onderstaand figuur blijkt dat er een driehoeksverhouding bestaat bij SLA’s.

De gebruikersorganisatie stelt functionele eisen aan de onderhoudsorganisatie. Deze functionele eisen kunnen niet in een SLA worden vastgelegd, omdat zoals eerder geschreven is, beheer van functionele eisen niet uitbesteed kan worden aan een andere partij dan de gebruikersorganisatie. De gebruikersorganisatie stelt tevens prestatie-eisen aan de verwerkingsorganisatie, terwijl de verwerkingsorganisatie eisen kan stellen aan de gebruikersorganisatie in de zin van maximale gebruiksbelasting. De onderhoudsorganisatie maakt gebruik van de verwerkingsorganisatie, daarom kunnen in een SLA bepaalde kwaliteitseisen vastgelegd worden over dit gebruik. De verwerkingsorganisatie tenslotte zou d.m.v. een SLA eisen kunnen stellen aan derden, zoals leveranciers van hardware en publieke netwerken.
De essentie in dit figuur is dus, dat de gerbuikersorganisatie afspraken maakt over de prestatie-eisen met de verwerkingsorganisatie, daarom moet de verwerkingsorganisatie ook weer afspraken maken met andere partijen.

Een bekend model, ontwikkeld door de TU Delft, de TU Eindhoven en de VU Amsterdam, gebaseerd op ervaring in de praktijk is een model voor Service Management. In het model worden twee terreinen onderscheiden: Service Level Management en Service Proces Management. Zie onderstaand figuur. Tussen deze twee terreinen bestaat in de praktijk veelal een kloof. In het model vormt een SLA de spil tussen deze terreinen.

Service Management begint met een klant met een behoefte aan IT-diensten. Deze behoefte dient gespecificeerd en gekwantificeerd te worden in een SLA. Een SLA dient uitgangspunt te zijn, voor zowel een IT-dienstverlener als een klant voor het specificeren en inrichten van IT-diensten. De inrichting, de inspanningen en de resultaten van de IT-dienstverlening dienen vervolgens bewaakt te worden, dit noemen we Service Proces Management, uiteraard aan de hand van de ontwikkelde SLA’s. Daarna kan terugkoppeling, in termen van evaluatie en verbetering van de dienstverlening, tussen klant en leverancier plaatsvinden. Vervolgens kan het Service Management model opnieuw worden doorlopen.

Service Management kunnen we besturen volgens het onderstaand besturingsmodel:

Zoals in ieder besturingsmodel geldt, onderkennen we ook in dit model planning en beheersing. Het Service Level Management zorgt ervoor dat de klant en de leverancier tot een SLA komen, welke verder vertaald wordt in een serviceplan. Dit serviceplan heeft het doel om de automatiseringsmiddelen, zoals hardware en progarmmatuur te beheren. De uitvoering van dit serviceplan dient beheerst te worden, dit noemen we zoals al eerder gezegd, Service Proces Management. Om dit beheersproces te ondersteunen, worden er service-rapporten opgesteld, die de resultaten beschrijven van de bewaking van de serviceplannen. Service Level Reports tenslotte worden opgesteld om de voortgang te tonen van de naleving van het SLA.

Tenslotte willen we u in deze paragraaf een moderne visie laten zien op Service Level Agreements. Zoals uit onderstaande figuren blijkt, sluit een gebruikersorganisatie een SLA af met een Servicemakelaar. Deze Servicemakelaar, die op het ondersteunende niveau werkt, heeft ook weer een soort van SLA’s afgesloten met verschillende Service Providers. Service Providers kunt u zien als verleners van bepaalde diensten op het uitvoerende niveau. Deze SLA’s die de Servicemakelaar afsluit met de Service Providers noemen we Service Process Agreements. Bijvoorbeeld: een gebruikersorganisatie heeft een SLA afgesloten met een helpdesk. De helpdesk is als het ware de schakel tussen de gebruikers en de techniek. Vanuit de beheerders van de techniek, de Service Providers, komen incidentmeldingen en wijzigingsvoorstellen naar boven en ook de gebruikers melden incidenten en wijzigingsvoorstellen aan de helpdesk. De helpdesk heeft de taak al deze incidenten af te handelen en de wijzigingsvoorstellen te behandelen volgens een vastgesteld wijzigingenbeheer.



ITIL

ITIL is een veel gehoord begrip in de wereld van het Service Management. In deze paragraaf willen we u in het kort kennis laten maken met ITIL.

ITIL staat voor IT-Infrastructure Library. ITIL, een publicatie van de Engelse overheidsinstelling CCTA (Central Computer and Telecommunications Agency), is ontwikkeld omdat erkend werd dat organisaties steeds afhankelijker worden van informatiesystemen. Zonder informatiesystemen kunnen de meeste bedrijven niet meer functioneren, maar een gekwalificeerde IT-service is essentieel voor optimaal functioneren. Klanten willen waar voor hun geld en de geleverde service moet afgestemd zijn op de behoeften van de klanten. Effectief en efficiënt management van IT services is cruciaal. ITIL documenten bieden een ondersteuning in het verbeteren van deze efficiëntie en effectiviteit door het aanbieden van een verzameling 'best practices' voor IT service management. Door gebruik te maken van deze best practices kan men tot een systematische aanpak komen van het IT service management. Dit biedt dan onder andere de volgende voordelen:
 

  • De klanttevredenheid neemt toe omdat IT services zijn afgestemd op de behoefte van de klant.
  • Verkleining van het risico tot het niet kunnen voldoen aan wensen van de klanten.
  • Betere communicatie en informatievoorziening tussen management en klanten.
  • De klant kan zich bekommeren over core business en kan IT service over laten aan IT servicemanagement.
  • ITIL biedt een gemeenschappelijke taal waarmee informatieuitwisseling kan plaatsvinden tussen organisaties en medewerkers.

Voor het realiseren van de dienstverlening is het van belang dat gemaakte afspraken worden omgezet in activiteiten. Deze activiteiten worden binnen ITIL gegroepeerd tot processen: de voornaamste processen zijn in twee hoofdgroepen gebundeld, Service Support en Service Delivery.

Service Support Set :
 

  • Configuration Management: Configuration management ondersteunt het leveren van hoog gekwalificeerde IT-Services door het onder controle brengen van de IT-infrastructuur en het verzorgen van de informatievoorziening over de IT-infrastructuur. Een goed ingerichte Configuratie Database biedt de basis voor registratie, probleem-, en impactanalyse.
  • Helpdesk ofwel Incident Management: Het doel van Incident Management is het uitvoeren van een onafhankelijk gebruikers-georienteerde bewaking en afhandeling van productieverstoringen, zodat het daardoor verminderde serviceniveau zo spoedig mogelijk kan worden hersteld.
  • Problem Management: Doelstelling van Problem Management is om door het nemen van structurele maatregelen herhaling van verstoringen te voorkomen. Door fouten structureel weg te nemen of te voorkomen wordt een zo hoog mogelijke stabiliteit van de IT-infrastructuur bereikt. Hierdoor kan de beschikbaarheid van de dienstverlening aan de gebruiker verbeteren.
  • Change Management: Change Management heeft tot doel om op een gestructureerde wijze wijzigingen in de IT-infrastructuur door te voeren, zodat aan wijzigingen gerelateerde problemen kunnen worden voorkomen.
  • Software Control & Distribution impression: Software control & distributie heeft tot doel het zekerstellen van alle software en de garantie , dat alleen geteste en juiste versies van geautoriseerde software beschikbaar worden gesteld voor productie.

Service Delivery Set :
 

  • Availability Management: Availability management richt zich op de continuïteit van de informatievoorziening gezien vanuit de gebruikers. Wanneer dienen welke applicaties beschikbaar te zijn?
  • Capacity Management: Capacity management richt zich op de juiste sizing van de Technische Infrastructuur waarbij een directe link met performance-eisen gelegd moet worden.
  • Contingency Planning: Contingency planning omvat alle activiteiten die uitgevoerd moeten worden om de gevolgen van een calamiteit, waardoor de Informatievoorziening stagneert, zoveel mogelijk te beperken.
  • Cost Management: Cost management richt zich op doorbelasting en kostenbewaking waarbij een goede prijs/performance t.a.v. de Informatievoorziening van wezenlijk belang is.
  • Service Level Management: zie de vorige paragraaf.

Trends

  • We zien naast het ontwikkelen meer aandacht voor de exploitatie en het beheer van het informatiesysteem. Dit is een belangrijke verbetering daar een klant immers vooral geïnteresseerd dient te zijn in de "run phase' van het informatiesysteem.
  • We zien een nieuwe generatie applicaties verschijnen ( in de vorm van actieve objecten ) die zich zelf een aantal beheertaken kunnen uitvoeren zoals : zoals back-up / recovery, autorisatie zaken.
  • Er komt een nieuwe generatie van plug-and-play software componenten die in onderhoudsslagen via het Internet zullen worden aangeboden.
  • Beheer op afstand.
  • Push technologie geeft een nieuwe mogelijkheid tot actieve maintenance.

Statements

  • Continuïteit is bij beheer / system management nog veel essentiëler dan bij systeemontwikkeling. Bij onmin is de afhankelijkheidsrelatie veel sterker en opzeggen is niet eenvoudig.
  • System Management is balanceren tussen veranderen en stabiliseren
  • balans tussen flexibel en betrouwbaar
  • balans tussen efficiency en effectiviteit
  • balans tussen zelf doen en uitbesteden.
  • Beheer begint tijdens ontwikkeling. Daarom dient het toekomstig beheerpersoneel al tijdens de ontwikkeling te worden geïnvolveerd.
  • Beheerfaciliteiten horen tijdens de ontwikkelingen te worden mee ontworpen en mee gebouwd, beter nog is dat beheer en test faciliteiten intrinsiek in het informatiesysteem aanwezig zijn.
  • Beheer is geen vorm van brandblussen.
  • Beheer dient te worden uitgevoerd door eerste klas personeel. De uitdaging in het beheer ligt in het feit om middels actief beheer te zorgen dat de economische levensduur van de informatiesystemen wordt verlengd.
  • Adequaat beheer kan, net als systeemontwikkeling, niet meer zonder tools.
  • In een SLA dient de business benefit duidelijk te zijn geformuleerd. Bedrijfsvoering van de klantorganisatie is leidend.
  • ITIL is geen doel maar een referentiekader.

Oefeningen

  • Beschrijf hoe het beheer van de informatievoorziening plaats vindt in uw bedrijf.
  • Beschrijf de organisatie van beheer en noem een aantal beheertaken in uw bedrijf.
  • Beschrijf een Service Level Agreement van een dienst waarvan u gebruik maakt.

Vragen

  • Waarom dient er te worden beheerd en wat moet er worden beheerd?
  • Wat voor soort gebruiker ben jij, en in welke situaties?
  • Noem voordelen en nadelen van outsourcing.
  • Bij probleembeheer is coördinatie op operationeel niveau voldoende. Geldt dit ook voor wijzigingsbeheer?

Definities

adaptief onderhoud
Adaptief onderhoud is het aanpassen van één of meer delen van het informatievoorzieningssysteem als gevolg van wijzigingen in de omgeving van die delen. Adaptief onderhoud kan worden veroorzaakt door onderhoud aan een ander deel (meestal in een onderliggende laag) van het informatievoorzieningssysteem, door wijziging van een ander informatievoorzieningssysteem waarmee een interface bestaat, of door gewijzigde regelgeving voor de bedrijfsfunctie die wordt ondersteund.

bedrijfsvoering van informatievoorziening
Bedrijfsvoering van informatievoorziening is het gebruiken, exploiteren en onderhouden van een informatievoorzieningssysteem zodanig dat dit voldoet en blijft voldoen aan vastgelegde en vanzelfsprekende behoeften. Onder vastgelegde behoeften vallen zowel de beschreven functionaliteit als kwaliteitseisen.

correctief onderhoud
Correctief onderhoud is het herstellen van afwijkingen in componenten van het informatievoorzieningssysteem. Afhankelijk van het object van onderhoud kan dit variëren van het verwijderen van bugs uit de applicatieprogrammatuur tot het verhelpen van storingen in de apparatuur. Bij correctief onderhoud blijven het gebruik en de exploitatie van de informatievoorziening ongewijzigd.

economische levensduur
De economische levensduur van een informatiesysteem loopt vanaf de invoering tot aan het moment dat vervanging van het informatiesysteem goedkoper wordt dan voortzetting van het beheer en het onderhoud.

exploitatie
Exploitatie-uitvoering is het operationeel beschikbaar stellen van een applicatie, tezamen met de onderliggende gegevens en technische infrastructuur.

incident
Men spreekt in de informatievoorziening van een incident wanneer er een voorval plaatsvindt waarbij een gebruiker of een verwerkingsmedewerker constateert of vermoedt dat het functioneren van het informatievoorzieningssysteem is verstoord.
Een incident kan voortkomen uit verkeerde handelingen of onkunde, maar kan ook het gevolg zijn van een storing of een fout. Ook een alarm is een aanleiding voor een incident.

levenscyclus van een informatiesysteem
Onder de levenscyclus van een informatiesysteem wordt verstaan: de reeks van stadia van het bestaan van een informatiesysteem. Deze cyclus loopt vanaf zijn concipiëring, initieel ontwerp, bouw en invoering, via een periode van gebruik en beheer waarin (klein of groot) onderhoud plaats vindt, tot en met het moment waarop het informatiesysteem geen betekenis meer heeft voor het bedrijf en uit bedrijf wordt genomen.

onderhoud
Onderhoud is het wijzigen of aanvullen van een bestaand informatievoorzieningssysteem. We kunnen onderhoud indelen in vijf soorten onderhoud: correctief onderhoud, preventief onderhoud, adaptief onderhoud, perfectief onderhoud en onderhoud van functionaliteit.

onderhoud van functionaliteit
Onderhoud van functionaliteit omvat het uitbreiden of wijzigen van de functionaliteit van het informatievoorzieningssysteem.

perfectief onderhoud
Perfectief onderhoud is het aanpassen van een component van het informatievoorzieningssysteem aan veranderde kwaliteitseisen van de gebruikers.

preventief onderhoud
Preventief onderhoud is het corrigeren van componenten van het informatievoorzieningssysteem, zonder aanleiding in de vorm van een probleemrapport. Doel van preventief onderhoud is: (a) het voorkomen van toekomstige problemen, of (b) het verhogen van de onderhoudbaarheid.

probleem als operationeel tekort in informatievoorziening
Men spreekt in de informatievoorziening van een probleem wanneer is vastgesteld dat er in de automatiseringsmiddelen een storing of fout is. Deze situatie wordt geconstateerd aan de hand van incidenten, of op basis van symptomen.

probleembeheer
Probleembeheer omvat het afhandelen van incidentmeldingen en probleemmeldingen aangaande automatiseringsmiddelen.

service level agreement
Een service level agreement (SLA) is een stelsel van afspraken over het kwaliteitsniveau van een dienst.

service level management
Service level management (SLM) omvat het afstemmen en vastleggen van afspraken (planning) en het zorgdragen voor het nakomen daarvan (control).

service level report
Een service level report (SLR) is een, door het service management op te stellen, verslag over de kwaliteit van een dienstverlening.

service management van bedrijfsvoeringsfuncties
Het service management (SRM) richt zich op de interne gang van zaken. De afspraken, die het service level management is aangegaan, worden hier vertaald naar service-plannen. De service-rapporten worden geverifieerd tegen het service-plan, en naar het service level management gerapporteerd door middel van service level reports.

serviceplan
In het serviceplan zijn alle service level agreements vertaald in interne criteria. Deze criteria hebben betrekking op de inrichtingsaspecten en op de te verrichten handelingen en begeleiding daarvan.

technische levensduur
De technische levensduur van een informatiesysteem loopt vanaf de invoering tot het moment waarop a) verder onderhoud van het informatiesysteem onmogelijk of onbetaalbaar wordt, èn b) de gewenste informatie niet langer kan worden geproduceerd.

wijzigingenbeheer
Wijzigingenbeheer omvat het afhandelen van wijzigingsvoorstellen/probleemrapporten en wijzigingsverzoeken aangaande automatiseringsmiddelen.

wijzigingsverzoek
Een wijzigingsverzoek is verzoek tot wijziging van één of meer onderdelen van het informatievoorzieningssysteem. Deze wijzigingen kunnen het gevolg zijn van veranderde behoefte (wijzigingsvoorstellen) of van ondervonden problemen.

wijzigingsvoorstel
Een wijzigingsvoorstel is het initiatief van gebruikers of verwerkingspersoneel waarbij wordt voorgesteld, een bepaalde wijziging in het informatievoorzieningssysteem aan te brengen.

Literatuurverwijzingen

  • G.P.A.J. Delen en M. Looijen, Beheer van de informatievoorziening, Rijswijk, Cap Gemini Publishing, 1992.
  • Sander Koppens, Bas Meyberg, Operationeel beheer van Informatiesystemen, Pink Elephant, 1993
  • Kochs, …
vorig artikelvolgend artikel
website: Daan Rijsenbrij