• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Informatiemanagement
Informatiemanagement
3 vormen van beheer
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

informatievoorziening applicaties technische infrastructuur informatie

Vanaf het begin van mijn loopbaan binnen de informatievoorziening - waarin ik - nota bene - begon in de functie van 'functioneel applicatiebeheerder'- ben ik gefascineerd door het feit dat terminologisch gezien het vakgebied zich kenmerkt door een hoge make van begripsverwarring en dat het zowel aan 'newbies' en 'mensen van buiten' lastig uitleggen is wat er verstaan wordt onder de verschillende vormen van beheer.

Om het op zijn minst voor mezelf helder te krijgen, hierbij een poging om te komen tot een definitie van de drie beheervormen:

Beheervorm Beheerobject Definitie Synoniemen
Functioneel beheer Informatievoorziening Instandhouden en onderhouden van de informatievoorziening voor het ondersteunen van processen door het bieden van functionaliteit voor het tijdig en juist verwerken, gebruiken en beheren van informatie. Business informatiemanagement
Applicatiebeheer Applicaties + gegevensverzamelingen
Instandhouden en onderhouden van de applicaties en bijbehorende gegevensverzamelingen. Applicatiemanagement
Technisch beheer Technische infrastructuur
Beschikbaar stellen en in stand houden en onderhouden van de technische infrastructuur. IT Service management

Een deel van de verwarring is dat in de benamingen van de drie vormen van beheer het object van beheer niet expliciet wordt benoemd. Alleen in de term 'applicatiebeheer' komt het object terug: applicatie. Soms wordt ook gesproken over 'applicatief beheer'. Dan is op zijn minst consistentie bereikt in het bijvoeglijke naamwoord, maar rest nog de vraag wat er dan daadwerkelijk wordt beheerd.

Binnen nieuwe termen is de term 'beheer' vaak vervangen door 'management'. Op z'n minst sexier klinkend, maar nog steeds wordt hierdoor nog niet helder waarover het gaat.

Zonder toelichting bij de term 'onderhoud' is bovendien lastig om aan te geven waar 'onderhouden' ophoudt en het 'vernieuwen' begint.

De toevoeging in de definitie 'tegen overeengekomen kosten en kwaliteit' geeft een inkleuring aan hoe het beheer zou kunnen worden ingevuld, maar is mijns inziens niet strikt noodzakelijk om de beheervorm(en) af te bakenen.
Het opnemen van beschrijvingen als 'tijdens de gehele cyclus van informatiesystemen' cq. 'levenscyclus van informatiesystemen' brengt meer dynamiek in de definitie omdat het impliceert dat regelmatig aanpassingen noodzakelijk zijn als gevolg van interne en/of externe ontwikkelingen. Deze dynamiek zit mijns inziens echter al begrepen in de term onderhoud.

Het is slechts een bescheiden aanzet, reacties zijn welkom.

Wordt vervolgd.....

-----vervolg-1------------------------------------------------------------------------------------------------

Hieronder zijn ook vier rollen geplot:

beheervormen functioneel beheer informatiemanagement

Ik heb in de definitie bij technische beheer het 'beschikbaar stellen' geskipt en bij alle drie beheervormen 'vernieuwing'  toegevoegd. Dit betekent dat - letterlijk - het verschil tussen de drie vormen van beheer zit in het object van beheer. De grens tussen 'adaptief onderhoud' en 'vernieuwen' is grijs, maar op deze manier krijgen de definities expliciet een iets dynamischer, duurzamer insteek.

Ter toelichting op 'onderhouden' heb ik - gebaseerd op een eerdere blogpost Beheer volgens Bart de Best - hieronder de vijf vormen van onderhoud beschreven.

Onderhoudsvorm Beheerobject
Correctief onderhoud Herstellen van gebreken in een applicatie.
Additief onderhoud Uitbreiden van de functionaliteit van de applicatie.
Adaptief onderhoud Aanpassen van de applicatie om te blijven voldoen aan de eisen die gesteld worden  aan wijzigingen in de omgeving (ontwikkelingen keten, technologie of bedrijfsproces).
Perfectief onderhoud Aanpassen van de applicaties zodat deze beter prestaties levert.
Preventief onderhoud Tijdig nemen van maatregelen om verstoringen te voorkomen.

 

Beheervorm Beheerobject Definitie Synoniemen
Functioneel beheer Informatievoorziening Instandhouden, onderhouden en vernieuwen van de informatievoorziening voor het ondersteunen van processen door het bieden van functionaliteit voor het tijdig en juist verwerken, gebruiken en beheren van informatie.

Business informatiemanagement
Applicatiebeheer Applicaties + gegevensverzamelingen
Instandhouden, onderhouden en vernieuwen van de applicaties en bijbehorende gegevensverzamelingen. Applicatiemanagement
Technisch beheer Technische infrastructuur
Instandhouden, onderhouden en vernieuwen van de technische infrastructuur. IT Service management

 

Zie ook:



 

Laatst aangepast op vrijdag, 17 november 2017 22:08  
Sleutelen aan de informatievoorziening: functionele wijzigingen
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

wijziging functionaliteitenbeheer wijzigingenbeheer functioneel beheer functionaliteit

Het object van functioneel beheer is de (functionaliteit van de) informatievoorziening. Deze functionaliteit kun je gecontroleerd wijzigen via een vooraf afgestemd, zorgvuldig uitgevoerd wijzigingsproces. Je kunt ook hap-snap de functionele motorkap  opengooien en - on-the-fly - gaan sleutelen.

