• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Informatiemanagement
Informatiemanagement
PIOFACH-functies
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

PIOFACH-model ondersteunende functies

PIOFACH is een acroniem voor alle ondersteunende functies van een organisatie (de bedrijfsvoering):

  1. Personeel.

  2. Informatievoorziening.

  3. Organisatie.

  4. Financiën.

  5. Algemene zaken (facilitaire diensten).

  6. Communicatie.

  7. Huisvesting.

Varianten zijn PIOFA, PIOFAH, PICOFA, OPAFIT en de meest uitgebreide variant is COPAFIJTH. Bij organisaties die de acroniemen gebruiken, bestaan nog wel de nodige smaakverschillen met betrekking tot de exacte benaming van de letters in het acroniem. Zo wordt voor de I wisselend gebruikt voor 'Inkoop', 'Informatievoorziening' en/of 'ICT' gebruikt, terwijl de A ook wel wordt gebruikt voor 'Automatisering'. Over de letters P, O, F, C en H is men in het algemeen wel unaniem.

De term 'bedrijfsvoering' kan in de praktijk verwarring opleveren. Het wordt hier gebruikt als synoniem voor de 'ondersteunende functies'. De verwarring ontstaat omdat de term bedrijfsvoering gebruikt kan worden in twee betekenissen: (a) het gehele takenpakket van een organisatie, zowel primair als ondersteunend; (b) een beperkt takenpakket bestaande uit alleen de ondersteunende taken.

Ondersteunende functies zijn gericht op het ter beschikking stellen van mensen, gebouwen en middelen aan de organisatie zelf ten behoeve van het zo goed mogelijk uitvoeren van de primaire taken.

Bron: http://www.wikixl.nl/wiki/ictu/index.php/BFM:_Ondersteunende_functies

Laatst aangepast op vrijdag, 17 november 2017 22:08  
Quick scan volwassenheid functioneel beheer
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

quick scan volwassenheid functioneel beheer

Tijdens het seminar Van uitvoeren naar uitblinken: Functioneel Beheer 2.0 (georganiseerd door Sogeti) werd een quick scan geïntroduceerd om de volwassenheid te meten van functioneel beheer. Hierbij werden zes aspecten gescoord op basis van drie 'stellingen'. Per stelling kun je aangeven of je - als je naar je eigen organisatie kijkt - het hier mee eens of oneens bent. Elk 'Eens' levert twee punten op, zodat per aspect maximaal zes punten kunt scoren. De eindscore geeft een goede indruk waar je als organisatie staat. De stellinigen geven in ieder geval een goede indruk van wát je überhaupt moet regelen voor het inrichten en verder professionaliseren van functioneel beheer.

1. Organisatie
1.1 Functioneel beheer wordt onderkend als aparte functie in uw organisatie.
1.2 Functioneel beheer is organisatorisch gepositioneerd bij de business.
1.3 Er zijn hoofdgebruikers (key users) die het centrale aanspreekpunt zijn voor FB.

2. Medewerkers
2.1 Er is in de hele organisatie duidelijkheid over de verantwoordelijkheden van functioneel beheer.
2.2 Voor functioneel beheer zijn competenties gedefinieerd en wordt hierop beoordeeld.
2.3 De functioneel beheerder wordt gestimuleerd zijn competenties via gerichte cursussen te verbeteren.

3. Samenwerking
3.1 De functioneel beheer-procedures en -taken zijn afgestemd met eindgebruikers en IT (leveranciers).
3.2 Functioneel beheer evalueert periodiek de gebruikerstevredenheid van de informatiesystemen.
3.3 Functioneel beheer evalueert periodiek de kwaliteit van de door IT geleverde diensten.

4. Kennis
4.1 Functionele beheer heeft diepgaande kennis van de informatiesystemen waarvoor zij verantwoordelijk is.
4.2 Functioneel beheer heeft diepgaande kennis van de bedrijfsprocessen die deze systemen ondersteunen.
4.3 Functioneel beheer is op de hoogte van de kwaliteitseisen die aan deze informatiesystemen worden gesteld.

5. Processen en procedures
5.1 Functioneel beheer heeft procedures voor de afhandeling van gebruikersvragen en volgt deze ook.
5.2 Functioneel beheer heeft procedures voor het opstellen van wijzigingsvoorstellen en volgt deze ook.
5.3 Functioneel beheer wordt actief betrokken bij een project; vanaf de start tot en met de implementatie.

