• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
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  
Less is more volgens Hans Hofmann
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

citaat

The ability to simplify means to eliminate the unnecessary so that the necessary may speak.

Hans Hofmann

Laatst aangepast op maandag, 02 april 2012 19:40  
Geluk volgens Dale Carnegie
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

citaat

Successs is getting what you want. Happiness is wanting what you get.

Dale Carnegie

Laatst aangepast op maandag, 02 april 2012 19:38  
Geluk volgens Loesje
Gepubliceerd in Losse flodders
E-mail Afdrukken

Geluk volgens Loesje

Laatst aangepast op zaterdag, 03 november 2012 14:50  
Faciliterend leraarschap volgens Einstein
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

citaat

I never teach my pupils. I only attempt to provide the conditions in which they can learn.

Albert Einstein

Laatst aangepast op maandag, 02 april 2012 19:36  
Kantoren bestaan niet meer (boekentip)
Gepubliceerd in Boeken over management
E-mail Afdrukken

kantoren bestaan niet meer erik veldhoen

Kantoren bestaan niet meer / Versie 2.0
Een vitale organisatie in een digitale werkomgeving
Erik Veldhoen

Bij Bol.com

Laatst aangepast op woensdag, 11 april 2012 19:36  
Schaduwen over de woestijn (boekentip)
Gepubliceerd in Boeken over management
E-mail Afdrukken

schaduwen over de woestijn jaap jan brouwer

Schaduwen over de woestijn
Strategie, management en organisatie van het Duitse en Britse leger van Versailles tot El Alamein
Jaap Jan Brouwer

Bij Bol.com of Managementboek

Laatst aangepast op woensdag, 11 april 2012 19:27  
Leerzame ervaringen
Gepubliceerd in Citaten: constructief falen
E-mail Afdrukken

citaat

There is only one thing more painful than learning from experience and that is not learning from experience.

Archibald McLeish

Laatst aangepast op maandag, 02 april 2012 19:34  
Beroepszeer (boekentip)
Gepubliceerd in Boeken over management
E-mail Afdrukken

beroepszeer waarom nederland niet goed werkt brink jansen pessers

Beroepszeer
Waarom Nederland niet goed werkt
Gabriël van den Brink, Thijs Jansen, Dorien Pessers

Bij Bol.com of Managementboek

Laatst aangepast op woensdag, 11 april 2012 19:23  
5 frustraties van teamwork volgens Patrick Lencioni
Gepubliceerd in Management
E-mail Afdrukken

lencioni teamwork vijf frustraties piramide vertrouwen

In zijn boek De vijf frustraties van teamwork beschrijft Patrick Lencioni vijf frustraties, voor de hand liggende maar gevaarlijke valkuilen, voor teamwork:

  1. Afwezigheid van vertrouwen tussen de teamleden onderling: teamleden die niet bereid zijn zich kwetsbaar op te stellen en in alle openheid hun fouten en zwakheden toe durven te geven, maken het onmogelijk een basis van vertrouwen te leggen.

  2. Angst voor conflicten: teams waarin geen vertrouwen aanwezig is, zijn niet in staat zich over te geven aan ongeremde en hartstochtelijke debatten over ideeën. In plaats daarvan beperken ze zich tot versluierde discussies en commentaren.

  3. Gebrek aan betrokkenheid: "Wanneer teamleden in de loop van hartstochtelijke en open debatten geen lucht hebben kunnen geven aan hun meningen, engageren ze zich zelden of nooit en stellen zij zich ook niet achter besluiten op, hoewel ze misschien tijdens vergaderingen instemming veinzen.".

  4. Teamleden mijden (het nemen van) verantwoordelijheid: als een werknemer een overeengekomen plan niet van harte steunt, leidt dat ertoe dat ze collega's die met hun gedragingen het teambelang lijken te schaden slechts aarzelend ter verantwoording roepen.

  5. Te weinig aandacht voor de resultaten: wanneer teamleden, als men binnen het team elkaar niet om verantwoording vraagt, eigen belangen (eigen ego, carrièreplanning of erkenning) of de belangen van hun afdeling, voorrang geven boven de doelstellingen van het team.

Volgens gaat Lencioni is de zwakste schakel bepalend voor de sterkte van het team: "Net als bij een ketting met een kapotte schakel gaat het teamwork achteruit als ook maar één enkele frustratie zich kan ontwikkelen."