In bovenstaande figuur zijn twee varianten van het sleutelen aan de informatievoorziening beschreven. In het eerste geval blijft de functionaliteit van de informatievoorziening ongewijzigd (bijv. het aanpassen van een parameter). In het tweede geval verandert de functionaliteit van de informatievoorziening wél. Voor deze functionele wijzigingen zijn binnen BiSL best practices beschreven in het procescluster Functionaliteitenbeheer en de processen Wijzigingenbeheer en Transitie.

Laatst aangepast op maandag, 01 januari 2018 12:54  
3 vormen van beheer volgens Ruigrok & Bosschers (2)
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

3 beheervormen functioneel beheer applicatie technisch beheer

In het boek Functioneel beheer beschrijven Kees Ruigrok en Ernst Bosschers de drie vormen van beheer als volgt:

functioneel beheer vormen ruigrok bosschers

Technisch beheer is verantwoordelijk voor het tegen overeengekomen kosten en kwaliteit beschikbaar stellen en in stand houden van de technische infrastructuur waarvan de ICT-systemen gebruikmaken, en de diensten die daarvoor nodig zijn.

Applicatiebeheer is verantwoordelijk voor het tegen overeengekomen kosten en kwaliteit in stand houden en onderhouden van de bedrijfsapplicaties en de bijbehorende gegevensverzamelingen tijdens de gehele cyclus van de informatiesystemen.

Functioneel beheer is verantwoordelijk voor het tegen aanvaardbare kosten en kwaliteit in stand houden van de gewenste informatievoorziening ten behoeve van de gebruikersorganisatie tijdens de gehele levenscyclus van informatiesystemen. Daaronder verstaan we alle te ondernemen acties voor een ongestoorde informatievoorziening van de gebruikersorganisatie. Maar ook het met technisch beheer afspreken welke diensten zullen worden geleverd, wat van een servicedesk zal worden verwacht, et cetera.

In de voorgaande beschrijvingen vallen misschien een paar woorden op. Het begrip levenscyclus wordt gebruikt om duidelijk te maken dat zowel de organisatie, als de gewenste informatievoorziening, zich door interne en externe oorzaken ontwikkelen. Het invoeren, aanpassen en ten slotte afvoeren van de informatiesystemen moet plaatsvinden binnen het perspectief van die ontwikkelingen en veranderingen.

Het gaat uitdrukkelijk om de zo optimaal mogelijke ondersteuning van de bedrijfsprocessen door een goede informatievoorziening en daardoor het bijdragen aan de realisatie van de organisatiedoelstellingen. Functionaliteit betekent dat de correcte gegevens op het juiste moment en op de juiste plaats beschikbaar zijn en gebruikt kunnen worden. Er staat in de definitie van functioneel beheer het woord informatievoorziening en niet het woord applicaties, want het werkterrein van de functioneel beheer is niet beperkt tot geautomatiseerde systemen, maar strekt zich ook uit over de informatievoorziening die (nog) niet geautomatiseerd is, of niet geautomatiseerd zal worden.

 

Bron: Functioneel beheer - Kijk op bedrijfsprocessen, informatievoorziening en ICT, Kees Ruigrok, Ernst Bosschers

 

Laatst aangepast op maandag, 01 januari 2018 12:55  
Dienende architecten volgens Viktor Grgic
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

dienende architecten architectuur

 

Het lijkt bijna een contradictio in terminis, maar Viktor Grgic beschrijft de eigenschappen van een 'dienende architect':

 

Directieve architecten Dienende architecten
Aandacht voor architectuur zelf Aandacht voor belanghebbenden
Architectuur is een product geleverd door een of meer architecten Architectuur is het resultaat na samenwerking met bouwers
Architectuurraamwerk en modelleertechniek staan centraal in communicatie Common sense en eenvoud zijn het belangrijkst in communicatie
Architecten zijn bewakers en zorgen ervoor dat iedereen de uitgestippelde lijn volgt Architectuurbewaking komt voort uit een gevoel van verantwoordelijkheid van zowel bouwers als architecten
Bepaalt alle kaders waarbinnen engineers zich mogen begeven. Definieert en draagt één visie uit
Bedenkt en bewaakt de architectuur Initieert, faciliteert en coördineert het proces

 

diendende architectuur architecten

De dienende architect geeft aandacht aan belanghebbenden en hun belangen en zorgen.

Iedere zin of een plaatje in een architectuurdocument is gemaakt om te worden begrepen door de lezer. Desnoods zou de architect speciaal voor iedere lezer een eigen "Jip en Janneke" plaatje moeten maken, zodat iedereen begrijpt. Een architectuur is geschreven op basis van vragen van belanghebbenden.

Als niemand om bepaalde informatie vraagt, dan heeft het geen nut om die te beschrijven. Het feit dat je als architect weet dat er een vraag gaat komen, is nog geen reden om die nu al te gaan beantwoorden. Het is namelijk nooit bekend wat die vraag exact is en op welke manier de belanghebbende zijn antwoord wenst te hebben. Met andere woorden, net op tijd, net genoeg besluiten en communiceren. Deze manier van omgang met architectuur wordt vaak Emerging Architecture [Gartner, 2009] genoemd.


Bron: De Dienende Architect, Viktor Grgic (22 mei 2010)

Laatst aangepast op maandag, 01 januari 2018 12:55  
Premature precisie volgens Robert C. Martin
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

robert martin premature precisie


Both business and programmers are tempted to fall into the trap of premature precision. Business people want to know exactly what they are going to get before they authorize a project. Developers want to know exactly what they are supposed to deliver before they estimate the project. Both sides want a precision simply cannot be achieved, and are often willing to waste a fortune trying to attain it.

Robert C. Martin

Laatst aangepast op maandag, 01 januari 2018 12:55  
Het doel van user stories volgens Mike Cohn
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

user stories mike cohn

Laatst aangepast op maandag, 01 januari 2018 12:54  
10 BIT-regels voor ICT-projecten volgens Elias & co.
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