6. Sturing en afspraken
6.1 Functioneel beheer weet hoe het besluitvormingsproces ten aanzien van wijzigingen en projecten loopt.
6.2 Functioneel beheer kent de projectplanning en bepaalt op basis daarvan de benodigde FB-capaciteit.
6.3 Functioneel beheer bewaakt of de contractafspraken met IT leveranciers aansluiten bij de gebruikerseisen.

Bron: Sogeti

Laatst aangepast op zaterdag, 14 juli 2018 15:19  
Bluff Your Way Into Bedrijfsfuncties
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

informatieobjecten informatiedomeinen bedrijfsactiviteiten

Het referentiedomeinenmodel ziekenhuizen is een generiek model voor informatiedomeinen met bedrijfsactiviteiten en informatieobjecten in ziekenhuizen. Binnen het model wordt ingegaan op de relatie tussen bedrijfsactiviteiten, informatieobjecten en informatiedomeinen. Hieronder een definitie van de belangrijkste begrippen uit het referentiemodel:

  1. Bedrijfsactiviteit: handeling die kan worden toegekend aan een specifieke persoon of rol. Een voorbeeld van een bedrijfsactiviteit is het uitvoeren van een preoperatieve screening.

  2. Bedrijfsproces: reeks van activiteiten, met een duidelijk startpunt en eindpunt, en die leidt tot een duidelijk (en voor de klant nuttig) resultaat. Een voorbeeld van een bedrijfsproces is het operatief proces. In het operatief proces worden diverse bedrijfsactiviteiten (na elkaar) uitgevoerd, zoals het plannen van de operatie, het voorbereiden van de operatie, het uitvoeren van de preoperatieve screening, het uitvoeren van de operatie zelf en het opstellen van het operatieverslag.

  3. Bedrijfsfunctie: set van activiteiten die onderling samenhang vertonen in de vereiste kennis, vaardigheden of middelen. Bedrijfsfuncties hebben vaak een meer permanent karakter dan bedrijfsprocessen. Een voorbeeld van een bedrijfsfunctie is verzorging & verpleging. Een bedrijfsfunctie levert een organisatie functionaliteit die bijdraagt aan een of meerdere bedrijfsprocessen.

  4. Informatieobject: eenheid van informatie die relevant is vanuit een bedrijfsperspectief. Een informatieobject heeft betekenis voor de doelstelling en voor het functioneren van een organisatie. Een voorbeeld van een informatieobject is een operatieverslag. Informatieobjecten zijn onafhankelijk van fysieke inrichting of implementatie in een organisatie. Ze kunnen worden vertaald naar een fysiek model en naar fysieke verschijningsvormen van informatie (bijvoorbeeld tabellen in een database, informatie in een datawarehouse-omgeving, informatie in documenten). Dat betekent dat onderscheid moet worden gemaakt tussen de inhoud van een begrip (als concept, iets wat betekenis heeft in de werkelijkheid) en de manifestatie/vorm waarin het wordt opgeslagen of gepresenteerd (papier, digitaal, etiket, ponsplaatje). De manifestatie/vorm blijft buiten beschouwing wanneer gesproken wordt over informatieobjecten.

  5. Informatiedomein: verzameling van bedrijfsactiviteiten met een maximale samenhang in de informatie die door de activiteiten wordt geproduceerd en gebruikt. Een informatiedomein wordt dus gedefinieerd door de bedrijfsactiviteiten die erin worden ondersteund en door de informatieobjecten die erbinnen worden gedefinieerd. Door de bedrijfsactiviteiten en informatieobjecten te clusteren op basis van onderlinge samenhang wordt bereikt dat informatiedomeinen zoveel mogelijk op zichzelf staan, en zo weinig mogelijk informatieobjecten uit andere domeinen nodig hebben.

Voor informatie-intensieve organisaties is het vaak zo dat bedrijfsfuncties en informatiedomeinen met elkaar samenvallen. Het verdient voor de begrijpelijkheid en herkenbaarheid de voorkeur deze één op één relatie te handhaven.

bedrijfsfuncties bedrijfsactiviteiten bedrijfsprocessen afdeling

Bron: Referentiedomeinenmodel ziekenhuizen (versie 2| 21-06-2012) op www.nictiz.nl

 

Laatst aangepast op woensdag, 27 december 2017 08:25  
Het negenvlaksmodel volgens VERA
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

negenvlaksmodel vera architectuur