Lencioni stelt dat zijn model ook positief gesteld kan worden door te stellen dat (h)échte teams voldoen aan de volgende vijf criteria:

  1. Teamleden vertrouwen elkaar: "Vertrouwen vormt de basis van een goed functioneren, hecht team. Zonder vertrouwen is teamwork vrijwel onmogelijk. (...) In de context van de opbouw van een team staat vertrouwen voor de zekerheid van de teamleden dat de intenties van hun collega's goed zijn en dat er geen reden is om beschermend of bezorgd over de groep te zijn. In wezen moeten de teamleden zich op hun gemak voelen als ze zich kwetsbaar tegenover elkaar opstellen. (...) [A]ls leden van een team zich bij elkaar echt op hun gemak voelen, kunnen ze reageren zonder op hun hoede te hoeven zijn. Dat heeft weer tot gevolg dat ze hun energie en aandacht volledig kunnen richten op de zaak waar ze mee bezig zijn; de noodzaak strategisch of politiek met elkaar om te gaan ontbreekt."

  2. Teamleden gaan openlijk de strijd aan over ideeën: "Alle belangrijke, duurzame relaties hebben productieve conflicten nodig om te kunnen groeien. Dat geldt zowel voor het huwelijk als voor ouderschap en vriendschap. Het geldt zeker voor het bedrijfsleven. Helaas zijn conflicten vaak taboe. Zeker op het werk is dat zo. Hoe hoger je in de hiërarchie komt, hoe vaker je ziet dat mensen onevenredig veel tijd en energie besteden aan pogingen juist die hartstochtelijke discussies te vermijden die essentieel zijn voor goed functionerende teams. (...) Teams die productieve conflicten aangaan, weten echter dat het enige doel daarvan is op de kortst mogelijke termijn de best mogelijke oplossing te bereiken. Ze bespreken problemen en lossen die ook sneller en vollediger op dan andere groepen. Uit verhitte debatten komen ze te voorschijn zonder dat er emotionele resten blijven hangen of schade is aangericht. Deze teams kenmerken zich juist door hun gretigheid en door de bereidheid om het volgende belangrijke probleem aan te pakken."

  3. Teamleden steunen besluiten en actieplannen: "Binnen de context van teams is betrokkenheid een functie van twee zaken: duidelijkheid en steun. Goed functionerende teams nemen duidelijke beslissingen, en ze nemen ze tijdig. Ze werken met complete instemming van alle teamleden, zelfs van diegenen die tegen het besluit hebben gestemd. Na het einde van de vergadering heeft geen enkel teamlid twijfel over de vraag of de gemaakte keuzes moeten worden ondersteund. De twee belangrijkste oorzaken van een gebrek aan betrokkenheid zijn het verlangen naar consensus en de behoefte aan zekerheid. (...) [S]lecht functionerende teams ... proberen zich in te dekken en stellen belangrijke beslissingen uit tot ze over genoeg gegevens beschikken. Ze willen er zeker van zijn het goede besluit te nemen. Hoe verstandig dit misschien ook lijkt, het is gevaarlijk. Het leidt tot verlamming en een gebrek aan vertrouwen binnen het team.".

  4. Teamleden spreken elkaar aan op het realiseren van overeengekomen activiteiten: "In verband met teamwork verwijst [verantwoordelijkheid] specifiek naar de bereidheid van teamleden om collega's aan te spreken op prestaties of gedragingen die het team kunnen schaden. In wezen betreft het hier de onwil van teamleden om het sociale ongemak te verdragen dat samengaat met het aanspreken van een collega op zijn of haar gedrag. Ook speelt de meer algemene neiging een rol om lastige gesprekken te vermijden. Leden van goed functionerende teams overwinnen deze natuurlijke neiging en zijn niet bang risico's te nemen. (...) Leden van goed functionerende teams verbeteren de onderlinge relaties door elkaar ter verantwoording te roepen. Op die manier laten ze zien dat ze elkaar respecteren en hoge verwachtingen koesteren omtrent elkaars prestaties.".

  5. Teamleden concentreren zich op het bereiken van collectieve resultaten: "De allerbelangrijkste frustratie van een team is de neiging van de leden zich meer te richten op iets anders dan de teamdoelstellingen. Een niet aflatende concentratie op specifieke doelstellingen en duidelijke omschreven resultaten is een absolute noodzaak voor ieder team dat zichzelf op prestaties beoordeelt.".

In het artikel De harde hand van Ronald Koeman op nusport blijkt dat Ronald Koeman in ieder geval de 4e frustratie goed begrepen heeft:

ronald koeman patrick lencioni

Bij Feyenoord merkte Koeman al snel dat zijn spelers veel te weinig van elkaar eisten. Bijna niemand corrigeerde een ander. Wat is dít, dacht hij in zijn eerste weken.

Maar zie wat er gebeurde. [Koeman] stimuleerde zijn spelers de afgelopen maanden bijna dagelijks om elkaar meer en meer op te peppen en te coachen. Langzaamaan zag hij het saamhorigheidsgevoel, het zelfcorrigerend vermogen en het vertrouwen binnen Feyenoord groeien.

Gevolg: Koeman mengde zich met een selectie die kwalitatief veel brozer en onevenwichtiger is dan die van Ajax, PSV en FC Twente in de strijd om de bovenste plaatsen. Net als Verbeek met AZ. Beide trainers persten zo’n beetje het maximale uit de mogelijkheden van hun team, bijna een heel seizoen lang.

Bron: De vijf frustraties van teamwork, Patrick Lencioni en De harde hand van Ronald Koeman

Laatst aangepast op woensdag, 27 december 2017 07:38  


JPAGE_CURRENT_OF_TOTAL

 

Nothing is so fatiguing as the eternal hanging on of an uncompleted task.

William James 

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 90 gasten online
Artikelen

continu verbeteren mark twain continuous improvement delayed perfection

Banner
Banner

gelukkig zijn kun je leren martin seligman

Gelukkig zijn kun je leren
Martin E.P. Seligman

Bij managementboek | Bol.com

Lean boekentips

Banner