beginnen bezinnen BIT regels ict-projecten

De parlementaire onderzoekscommissie (Ton Elias, Paul Ulenbelt, Manon Fokke, Hanke Bruins Slot en Paul van Meenen) kwam tot de conclusie dat de rijksoverheid haar ICT-projecten niet onder controle heeft. Om de besturing en beheersing van ICT-projecten op orde te krijgen stelt (lees: orde in de chaos te brengen) stelt de commissie voor een tijdelijke ICT-autoriteit op te richten: Het BIT (Bureau ICT-toetsing) die alle projecten van de rijksoverheid boven de 5 miljoen euro (waarbij de ICT-component een belangrijke rol speelt) voorafgaand aan een aanbesteding te toetsen op 10 zgn. BIT-regels:

  1. Stel een zakelijke rechtvaardiging op waar alle belangrijke onderdelen om een besluit gedegen te kunnen nemen in voorkomen.

  2. Toon de meerwaarde van het project aan voor de eindgebruiker en de samenleving.

  3. Zorg voor draagvlak bij alle betrokken partijen, inclusief de eindgebruikers, en toets op organisatorische, bestuurlijke en technische haalbaarheid.

  4. Reorganiseer en standaardiseer eerst de werkprocessen die met ICT worden ondersteund en ga pas daarna automatiseren.

  5. Breng de technische, organisatorische en bestuurlijke risico's en risicomaatregelen in kaart en elimineer «doormodderen» op voorhand.

  6. Zorg ervoor dat de verantwoordelijkheid voor het budget én de opdracht bij één persoon liggen.

  7. Faseer de ontwikkeling van het ICT-project zo efficiënt mogelijk en probeer daarbij per fase direct bruikbare producten op te leveren.

  8. Sluit aan op de standaarden bij de rijksoverheid en toon de technische haalbaarheid aan.

  9. Toon aan hoe er van het begin tot het einde van een project voor gezorgd wordt dat kritiek en tegengeluiden mogelijk zijn en ter harte genomen worden. Openheid en transparantie zijn hierbij het uitgangspunt.

  10. Neem een heldere aanbestedingsstrategie op in de zakelijke rechtvaardiging.

Ergo: het venijn zit in de start! Zelfs bij ICT-projecten van de rijksoverheid lijkt bezinnen voor het beginnen dé beste insteek. Misschien iets voor een tegeltje....

Zie ook: 8 gouden regels bij IT-investeringen: Raines Rules

Bron: Eindrapport Parlementair onderzoek naar ICT-projecten bij de overheid



Laatst aangepast op vrijdag, 17 november 2017 22:06  
Informatie-architectuur binnen BiSL
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

informatie-architectuur informatie portfoliomanagement bisl proces

In een poging te komen tot een inrichtings-, organisatie-onafhankelijke indeling van de informatievoorziening ('domeinindeling'), was ik me er in eerste instantie niet van bewust dat ik bezig wat met het praktiseren van de strategische BiSL-processen: informatie lifecycle management en informatie portfoliomanagement. Hieronder een selectieve samenvatting van mijn BiSL-samenvatting en een aantal fragmenten uit het boek De functioneel beheerder en BiSL om helder te krijgen hoe een beschrijving van het opdelen van de informatievoorziening in zgn. informatiedomeinen (lees: het opstellen van een informatie-architectuur) past binnen de strategische BiSL-laag.

Binnen de strategische BiSL-processen wordt het procescluster Opstellen informatiestrategie onderscheiden. Dit procescluster heeft als doel het bepalen hoe de toekomstige informatievoorziening er uit gaat zien (waarbij de informatievoorziening op lange(re) termijn de bedrijfsprocessen optimaal blijft ondersteunen) en bestaat uit vijf processen:

  1. Bepalen ketenontwikkelingen: inventariseren ontwikkelingen op het gebied van de informatie-uitwisseling met andere organisaties (keten) + het vertalen naar gevolgen voor eigen informatievoorziening.

  2. Bepalen bedrijfsprocesontwikkelingen: inventariseren ontwikkelingen in de organisatie en de bedrijfs-processen + het vertalen naar gevolgen voor de informatievoorziening.

  3. Bepalen technologie-ontwikkelingen: bepalen welke technische ontwikkelingen interessant kunnen zijn voor de organisatie en informatievoorziening.

  4. Informatie lifecycle management: vaststellen van de hoofdlijnen van de (toekomstige functionaliteit van de) informatievoorziening voor een specifiek informatiedomein.

  5. Informatie portfoliomanagement: zorg dragen voor een, vanuit bedrijfsbrede optiek, optimale inzet van middelen en opzet en invulling van de informatievoorziening.

 

Ad (4) Informatie lifecycle management

Informatie lifecycle management heeft als doel het opstellen van een strategie voor de informatievoorziening voor alle specifieke informatiedomeinen (vaak zijn deze gekoppeld aan specifieke bedrijfsprocessen). Voor elk domein wordt vastgesteld wat de behoeften voor beheer, onderhoud en vernieuwing. Bij het bepalen van de behoeften wordt aan de ene kant rekening gehouden met de ontwikkelingen op langere termijn op het vlak van: (a) de bedrijfsprocessen, (b) met de omgeving van de organisatie, en (c) met de technologie. Daarnaast wordt ook rekening gehouden met de huidige staat van de informatievoorziening per domein en de daarbinnen bestaande structurele knelpunten en problemen en het organisatiebeleid. De concrete output van dit proces bestaat uit: (i) een statusrapport (status informatievoorziening per informatiedomein), en (ii) een informatiestrategie (schetsen van toekomstige informatievoorziening + scenario’s per informatiedomein). Het proces informatie lifecycle management geeft dus invulling aan een onderdeel van het totale informatiebeleid van de organisatie, namelijk de toekomstbepaling voor de afzonderlijke onderdelen van de totale informatievoorziening.