Het bovenstaande negenvlaksmodel kwam ik tegen bij VERA. 'VERA' staat voor Volkshuisvesting Enterprise Referentie Architectuur en heeft als doel het faciliteren van uniforme gegevensuitwisseling tussen ICT systemen en richt zich met name op het ontwikkelen van implementeerbare gegevensdefinities.

Bron: http://www.stichting-vera.nl/wat-is-vera/

Laatst aangepast op maandag, 25 december 2017 11:31  
Specificeren (BiSL) vs. functioneel ontwerp (ASL2)
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

asl2 uitvoerende processen

 

uitvoerende processen bisl specificeren

In het artikel Misvattingen, misverstanden en vragen over ASL en BiSL gaan Machteld Meijer en René Sieders in op het verschil tussen het maken van het functioneel ontwerp en het opstellen van de functionele eisen (requirements).

functioneel ontwerp functionele eisen specificaties asl bisl

In BiSL treft men het proces Specificeren aan en in ASL het proces Ontwerp. In praktijk blijkt dat over het onderscheid tussen deze twee veel verwarring bestaat, omdat een functioneel ontwerp ook wel wordt aangeduid met de term functionele specificaties. Regelmatig zie je dan ook dat het maken van een functioneel ontwerp als een taak belegd is bij de functioneel beheerders. Toch is dat niet logisch.
Indien een applicatie moet worden gebouwd of aangepast is businessinformatiemanagement verantwoordelijk voor het aangeven wat de functionele eisen zijn (vaak requirements of gebruikersspecificaties genoemd). Aangeven hoe deze worden opgenomen in de applicatie is een taak van applicatiemanagement. Dit staat in een functioneel ontwerp. Om een functioneel ontwerp aan te kunnen passen heb je dus kennis nodig van de opbouw van de applicatie. Voor de gebruikersorganisatie is het niet nodig die opbouw te kennen. Zij moeten kunnen aangeven wat ze nodig hebben en niet hoe dat wordt vormgegeven. Specificeren gaat over het probleem (de vraag) en hoort thuis bij de functioneel beheerders en ontwerpen gaat over de oplossing (het aanbod) en hoort dus bij applicatiemanagement thuis. Maken en onderhouden van een functioneel ontwerp hoort dus thuis bij applicatiemanagement. (...) Het functioneel ontwerp is een document dat met de afnemer (lees: de functioneel beheerder) wordt afgestemd en veelal ook door de afnemer wordt geaccordeerd. Het is daarmee een onderdeel van het contract. Daardoor is een duidelijke overgang van Ontwerp naar Realisatie handig.

Bron: Misvattingen, misverstanden en vragen over ASL en BiSL, Machteld Meijer & René Sieders

 

 

Laatst aangepast op woensdag, 27 december 2017 07:33  
Negenvlaksmodel volgens Joost van den Berg
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

negenvlaksmodel voor informatiemanage

In het artikel Succesvolle sourcing begint met een onderbouwd besluit, plot Joost van den Berg functioneel beheer, applicatiebeheer en technisch beheer op het negenvlaksmodel van Maes.

negenvlaksmodel informatiemanagement

De verschillende beheeractiviteiten zijn verdeeld over het technologiedomein en het informatiedomein en bevinden zich meer op het operationele (uitvoerende) niveau dan op het tactische (structuur) niveau. Applicatiebeheer en technisch beheer zijn daarbij onderdeel van het technologiedomein. Het middelste domein van de informatie en communicatie is de plek waar de behoefte van de business wordt samengebracht met en afgestemd op het aanbod en de mogelijkheden van ict. In dit middelste domein bevindt zich het functionele beheer van de voorziening.

Bron: Succesvolle sourcing begint met een onderbouwd besluit, Joost van den Berg

Laatst aangepast op maandag, 25 december 2017 11:32  
Negenvlaksmodel volgens Joep Janssen
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

negenvlaksmodel informatiemanagement


In het artikel Combinatie van Cobit en BISL biedt een sterk Information Governance framework visualiseert Joep G.M. Janssen het negenvlaksmodel van Maes op bovenstaande wijze en geeft hij als omschrijving:

negenvlaksmodel informatiemanagement

Het negenvlaksmodel is een raamwerk voor integratie, waarmee het management op een samenhangende en afgewogen wijze en op strategisch, structurerend en uitvoerend niveau een relatie kan leggen tussen informatie- en communicatieprocessen die de bedrijfsprocessen ondersteunen en de daarbij behorende technologie.

Bron: Combinatie van Cobit en BISL biedt een sterk Information Governance framework, Joep G.M. Janssen

Laatst aangepast op maandag, 25 december 2017 11:32  
De informatieladder volgens Roel Grit
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

informatieladder

Volgens Roel Grit is informatie een onderdeel van de zogenaamde informatieladder (naar Informatiemanagement, Bruins & Pinkster, 2007).

De informatieladder bestaat uit vijf 'treden':

  1. Feiten: gebeurtenissen of omstandigheden die zich in de werkelijkheid voordoen (bijv. de auto rijdt 120 kilometer per uur).

  2. Gegevens: registraties van feiten. Als feiten op papier of in de computer worden vastgelegd, spreekt men van gegevens. Als gegevens met een computer met elkaar in verband worden gebracht, spreekt men wel van data.

  3. Informatie: feiten die betekenis voor je hebben.

  4. Kennis: 'veredelde informatie', kennis ontstaat uit informatie, als die is aangevuld met vaardigheden en ervaring.

  5. Competentie: combinatie van kennis, vaardigheden, houding en gedrag die nodig is om in een bepaalde beroepssituatie goed te kunnen functioneren. Een competentie heeft te maken met iemand doet met zijn kennis.

Bron: Informatiemanagement, Roel Grit

Laatst aangepast op woensdag, 27 december 2017 07:30  
Negenvlaksmodel volgens CORA
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

negenvlaksmodel volgens CORA

Bovenstaande weergave van het Negenvlaksmodel van Maes is afkomstig uit de Woningcorporatie referentie architectuur (CORA).

Bron: http://www.bitti.nl/userFiles/upload/presentaties/Introductie_cora_van_Dijk.pdf

 

Laatst aangepast op maandag, 25 december 2017 11:32  
Applicatierationalisatie volgens KING
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

applicatiesanering applicatieportfoliomanagement king

Het Kwaliteits Instituut Nederlandse Gemeenten (KING) beschrijft in de Handreiking KING: Applicatiesanering en contract management: ‘De basis op orde’ een aanpak voor het saneren van applicaties. King positioneert ‘applicatiesanering’ in een breder perspectief. Immers, ook een gesaneerd applicatielandschap moet onderhouden worden. Het gestructureerd werken en sturen met een (applicatie)portfolio is hiervoor een goed instrument.

Volgens King bied applicatiesanering een oplossing de volgende problemen:

  • Beheerskosten worden structureel lager
  • Focus op het uitzetten oude applicaties (incl. bijbehorende contracten)
  • Alignement met strategie visie van de organisatie
  • Actieve sturing op een eenvoudig en overzichtelijk applicatielandschap.
  • Managen spanning tussen korte termijn business en lange termijn IT doelstellingen
  • Veel sneller en beter aanpassingen aan de organisatie kunnen doen
  • Kosten van upgrades zijn lager
  • Hoeveelheid benodigde kennis neemt af (complexiteitsreductie)
  • Eén applicatieregistratie, inzicht in kosten, eigenaarschap, functionele (!) en technische kwaliteit

Voordat zinvol gesaneerd kan worden is het nodig om een beeld te hebben van de richting waar de organisatie heen wil groeien, vastgelegd in architectuurprincipes.

King's aanpak bestaat uit vier stappen. De eerste 2 stappen zijn gericht op het creëren van inzicht en overzicht, terwijl de derde stap bestaat uit het consolideren en harmoniseren. Vervolgens ligt de weg vrij voor de optionele vierde stap, het structureel inregelen van applicatieportfoliomanagement.

  1. Inventariseren: het resultaat van de inventarisatie is een compleet overzicht van het applicatielandschap. Het overzicht geeft aan welke de organisatie allemaal heeft (gekocht, geïnstalleerd, in gebruik, in beheer) en wat het werkelijke gebruik is van de applicaties (welke processen, welke functionaliteit, wie, waar, wanneer, hoe tevreden is de gebruiker).

  2. Analyseren: de stap van de analyse is erop gericht een globaal beeld te krijgen van de ‘levensvatbaarheid’ van de aanwezige applicaties, als hulpmiddel om verder besluitvorming te ondersteunen..

  3. Kiezen en realiseren van de sanering: op basis van de inventarisatie en de analyse kunnen keuzes worden gemaakt over de toekomst van de applicatie ('bevriezen', uitfaseren mét en zonder (gedeeltelijke) vervanging) en kan de daadwerkelijke implementatie van deze strategie in gang worden gezet.

  4. Inrichten applicatieportfoliomanagement: voor structureel applicatieportfoliomanagement, is een duidelijke set van criteria nodig waaraan applicaties moeten voldoen om binnen een applicatielandschap te (blijven) bestaan. Deze criteria zullen uiteindelijk een afgeleide zijn van bijvoorbeeld randvoorwaarden en uitgangspunten uit een ICT beleidsplan of een set van architectuurprincipes.