Het proces Informatie portfoliomanagement zorgt voor de overkoepelende afstemming over het geheel van de informatievoorziening + het opstellen van een portfolio van alle IV-objecten op hoofdlijnen. Dit resulteert in drie concrete producten: (i) informatiearchitectuur (indeling/structuur informatievoorziening), (ii) informatiebeleid (beleid voor de informatievoorziening), en (iii) een portfolioplanning (incl. besluitvorming over veranderingsbehoeften).

Hét verschil tussen informatie lifecycle management en informatie portfolionmanagement is dan ook dat informatie lifecycle management zich richt op specifieke informatiedomeinen, terwijl informatie portfoliomanagement gericht is op het bepalen van de strategie voor het geheel van de informatievoorziening. De uiteindelijke output van informatie portfoliomanagement is een informatiestrategie met een beschrijving (schets) hoe de informatievoorziening er op lange termijn uit gaat zien per informatiedomein, welke stappen en activiteiten (scenario’s) nodig zijn, wat de impact is voor andere delen van de informatievoorziening (relaties) en inschatting van de kosten en baten.

De overeenkomst tussen beide processen is dat beide zich bezig houden met het opstellen van informatiebeleid. De relatie tussen deze twee ‘informatiebeleidprocessen’ is dat elke voorgestelde strategie voor de informatievoorziening van betrokken informatiedomeinen moet worden afgestemd met het grotere geheel (en dat gebeurt binnen informatie portfoliomanagement). 


Ad (5) Informatie portfoliomanagement

Het proces informatie portfoliomanagement draagt zorg voor een overkoepelende afstemming en uniformiteit over het geheel van de informatievoorziening. Het gaat hierbij om het geheel en samenhang tussen de verschillende delen van de informatievoorziening. Doel van informatie portfoliomanagement is het – vanuit bedrijfsbrede optiek – zorgen voor een optiek optimale inzet van middelen en opzet van de informatievoorziening en het afstemmen van verschillende (deel)plannen voor de toekomstige ontwikkeling van de informatievoorziening. Belangrijk hulpmiddel hierbij is het opstellen en onderhouden van een portfolio met daarin de objecten van informatievooziening op hoofdlijnen (incl. veranderingsbehoefte). Het werken met een portfolio maakt het mogelijk bedrijfsbrede en bedrijfsbreed gedragen beslissingen genomen over uit te voeren veranderingen.

Binnen informatie portfoliomanagement spelen drie hoofdonderwerpen:

(1) Structuur van de informatievoorziening
Het proces informatie portfoliomanagement houdt zich bezig met de structuur van de informatievoorziening door te bepalen op welke wijze de informatievoorziening wordt opgedeeld (in informatiedomeinen) en wat de samenhang (relaties, koppelvlakken) is tussen de verschillende delen: de zgn. informatiearchitectuur. Een informatiearchitectuur kan worden gedefinieerd als een beschrijving/visualisatie van de gehele informatievoorziening waarbij de informatievoorziening is opgedeeld in zgn. informatiedomeinen.

(2) Portfolio: het geheel aan veranderingen in de informatievoorziening
Het proces informatie portfoliomanagement houdt zich – op een overkoepelend niveau – bezig met het afstemmen van alle gewenste en voorgenomen veranderingen voor de gehele informatievoorziening en het waarborgen dat ook in de toekomst een optimale aansluiting tussen de bedrijfsprocessen en de informatievoorziening bestaat.  De kern van portfoliomanagement is het inzichtelijk krijgen van alle veranderingen en oplossingsmogelijkheden op het geheel van de informatievoorziening en het afstemmen over het gehele domein van informatievoorziening heen, welke veranderingen wel doorgezet gaan worden en welke niet.

(3) De gebruikte middelen van de informatievoorziening: standaardisatie
Het proces informatie portfoliomanagement definieert welke afspraken gemaakt worden over de inzet van ICT-hulpmiddelen. Het gaat dan over het opstellen van de infrastructuurarchitectuur en een ontwikkelarchitectuur.

Informatie portfoliomanagement resulteert - in lijn met de drie hoofdonderwerpen - in drie concrete producten:
-    Informatie-architectuur (indeling op hoofdlijnen van de informatievoorziening)
-    Informatiebeleid (beleid ten aanzien van informatievoorziening)
-    Portfolioplanning (besluitvorming grootschalige veranderingsbehoeften)


richtinggevende processen bisl

De richtinggevende processen houden zich bezig met de (middel)lange termijn: binnen deze processen wordt beschreven hoe de informatievoorziening zich de komende drie tot vijf jaar zal (moeten) ontwikkelen. Er wordt ook bepaald, hoe de organisatie van business informatiemanagement zal worden vormgegeven; dat wil zeggen wat voor ondersteuning wenselijk is en hoe dit kan worden gerealiseerd. De processen worden door de informatiemanager uitgevoerd in nauw overleg met iedereen die daarvoor nodig is: zoals business management, bedrijfs- en procesarchitecten en informatiearchitecten, want informatievoorzieningsplannen zijn afgeleid van het bedrijfsbeleid, maar ook IT-serviceverleners zijn bij het opstellen van de strategie betrokken. Meerjarenplannen worden dus gemaakt voor de informatievoorziening en voor de wijze waarop die zal worden ingericht en ondersteund.

(...)

Informatie-lifecylemanagement

Voor specifieke informatiedomeinen (gekoppeld aan bedrijfsprocessen) worden scenario's ontwikkeld. Deze scenario's geven aan hoe de huidige situatie van de informatievoorziening zich in een aantal stappen zal gaan evolueren tot de gewenste informatievoorziening en de bijbehorende systemen die zo nodig ondersteund worden door applicaties. Vanzelfsprekend zullen een globaal beeld van kosten, baten, sterkten, zwakten en ruwe planning niet mogen ontbreken. Kortom, er ontstaat een rapport voor de informatiestrategie.