Ter ondersteuning van de eerste twee fasen beschrijft KING (a) een inventarisatiekader en een (b) analysekader, waarmee de inventarisatie en analyse kunnen worden uitgevoerd.

Ad (1) Inventariseren
De inventarisatie moet antwoord geven op onderstaande vragen:

  • Waar zitten witte, grijze of zwarte vlekken in procesondersteuning? Hoe erg is dit voor de organisatie?
  • Welke applicaties worden niet gebruikt worden of slechts deels;
  • Waar zitten doublures zitten in procesondersteuning met applicaties (incl. impact)?
  • Welke is al beschikbaar is en kan hergebruikt worden?

KING beschrijft een zgn. inventarisatiekader waarmee per applicatie de relevante aspecten van applicaties kunnen worden 'gescoord':

Architectuur

  • Applicatie: naam van de applicatie
  • Korte omschrijving: korte omschrijving
  • Processen: bedrijfsprocessen/functie waar applicatie een relatie mee heeft.
  • Applicaties/koppelingen: (andere) applicaties waar applicatie een relatie mee heeft. Koppeling standaard of niet?
  • Type: soort applicatie (King onderkent: business applicaties, kantoorautomatisering of tool/freeware/zelfbouw).

Applicatie

  • Leverancier: leverancier van de applicatie
  • Contract: soort contract
  • Looptijd contract: datum tot hoe lang contract loopt; of datum waarop het contract is afgesloten.
  • Opzegtermijn contact: bepalingen mbt opzegtermijn in contract
  • Contract opgezegd: ja/nee
  • Contract opgezegd: per datum
  • SLA Dienstverlening: indien applicatie behouden blijft is deze opgenomen in een SLA (pdc)

Operationeel

  • Gebruikers: afdelingen/gebruikersgroepen die applicatie gebruiken

Ad (2) Analyseren
KING beschrijft ook een hulpmiddel voor het uitvoeren van de analyse, het zgn. analysekader:

Bedrijfsfactoren

  • Operationeel belang: belang van de applicatie voor de huidige uitvoering (invloed op bedrijfsprocessen).
  • Toekomstige behoeftes: bruikbaarheid van de applicatie in de toekomst irt strategische doelstellingen.
  • Voldoet aan de huidige standaard: past de applicatie binnen de huidige ICT/bedrijfsstandaarden en architectuur.

Applicatiefactoren

  • Support: in welke kan vanuit de huidige (IT) organisatie de applicatie worden ondersteund?
  • Data: betrouwbaarheid, toekomstvastheid, veiligheid, directe/tijdige benaderbaarheid en nut voor de organisatie.
  • Overlappende functionaliteit: mate waarin de door de applicatie geleverde functionaliteit uniek is en eventuele overlap met andere applicaties.

Technische factoren

  • Integratie en afhankelijkheden: mate waarin applicatie eenvoudig integreerbaar is en/of er weinig afhankelijkheden zijn. Veel afhankelijkheden met andere systemen en/of applicaties bemoeilijken toekomstige upgrades en aanpassingen.
  • Onderhoudbaarheid en ondersteuning: heeft de applicatie veel/vaak onderhoud nodig om bugs te repareren of zijn er weinig/ nooit problemen en vergt de applicatie daarmee weinig ondersteuning van de ICT organisatie?
  • Architectuur & platform: hoe schaalbaar is de applicatie? Zijn er geen belemmeringen voor toekomstige uitbreiding, of is grootschalige aanpassing van de applicatie of onderliggende infrastructuur noodzakelijk. Is de applicatie ‘portable’ naar een ander platform?
  • Technische ‘dekking’: past de applicatie goed binnen de huidige en toekomstige ICT infrastructuur.