Informatie-portfoliomanagement

Dit proces dient ervoor om een overkoepelend beeld te krijgen van de ontwikkelingen van de informatiedomeinen, vastgelegd in scenario's. Het resultaat is een portfolio van het geheel van de veranderingen en hun onderlinge samenhang: de portfolioplanning.

Afstemming van de afzonderlijke scenario's vindt plaats waarbij afspraken worden vastgelegd over standaarden en richtlijnen. Het informatiebeleid bevat een compleet beeld ten aanzien van de kosten en baten en bevat ook een overall-planning. Ook een informatiearchitectuur is een resultaat van dit proces.

Er is overleg tussen functioneel beheerder(s) (het uitvoerende niveau), de systeemeigenaar (het sturende niveau) en de informatiemanager (het richtinggevend niveau) over de te verwachten ontwikkelingen in de organisatie en de producten of diensten, zodat (meer-)jarenplannen voor de portfolio van systemen en onderliggende applicaties kunnen worden gemaakt en bijgesteld. Het zal duidelijk zijn, dat bij het opstellen van van de informatiestrategie overleg met de IT-serviceverleners (IT-servicemangement en Applicatiemanagement) noodzakelijk is. De behoeften van de gebruikersorganisatie zijn primair, maar de IT-serviceverleners zijn bij de realisatie betrokken.

Bron: Samenvatting BiSL (incl. mindmap) en De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers

Laatst aangepast op maandag, 23 oktober 2017 18:51  
Sleutelen aan de informatievoorziening volgens Ruigrok & Bosschers
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

wijzigingenbeheer wijzigingsproces functioneel beheer bim

Volgens Kees Ruigrok en Ernst Bosschers speelt business informatiemanagement een sleutelrol bij het voorbereiden, doorvoeren en verifiëren van wijzigingsvoorstellen. Business informatiemanagement bepaalt samen met de gebruikers de eisen, behoeften (requirements) en de prioriteiten en stelt het budget voor de wijzigingen ter beschikking. De systeemeigenaar beoordeelt samen met de functioneel beheerder de business case op basis van de wijzigings- én onderhoudskosten, baten, neveneffecten en risico's. Hierdoor kan de systeemeigenaar een verantwoorde beslissing nemen over de haalbaarheid van het wijzigingsvoorstel.

Er kunnen allerlei redenen zijn om de bestaande infomratievoorziening te wijzigingen. (Zelfs) vanuit de richtinggevende processen (lees: informatiemanagement) kan er een aanleiding ontstaan voor functionele wijzigingen. Wanneer er om strategische redenen nieuwe functionaliteit wordt voorgesteld, wordt dit via het proces Behoeftemanagement (op sturend niveau) geaccordeerd waarna het wijzigingsproces in gang wordt gezet.

Om wijzigingen van de informatievoorziening goed te laten verlopen is een wijzigingsprocedure nodig: "Door een gestandaardiseerde afhandeling gaat dat over het algemeen sneller, is de kwaliteit van de afhandeling controleerbaar en gebeurt dat efficiënter: het behandelen van wijzigingsvoorstellen is beheersbaar."

Allereerst zal een wijzigingsvoorstel in functionele termen moeten worden beschreven: wat wil de gebruikersorganisatie bereiken. Bovenstaand schema geeft weer via welke procedure een wijzigingsvoorstel wordt afgehandeld.

"De eerste beoordeling en filtering van wijzigingsvoorstellen gebeurt meestal door business informatiemanagement. Een wijzigingsvoorstel wordt bijvoorbeeld als niet-zinvol beschouwd, als deze al eens is afgewezen en de reden daarvoor nog steeds actueel is. Maar ook als bij business informatiemanagement bekend is dat in een toekomstige release het voorstel al wordt ingewilligd of al worden achterhaald. De functioneel beheerder moet dus een overzicht hebben van alle wijzigingsvoorstellen. Zowel van de actuele voorstellen als van die uit het verleden. Business informatiemanagement moet de wijzigingsvoorstellen dus beheren, ook de voorstellen die zijn afgewezen. Een gegevensbestand met alle wijzigingsvoorstellen en hun actuele status is daarbij essentieel."

De functionele beheerder overlegt met de systeemeigenaar over de ingediende wijzigingsvoorstellen. Voor elk wijzigingsvoorstel moet er een eigenaar (sponsor) zijn die de business-verantwoordelijkheid draagt. "Tijdens dit overleg zal een business case op hoofdlijnen vastgesteld worden. Een business case op hoofdlijnen moet voldoende duidelijkheid geven over kosten en baten (financieel en niet-financieel) om te beslissen of het wijzigingsvoorstel realistisch is en/of een nader onderzoek zal worden uitgevoerd.

"Voor een realistisch wijzigingsvoorstel wordt een impactanalyse uitgevoerd. Dit betekent dat zowel de kosten als de baten, waarbij de systeemeigenaar verantwoordelijk is voor de inventarisatie van de baten. De IT-dienstverlener zal onderzoeken wat de impact is voor het geautomatiseerde deel van de informatievoorziening, de applicatie-impact. (...) Het uitvoeren van de impactanalyse betreft activiteiten van het proces Specificeren uit het procescluster Functionaliteitenbeheer. Applicatiemanagement voert dit onderzoek uit. Als er ook gevolgen zijn voor de infrastructuur, zal ook IT-servicemanagement hierbij worden betrokken. In veel gevallen is er sprake van een zogenoemd RfP, een Request for Proposal. Daarmee wordt de serviceverlener(s) verzocht een offerte voor de realisatie te doen.