Leverancier factoren

  • Support: is de leverancier of distributeur/reseller in staat om nu en in de toekomst ondersteuning te bieden bij het opzetten en onderhouden van de applicatie?
  • Strategie: is de strategie van de leverancier erop gericht, en is de leverancier goed in staat, om de applicatie verder te ontwikkelen en mee te gaan met toekomstige ontwikkelingen, of is de verwachting dat de leverancier de applicatieontwikkeling tot een minimum gaat beperken? Hierbij kan ook de levensvatbaarheid van een leverancier worden meegenomen.
  • Prijs: is prijs per klant of prijs per afgenomen dienst mogelijk? Onderhoud betaald of onderhoud in contract.
  • Markt: is er een aantrekkelijk alternatief in de markt (of bij een mogelijke samenwerkingspartner!) ontstaan die qua functionaliteit een set van applicaties kan vervangen?

Ad (3) Kiezen/realiseren
Applicatiesanering in het algemeen en het daadwerkelijk uitfaseren van applicaties in het bijzonder vraagt om lef. Het is gemakkelijk om iets wat niet of nauwelijks gebruikt wordt in stand te houden: niemand heeft er toch last van? Wat halen we niet allemaal overhoop als we een onderdeel willen opruimen. Bovendien zijn mensen gehecht aan bestaande zaken. Gebruikers zullen bijvoorbeeld niet met het verzoek komen om een applicatie te vervangen of uit te faseren. Ze zijn eraan gehecht en komen hoogstens met verzoeken tot wijzigingen. De reden om tóch aan de applicaties te saneren is omdat er anders nadelinge gevolgen optreden:

• Extra ICT beheerkosten
• Spaghetti architectuur
• Overlap in functionaliteiten
• Complexiteit bij toekomstige veranderingen

Ad (4) Inrichten applicatieportfoliomanagement
Applicatiesanering wordt vaak als ad hoc project opgestart. Niets mis mee, maar in dit project kan al een belangrijke basis worden gelegd voor structureel portfoliomanagement. KING omschrijft portfoliomanagement als een methode om applicaties, ICT-projecten en infrastructuur organisatiebreed te besturen en te beheren vanuit het oogpunt van:

• Het besparen op kosten voor licenties en beheer.
• Het reduceren van de complexiteit van de portfolio (bv licenties, dubbel beheer, koppelingen etc.);
• Het reduceren van de risico’s
• Het verbeteren van de performance
• Het verbeteren van de (ondersteuning van de) kwaliteit van dienstverlening

Portfoliomanagement komt in essentie neer op het 'centraal organiseren van de samenhang'. Voor het goed kunnen uitvoeren van het proces applicatieportfoliomanagement zijn volgens KING de onderstaande variabelen van belang en moeten voor deze aspecten 'spelregels' (lees: architectuurprincipes) worden opgesteld.

Applicaties

Algemeen
• status van een applicatie
• beschrijving van de applicatie
• soort applicatie (conform indeling verdieping GEMMA informatiearchitectuur)
• eigenaar van de applicatie
• gebruikers van een applicatie
• (niet)bedrijfskritisch en eisen over beschikbaarheid

Techniek
• gebruikte ontwikkeltechniek
• ondersteunde applicatieservers, operating systemen, databases en hardware (infrastructuur)

Beheer
• mate van documentatie
• contract, looptijd, opzegtermijn
• leverancier, ouderdom en levensduur
• besteedde uren voor onderhoud en exploitatie
• aanwezigheid service level overeenkomst.

Interoperabiliteit
• ondersteunde open standaarden
• afhankelijkheden met andere informatiesystemen

Gebruik
• gebruikte ontwikkeltechniek
• de nodige koppelingen
• het aanwezig zijn van een licentie en onderhoudscontract.

Kosten van de applicatie en de kosten voor verandering
• huidige kosten per onderdeel per jaar
• kosten voor vervanging
• (niet) gebruikte functionaliteit
• met het gebruik van de applicatie gepaard gaande risico’s op het terrein van continuïteit, veiligheid en compliance.

Levenscyclus van de applicatie
• behouden, verbeteren, migreren of vervangen

Bron: Handreiking KING: Applicatiesanering en contract management: ‘De basis op orde’

Laatst aangepast op woensdag, 27 december 2017 07:33  
Meer artikelen...


JPAGE_CURRENT_OF_TOTAL

Every day you ask yourself, 'How did our values influence decisions I made today?' If they didn't, they are pretty much bullshit.

Peter Senge

Banner
Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 148 gasten online
Artikelen

standaard standards taiichi ohno

Banner

start with why simon sinek

Start with Why
How Great Leaders Inspire Everyone to Take Action
Simon Sinek

Bij Managementboek

Lean boekentips

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

Bij Bol.com | Managementboek

Bewaren

Banner