wijzigingenbeheer applicatiebeheer functioneel beheer specificeren impactanalyse

Een wijziging zal vaak gevolgen hebben voor de gebruikersorganisatie, denk aan veranderde procedures, aan extra opleidingen enzovoort. Ook daarvoor wordt een impactanalyse uitgevoerd, de gebruikersimpact. Dit is de verantwoordelijkheid van business informatiemanagement.

Bij grote veranderingen zal business informatiemanagement die impactanalyse laten uitvoeren door een procesanalist of een informatieanalist, eventueel geassisteerd door een AO-adviseur. Dan worden vaak ook informatiemanagers en architecten bij het project betrokken, want een belangrijk aandachtspunt is het onderzoek naar de gevolgen van de wijziging elders in de keten van applicaties of voor andere bedrijfsprocessen.

De gebruikersimpact betreft veel aspecten: het moet COPAFEITHJ-breed worden uitgevoerd. Dit acroniem bestaat uit de beginletters van de onderwerpen waarvan de impact onderzocht moet worden: Commercie, Organisatie, Personeel, Administratie, Financiën, Ecologie/ergonomie, Informatie, Technologie, Huisvesting en Juridisch."

(...)

"Als de gebruikersimpact en de applicatie-impact bekend zijn, zal de business case op hoofdlijnen worden herzien en zal het mogelijk zijn een aangescherpte business case, de uitgewerkte business case, te maken. Deze is dan de basis voor de definitieve beslissing over het wijzigingsvoorstel door de systeemeigenaar."

"Is het wijzigingsvoorstel haalbaar, dan zal het worden voorgedragen aan het releaseoverleg voor invoering. Er wordt vanaf dat moment niet langer per wijzigingsvoorstel gekeken, maar naar alle wijzigingsvoorstellen van een toekomstige release. In veel organisaties is er sprake van een Change Advisory Board (CAB) conform ITIL. Het belang van de gebruikersorganisatie staat bij de beslissingen steeds voorop.

Welke personen aan het releaseoverleg deelnemen, zal per organisatie anders kunnen zijn, maar in ieder geval komen business informatiemanagement, applicatiemanagement en IT-servicemanagement hier samen. Wanneer de rol en samenstelling van het overleg goed beschreven zijn en bij iedereen bekend, is het doorvoeren van wijzigingen beheersbaar. Het releaseoverleg zal vanuit de sturende processen van BiSL een mandaat hebben gekregen over planningen, budgetten en behoeften. Door de IT-serviceverlener wordt een releasemanager verantwoordelijk gesteld voor de coördinatie van de realisatie."

 

betrokkenheid funtioneel beheerder wijzigingsbeheer functioneel beheer

Gedurende zijn bestaan doorloopt een informatiesysteem een aantal stadia. De meeste informatiesystemen doorlopen de stadia meerdere keren voordat ze buiten gebruik worden gesteld. Bovenstaande figuur geeft de betrokkenheid aan van de functioneel beheerder bij de verschillende fasen van de levenscyclus. In de oriëntatiefase is de centrale vraag: 'Waarom wil de gebruikersorganisatie deze verandering en hoe kan ze dit bereiken? "In dit stadium - ook wel definitiestudie of vooronderzoek genoemd - gaat het om twee zaken. Ten eerste worden de behoeften (problemen en kansen) van de organisatie, of een deel daarvan, in kaart gebracht. Ten tweede worden mogelijke oplossingsrichtingen onderzocht en deze worden beoordeeld op haalbaarheid met betrekking tot de business case en tot de gebruikers- en applicatie-impact. Dat onder meer een analyse van de bedrijfsprocessen essentieel is, zal duidelijk zijn.

(...)

Bij de verandering van de informatievoorziening wordt door ASL het woord impactanalyse gebruikt voor de applicatie-impact. De activiteiten van het vooronderzoek maken deel uit van de BiSL-processen Specificeren en Vormgeven niet geautomatiseerde Informatievoorziening.

(...)

De betrokkenheid van de functioneel beheerder is onontbeerlijk tijdens het oriëntatiestadium. Dit geldt ook tijdens het realisatiestadium, onafhankelijk voor welke oplossingsrichting gekozen is. Immers daar waar het gaat om de gebruikersbehoeften en -wensen kan men de functioneel beheerder niet uitsluiten. De functioneel beheerder spreekt namens de systeemeigenaar en de toekomstige gebruikers met applicatiemanagement (de informatieanalisten respectievelijk de functioneel ontwerpers) en brengt de wensen in. ... De functioneel beheerders zijn nauw betrokken bij de stadia Acceptatietest, Implementatie en Gebruik & Evaluatie. Immers, zij bemiddelen tussen (toekomstige) gebruikers en leverancier over de functionaliteit en kwaliteit van de applicatie en de bijbehorende diensten. Het is mede de verantwoordelijkheid van de functioneel beheerder om het resultaat van de acceptatietest te beoordelen en te adviseren aan de systeemeigenaar of tot ingebruikneming kan worden overgegaan.

Ten slotte wordt de applicatie - als onderdeel van de gewijzigde informatievoorziening - in beheer genomen, waarbij de functioneel beheerder verantwoordelijkheid draagt voor een optimale beschikbaarheid van de functionaliteit van de informatievoorziening."

 

Specificeren

"Het sturende proces Behoeftemanagement zorgt ervoor, dat er voor de informatiebehoeften van de bedrijfsprocessen jaarplannen zijn. Die plannen bevatten nieuwe behoeften, of veranderingen in de bestaande informatievoorziening en applicaties. Die behoeften aan veranderingen zullen leiden tot wijzigingsvoorstellen. Binnen het proces Wijzigingenbeheer worden de wijzigingsvoorstellen gekozen die ingevoerd gaan worden. Behoeftemanagement geeft voor die keuzes de kaders en prioriteiten.

Voor de systeemeigenaar een definitieve beslissing kan nemen over het al dan niet realiseren van een wijzigingsvoorstel moet er een business case op hoofdlijnen zijn. Daarvoor krijgt hij een globaal inzicht in de consequenties (impact) en haalbaarheid van een wijzigingsvoorstel. Voor het bepalen van een business case op hoofdlijnen is een onderzoek nodig. Alle activiteiten van zo'n onderzoek behoren tot het vooronderzoek of de definitiestudie; dat komt overeen met het stadium Oriëntatie. Het proces Specificeren hoort bij dat stadium en dient ervoor om de behoeften te concretiseren, de gewenste doelen duidelijk vast te leggen, de mogelijke oplossingsrichtingen te onderzoeken en de haalbaarheid voor de gebruikersorganisatie te valideren (behoefte, oplossing, validatie).

(...)

De meeste wijzigingsvoorstellen maken een ontwikkeling door, want aanvankelijk zijn ze vaak nog niet duidelijk genoeg geformuleerd. De behoeften (aanleiding, doel en randvoorwaarden) moeten nauwkeurig worden gespecificeerd. Het formuleren van de behoeften moet in functionele termen gebeuren: wat wil de gebruikersorganisatie bereiken? Dat is het eerste doel van het proces Specificeren. Maar er zijn ook randvoorwaarden.

(...)

Tijdens Specificeren wordt het wijzigingsvoorstel nader uitgewerkt. De functioneel beheerder begeleidt de gebruikers bij het nauwkeurig formuleren van de behoeften. Business informatiemanagement (meestal de systeemeigenaar, of een door hem gemandateerde functioneel beheerder) geeft de opdracht aan applicatiemanagement en vraagt aan hen te onderzoeken hoe de eisen in de applicatie kunnen worden gerealiseerd; daarvoor zijn duidelijk vastgelegde behoeften nodig: requirements.

(...)

Het onderscheid tussen gebruikersimpact en applicatie-impact is van belang omdat er bij een oplossing meestal een geautomatiseerd deel en altijd een niet-geautomatiseerd deel is. De applicatie-impact is primair een taak van applicatiemanagement, soms samen met IT-servicemanagement. ... Parallel aan de applicatie-impact wordt de gebruikersimpact uitgevoerd en worden de gevolgen voor de gebruikersorganisatie in kaart gebracht. Daarvoor dient het proces Vormgeven niet-geautomatiseerde informatievoorziening.

Door beide impactanalyses ontstaat duidelijkheid over de vraag of een oplossing realistisch is. ... BiSL gebruikt het begrip niet-geautomatiseerde informatievoorziening voor de gevolgen binnen de gebruikersorganisatie. Het is de taak van de business informatiemanagers om die zijde van de oplossingsrichting te (laten) onderzoeken."

 

Requirements

Ruigrok en Bosschers onderscheiden twee soorten requirements: functionele requirements en niet-functionele requirement. "Functionele requirements betreffen de gewenste functionaliteit: wat moet de applicatie kunnen doen voor de gebruikers De applicatie bezit de vastgelegde en vanzelfsprekende (!) functies. Vermeden moet worden dat de gebruikersorganisatie de eisen formuleert in de vorm van (technische) oplossingen. Niet-functionele requirements zijn kwaliteitseisen, de eisen die gesteld worden aan het gebruik, zoals verwerkingssnelheid, frequentie van gebruik, vormgeving van de user interface, enzovoort.

(...)

Bij het formuleren van requirements is het belangrijk het volgende onderscheid te maken: (i) business requirements (beschrijven de behoeften geformuleerd vanuit de businessdoelen), en systeemrequirements (beschrijven wat van een applicatie wordt verwacht).

(...)

Goede business requirements identificeren behoeften van de organisatie en moeten afleidbaar zijn uit de business strategie. De businessstrategie is de manier waarop de organisatie haar doelen wil bereiken. Door het proces Behoeftemanagement ligt er een jaarplan voor de informatievoorziening."

 

Releasematig werken

De frequentie waarmee bedrijfsprocessen moeten worden aangepast aan veranderingen in de omgeving is steeds hoger geworden. Vandaar ook dat de ondersteunende informatievoorziening bijna continu aan verandering onderheving is. (...) Het is belangrijk, dat er een bepaalde rust is in de werkomgeving. Als de stroom van wijzigingen niet wordt beheerd en gereguleerd, worden de gebruikers en beheerders continue met veranderende applicaties en werkinstructies geconfronteerd. Daarom werken de meeste organisaties releasematig.

Een release is een nieuwe of gewijzigde applicaties en/of IT-infrastructuur met bijbehorende documentatie en werkinstructies, die op een beheerste manier als een eenheid wordt ingevoerd in de gebruikersomgeving. Releasematig werken houdt in dat met een vaste frequentie wijzigingen, aanvullingen en verbeteringen worden doorgevoerd in de informatievoorziening. De systeemeigenaar spreekt vooraf een releasekalender af met applicatiemanagement en IT-servicemanagement. Dit betekent voor zowel business informatiemanagement (met name de functioneel beheerder) als voor de gebruikers ene periode van stabiliteit in de informatievoorziening tussen de releasedata.

 

Bron: De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers

 

Laatst aangepast op maandag, 01 januari 2018 12:57  
Informatieobjecten volgens Frits Derksen
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

gegevens informatieobject archiefstuk

gegevens informatieobject archiefstuk


Informatieobjecten

Het klassieke begrip document of archiefstuk wordt geassocieerd met de papieren wereld en verwijst naar een specifieke categorie informatieobjecten terwijl er in toenemende mate sprake is van informatieobjecten die niet aan de (traditionele) kenmerken van het begrip document voldoen. Van papieren informatieobjecten geldt dat ze bestaan, dat ze tastbaar en distribueerbaar zijn. In de digitale wereld heeft het begrip document een andere betekenis gekregen. Tekens afgebeeld (in een weblay-out) op een beeldscherm worden ‘digitaal document’ genoemd.

Als je met een pc of een tablet werkt kunnen de gegevens rechtstreeks vanaf het scherm worden gelezen. Als het van het scherm verdwijnt, is het niet (meer) tastbaar. Het ‘digitale document’ leidt derhalve een tijdelijk bestaan. Het digitale document geeft meestal weer hoe het er uit zou zien als het op papier wordt afgedrukt. De termen document en archiefstuk worden overigens niet door iedereen op dezelfde manier gedefinieerd. In het rapport Record Management Terminologie vinden we zestien verschillende definities van het woord document en niet minder dan vierentwintig van het woord ‘archiefbescheiden’.

Definities zijn ook niet altijd eenduidig zoals blijkt uit de definitie die NEN-ISO 15489-1 hanteert: ‘een document is vastgelegde informatie die of een vastgelegd object dat als een eenheid kan worden behandeld.’ In het Engels: ‘recorded information or object which can be treated as a unit.’ Object wordt niet nader gedefinieerd. Is een object geen informatie? Jeurgens et al beschouwen overigens op grond van deze definitie databanken wel ‘als document in de zin van de Archiefwet’.

De definitie van document is volgens de Archiefterminologie ‘het geheel van samenhangende gegevens vastgelegd op een of meer gegevensdragers. Gegevensdrager kan hier gebruikt worden in de vorm van papier of een beeldscherm. In een papieren document zijn inhoud en vorm geïntegreerd. In een digitaal document is dat niet zo. MacKenzie Owen  stelde in 1999 al vast dat in de digitale wereld de koppeling tussen inhoud en vorm verbroken is: ‘Gebruikers kunnen met behulp van technische middelen hun eigen vormgeving creëren.’

In een digitaal document zijn inhoud, structuur en verschijningsvorm niet alleen logisch maar in beginsel ook fysiek gescheiden. Ik vermijd in dit onderzoek het woord ‘document’; ik kies voor het abstracte begrip ‘informatieobject’. Archiefstukken zijn een deelverzameling van informatieobjecten. Zij verschillen van informatieobjecten op een punt; zij kunnen als archivistisch bewijs dienen.

...

Hoogstens maak ik onderscheid tussen een papieren informatieobject en een digitaal informatieobject om het verschil aan te geven tussen ‘iets op p apier’ en ‘iets op een beeldscherm’. Een papieren informatieobject kan ook een afdruk of ‘hardcopy’ zijn van ‘iets op een beeldscherm’. Een papieren informatieobject is een geheel van informatie (met uitzondering van bewegend beeld en geluid) dat is geschreven of afgedrukt op papier. En een digitaal informatieobject is de weergave van een informatieobject op het scherm van een pc of tablet.

Archiefstuk

In de archivistiek wordt onderscheid gemaakt tussen het informatieobject en het archiefstuk. Ik heb eerder aangegeven de voorkeur te geven aan de term informatieobject boven document. Een informatieobject is gedefinieerd als ‘een geheel van gegevens met een eigen identiteit.’ Een archiefstuk is ‘een informatieobject, ongeacht zijn vorm, met de bijbehorende metadata ontvangen of opgemaakt door een natuurlijke en/of rechtspersoon bij de uitvoering van taken [...]’ Ofwel informatie die gebonden is aan een werkproces . De wettelijke term is archiefbescheiden. Een archiefstuk is een informatieobject, maar niet ieder informatieobject is een archiefstuk. Een informatieobject wordt een archiefstuk als het wordt gecreëerd of ont-
vangen bij de uivoering van werkprocessen en als het als bewijs kan dienen voor deze processen. De overgang van informatieobject naar archiefstuk valt samen met de overgang van twee gebruiksniveaus van het Records Continuümmodel. In de eerste dimensie van het Records Continuüm vindt documentatie van de handeling plaats en ontstaat het informatieobject. In de tweede dimensie is een informatieobject een archief stuk dat als bewijs dient.

Een interessant vraagstuk is wat de criteria zijn voor het archiveren van informatieobjecten. Anders gezegd: wat maakt een informatieobject een ‘archiefstuk’? De theorie zegt: archiefbescheiden zijn die bescheiden (informatieobjecten) d
ie ‘naar hun aard’ bestemd zijn te berusten onder de organisatie die ze heeft opgemaakt of die ze heeft ontvangen. De vraag is op basis van welke criteria zijn informatieobjecten ‘naar hun aard’ bestemd zijn te berusten. Anders gezegd, hoe maken we onderscheid tussen informatieobjecten (alles waarvan de organisatie vindt dat het niet hoeft te worden vastgelegd) en archiefstukken (informatieobjecten die vanuit een goed te omschrijven bedrijfsvoerings-, verantwoordings- of bewijsbelang wel vastgelegd en beheerd moeten worden).

Bron: De organisatie van duurzaam digitaal bewijs, Frits Derksen

Laatst aangepast op maandag, 01 januari 2018 12:55  
Meer artikelen...


JPAGE_CURRENT_OF_TOTAL

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 530 gasten online
Artikelen

versneld verspillen stephen parry lean waste

Banner

citaat

Do not say a little in many words but a great deal in a few.

Pythagoras


Lean boekentips

Toyota Kata Culture
Building Organizational Capability and Mindset through Kata Coaching
Mike Rother & Gerd Aulinger

Bij Bol.com | Managementboek

Bewaren

Banner