• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
www.eenblogjeom.nl
Applicatieportfoliomanagement volgens Arjan Juurlink
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

applicatieportfoliomanagement

Arjan Juurlink beschrijft in zijn boek Applicatieportfoliomanagement voor IT-complexiteitsreductie het belang van hebben van een helder inzicht in het applicatielandschap en het vastleggen van de relevante gegevens in een zgn. Applicatie Inventory. In het onderstaande wordt aangegeven wat volgens Juurlink de belangrijke aspecten zijn van het applicatie en geeft inzicht in de de belangrijkste begrippen en processen die een rol spelen bij het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

IT (Service)-portfoliomanagement: paraplubegrip voor alle activiteiten die zich bezighouden met het in lijn brengen van de IT-voorzieningen en de strategische doelstellingen van de organisatie. Het gaat om het besturen van de samenhang van de portfolio van IT-diensten met de strategie van de organisatie. Doel is door te sturen op samenhang in de portefeuille van IT-services de effectiviteit van de inzet van IT toe te laten nemen.

In het ideale geval is een organisatie in staat om naar IT-voorzieningen te kijken als onderdeel van business-services. Applicaties zijn het meest zichtbare deel van een business-service en worden door de gebruiker vaak als een geheel gezien met gegevens en infrastructuur. Omdat een SLA de dienstverlening vaak beschrijft in relatie tot het (complexe) applicatielandschap, gebruikt Arjan Juurlink het begrip applicatieportfoliomanagement als hulpmiddel voor het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

Voor het kunnen reduceren van de complexiteit in het applicatie- en infrastructuurlandschap is het volgens Juurlink noodzakelijk een Applicatie Inventory ('single-source-of-truth') aan te leggen, waarin minimaal voor elke applicatie de kosten, het belang en het risico (incl. de verwachte ontwikkeling van alledrie de aspecten tot het eind van de levenscyclus). Juurlink waarschuwt voor het gevaar om té veel zaken vast te leggen en pleit voor het vastleggen van een beperkt aantal gegevens voor het gehele landschap. Op basis van need-to-know is het mogelijk later alsnog meer informatie te inventariseren. Hij onderscheidt drie categorieën informatie:

  1. Analysegegevens: gegevens die nodig zijn om het applicatielandschap in te delen in categorieëen. Het is van belang deze groep gegevens zo beperkt mogelijk te houden, omdat deze informatie voor het gehele landschap moet worden vastgesteld.

  2. Rapportagegegevens: wanneer de eigenaar van een groep applicaties wil kunnen sturen op de afhankelijkheden en op de voortgang van de migratie naar de doelarchitectuur, zijn overzichten nodig op basis van doorsneden en invalshoeken (zoals proces, informatie- of productdomein, ontwikkelomgeving en soort technologie), om de voortgang (in 'standgegevens') te kunnen volgen.

  3. Executiegegevens: (tijdelijke) gegevens die nodig zijn om te weten wanneer een applicatie daadwerkelijk wordt gemigreerd, zoals bijvoorbeeld aantallen logische of fysieke database-instanties. Het verzamelen van deze gegevens vindt plaats op basis van need-to-know en alleen voor applicaties die deel uitmaken van een migratie.

Juurlink clustert de eigenschappen van een applicatie in zeven categorieën:

  1. Applicatiegegevens: [ identificatie, naam, versie | service level | status | maatwerk/standaard | fase levenscyclus | client/server/beide | jaar in productie | datum laatste release | jaar end-of-life ]

  2. Functionele gegevens: [ relatie procesketen | relatie bedrijfsproces | belang voor bedrijfsproces | mate waarin proces wordt ondersteund | mate van gebruik (business events) | doelomgeving ja/nee | functionele kwaliteit ]

  3. Gebruiksgegevens: [ aantal gebruikers | gem. frequentie van gebruik | aantal installaties | aantal incidenten | performance | gebruikerstevredenheid | datakwaliteit | inleertijd ]

  4. Organisatiegegevens: [ businesseigenaar (eigenaar functionaliteit) | eigenaar applicatie | functioneel beheerteam | applicatiebeheerteam | aantal beheerders in organisatie | aantal beheerders buiten de organisatie ]

  5. Leveranciersgegevens: [ leveranciersnaam | productnaam | productversie | omvang leverancier | binnen/buitenlands ]

  6. Technische gegevens: [ hardwareplatform | operatingsystem | DBMS | aantal interfaces intern/extern | ontwikkelplatform | aantal regels code | middleware | doelomgeving ja/nee | technische kwaliteit ]

  7. Business-strategie: op welke wijze draagt applicatie bij aan de strategie?

Arjan Juurlink hanteert de volgende definities:

  1. Applicatie: eenheid van functionaliteit die van buitenaf autoriseerbaar is ten behoeve van een eindgebruiker. Een applicatie ondersteunt één of meer stappen uit een bedrijfsproces. Alles wat verdwijnt op het moment dat een applicatie wordt uitgezet, behoort tot deze applicatie.

  2. Component: een applicatie bestaat uit componenten, een component is ondeelbaar en draait op dezelfde technische stack (optelsom van functionaliteit, ontwikkelplatform, databaseplatform, middleware, operating system en hardware).

  3. Informatiesysteem: aantal applicaties die een bepaalde samenhang hebben (in termen van onderlinge verbindingen tussen applicaties, componenten en/of eindgebruikers).

Volgens Arjan Juurlink kunnen vijf soorten applicaties worden onderscheiden:

  1. End User-applicatie: applicaties die door eindgebruikers zélf zijn ontwikkeld (vaak op eigen werkplek, denk aan allerlei Excel-trucendozen)

  2. Image-applicaties: in verre mate gestandaardiseerde besturingssoftware en/of gebruikerssoftware (MS Office, internetbrowsers).

  3. Standaardkantoorapplicaties: standaarddiensten (meestal standaardpakketten) die een gebruiker kan bestellen via de IT-catalogus.

  4. SLA-applicaties: applicaties die niet standaard in de bestelcatalogus voorkomen, en meestal worden gebruikt ter ondersteuning van de (primaire) bedrijfsprocessen. Voor deze applicaties worden Service Level Agreements (SLA's) afgesloten met de (interne) leverancier, bijv. ten aanzien van beschikbaarheid, maximale tijd voor afhandeling van storingen. Het gaat meestal om uitgebreidere standaardpakketten, ERP-pakketten en specifieke maatwerkontwikkelingen.

  5. IT-for-IT applicaties: ontwikkel- en beheertools, 'tooling' om IT-diensten te maken en/of beheren.

Nadat de basisgegevens van het applicatielandschap zijn geïnventariseerd en geregistreerd, is het mogelijk applicaties te classificeren. Classificatie helpt bij het bepalen van migratiescenario's naar de doelarchitectuur of uitfasering. Arjan Juurlink noemt de volgende veelvoorkomende scenario's:

  • Behouden
  • Uitbouwen
  • Opschonen
  • Herplatformen
  • Migreren
  • Consolideren
  • Vervangen
  • Uitzetten

Arjan Juurlink beschrijft zijn boek beknopt ASL en BiSL, maar in relatie tot complexiteitreductie zijn vooral drie processen van belang:

  1. Applicatielifecyclemanagement : ASL-proces dat beslissingen faciliteert over investeringen in vernieuwing en onderhoud van een applicatie (gebaseerd op de levenscyclus van de applicatie).

  2. Applicatieportfoliomanagement: ASL-proces dat het applicatie- en infrastructuurlandschap optimaliseert voor de bedrijfsdoelstellingen.

  3. Planning en control: BiSL-proces wordt door Juurlink vertaalt naar projectportfoliomanagement dat zich bezig houdt met de coördinatie van projecten en programma's van een organisatie om de realisatie te optimaliseren, het risicoprofiel van de portfolio evenwichtig te houden en ervoor te zorgen dat projecten in lijn zijn met de strategie van de organisatie en binnen budgettaire grenzen wordt opgeleverd.

Volgens Juurlink bij het nemen van 'portfoliobeslissingen' gekeken worden naar de verdere - liefst gehele - levensduur van applicaties en de onderliggende infrastructuur. De lifecycle van functionaliteit wordt opgedeeld in drie categorieën:

  1. Doelapplicaties: applicaties die (al) deel uitmaken van de doelomgeving.

  2. Te migreren kernapplicaties: applicaties waarvan de functionaliteit nog niet in de doelomgeving is gemigreerd (maar dit moet nog wel gebeuren omdat deze applicaties nog zeker zo'n drie tot vijf jaar gebruikt moeten worden).

  3. Legacy applicaties: applicaties die nog binnen de planperiode (meestal 1 tot 3 jaar) gesaneerd zullen worden.

Zie ook:

Bron: Applicatieportfoliomanagement voor IT-complexiteitsreductie, Arjan Juurlink

Laatst aangepast op maandag, 01 januari 2018 12:56  
LSS: Van VOC naar CTQ
Gepubliceerd in Lean Six Sigma
E-mail Afdrukken

voc ctq lean

Een van de belangrijkste principes van Lean Six Sigma is het weten wat de kritieke kwaliteitseisen (Critical to Quality, CTQ's) zijn van je klanten en vervolgens moet je goed weten hoe de processen in elkaar zitten en ervoor te zorgen dat ze de CTQ's kunnen waarmaken. Elk proces moet een duidelijke doelstelling hebben om een bijdrage te leveren aan het realiseren van de kritieke klanteisen. Dit betekent wel dat je eerst moeten weten wat je klant wil. Lean Six Sigma noemt dit het luisteren naar de voice of the customer (VOC, de stem van je klant).

customer first

The only way to meet the needs of the customer is by putting yourself in his or her shoes and asking yourself what they need, what would make them happy.

Website Toyota

Als je aan de slag wilt met Lean Six Sigma begin je altijd met de vraag wie je klanten zijn om vervolgens te achterhalen wat achterhalen ze willen.

klantvereisten ctq voice of the customer proces

Je kunt achterhalen wat je klanten willen door met hem te praten, naar ze te luisteren en ze te observeren (bijvoorbeeld via marktonderzoeken, focusgroepdiscussies, onderzoeksresultaten en klachtenmeldingen). Bij het luisteren naar de 'stem van de klant' hoor je vaak wat hij of zij wil in algemene termen. Dit betekent dat een vertaling nodig is van deze algemene termen naar specifieke kritieke klanteisen die meetbaar zijn. Deze vertaalslag verloopt via een drietrapsraket:

(1) Voice of the customer (VOC): de letterlijke stem van de klant

(2) Key issue: welke werkelijke behoefte gaat er schuil achter de VOC; wat zijn de belangrijke kwesties (key issues)

(3) Critical tot Quality (CTQ): welke concrete eis stelt de klant; welk meetbaar kenmerk is bepalend voor de waargenomen kwaliteit.

Het onderstaande voorbeeld geeft aan hoe je de vertaling van VOC naar CTQ: de stem van de klant kan aangeven: "Ik wordt in de wacht gezet of ik word met de verkeerde afdeling of persoon doorverbonden". Het bijbehorende key issue is dan: "De klant wil snel naar de juiste persoon worden doorverbonden". Concreet kan dit worden vertaald naar de volgende kritieke klanteis (CTQ): "Klant wordt direct de eerste keer met de juiste persoon doorverbonden".

De vertaling naar CTQ's is binnen Lean Six Sigma een cruciaal hulpmiddel om te achterhalen wat de klant écht wil en de relatie te begrijpen tussen de eisen die de klant stelt (customer requirements) en en deze te vertalen naar meetbare criteria identificeert die belangrijk zijn voor de kwaliteit van het product of de dienst door de ogen van de klant. Ook als is de klant zeker koning, ook de business zélf is belanghebbende bij de producten en/of diensten die de organisatie produceert. Dit betekent dat ook de 'stem van de business' (Voice of the business, VOB) moet worden gehoord, en vertaald naar CTQ's. De CTQ's die voortvloeien uit de VOB worden ook wel Critical to Business (CTB) genoem en de CTQ's die horen bij de VOC: Critical to Customer (CTC).

ctq vob voc outputindicatoren key issues

Een CTQ wordt binnen Lean Six Sigma gedefinieerd als een meetbaar kenmerk dat - vanuit het oogpunt van de klant - kritiek is voor de waargenomen kwaliteit van het product, proces of systeem. Een CTQ mag geen oplossing voorschrijven. Een CTQ moet meetbaar zijn en indien van toepassing een onderste en bovenste specificatielimiet en een doelwaarde hebben. Een CTQ moet een positieve uitdrukking zijn van wat de klant wil, in plaats van een negatieve uitdrukking van wat de klant niet wil. Een CTQ kan worden ontleed in vier componenten: (1) het outputkenmerk, (2) de KPI, (3) een doelwaarde (target), en (4) tolerantiegrenzen: door de klant gespecificeerde grenzen waarbinnen het kenmerk moet 'scoren'. Zodra duidelijk is welke kritieke klanteisen het proces moet waarmaken, is het mogelijk het proces zodanig in te richten en te optimaliseren dat het - met een hoge mate van voorspelbaarheid - aan de gestelde eisen voldoet.

voice of the customer ctq kpi target

De drietrapsraket om de VOC via Key Issues te vertalen naar CTQ's wordt soms ook gevisualiseerd in een CTQ-boom. De CTQ-boom (Critical to Quality Tree) is een hulpmiddel om goed te kunnen evalueren wat de klant werkelijk belangrijk vindt in de geleverde dienst of product. Eerst wordt de behoefte van een bepaalde klant gedefinieerd. Vervolgens wordt een aantal takken geplaatst (vorming van de boom) waarin weergegeven wordt welke aspecten hieraan belangrijk zouden kunnen zijn voor de klant. Daarna wordt voor deze aspecten gedefinieerd welke (meetbare) zaken daarin bijdragen. Het resultaat is een inzicht in wat de klant wil, waaraan het proces moet voldoen om de klant tevreden te stellen. Dat wordt meteen meetbaar gemaakt.

ctq boom klanteisen

Concreet doorloop je bij het opstellen van een CTQ-boom de onderstaande stappen:

  1. Omschrijf helder het product of de dienst.

  2. Bepaal voor welke klanten(groepen) de boom wordt opgezet.

  3. Bepaal welke behoeften van de klant daarmee worden vervuld.

  4. Stel vast welke aspecten van de levering van het product of dienst bijdragen aan het vervullen van die behoefte.

  5. Bepaal door steeds de vraag te stellen 'wat bedoel je precies met ...' wat uiteindelijk de meetbare eigenschappen zijn die van belang zijn voor het goed vervullen van de behoefte van de klant.

  6. Zet de drie niveaus (i) behoefte, (ii) aspecten, en (iii) meetbare eigenschappen) in een boomstructuur door verbindingen te leggen via lijnen.

In het artikel Lean Six Sigma in het ziekenhuis, hebben de auteurs Ronald Does en Benjamin Kemper het niet over een CTQ-boom, maar over een CTQ flowdown. Volgens Does en Kemper begint de meetfase van de DMAIC-methodologie met het maken van een CTQ-flowdown: " Een CTQ flowdown verbindt de projectdoelen met strategische focuspunten en procesindicatoren (CTQ's).

ctq flowdown boom

In het algemeen zullen CTQ's betrekking hebben op geld, tijd, kwaliteit of klanttevredenheid. De CTQ flowdown visualiseert de hiërarchische niveaus van CTQ's. Des te lager je een CTQ kiest als insteek voor het DMAIC-project, des te kleiner de scope. De gekozen CTQ vormt het te verbeteren aspect binnen het proces.

ctq flowdown

Samenvattend stelt Lean Six Sigma de klant centraal, door actief te luisteren naar de Voice of the Customer (VOC) en de klantspecifieke eisen te vertalen naar meetbare criteria voor het product of de dienst (CTQ's). De kritieke klanteisen moeten worden waargemaakt in het proces, zodat Lean Six Sigma in essentie neerkomt op het op elkaar afstemmen van de 'stem van het proces' op de stem van de klant.

Belangrijk bij het analyseren van de VOC/CTQ’s is te realiseren waar deze zich bevindt binnen de behoefte van de klant. Is het een ‘basisbehoefte’ , ‘meer is beter’, of is het een ‘delighter’? Als hulpmiddel kan hierbij gebruik gemaakt worden van een KANO-analyse.

Bron: 111 instrumenten voor kwaliteitsverbetering - Ingedeeld volgens de Six Sigma-verbetercyclus, Arend Oosterhoorn en Lean Six Sigma in het ziekenhuis, Ronald Does & Benjamin Kemper

Laatst aangepast op woensdag, 02 september 2020 08:29  
Reclame als weggegooid geld volgens Lord Leverhulme
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

citaat quote

de helft van wat ik uitgeef aan reclame is weggegooid geld. Het probleem is dat ik niet weet welke helft.

Lord Leverhulme

Laatst aangepast op zondag, 23 april 2017 06:40  
Anders organiseren & beter werken (boekentip)
Gepubliceerd in Management
E-mail Afdrukken

anders organiseren beter werken amelsvoort

Anders organiseren & beter werken
handboek sociale innovatie en verandermanagement
G. Van Hootegem, P. van Amelsvoort ea 

Bij Bol.com





Laatst aangepast op woensdag, 25 september 2013 08:24  
5 intellectuele vaardigheden volgens Gagné & Briggs
Gepubliceerd in Bluff Your Way Into
E-mail Afdrukken

intellectuele vaardigheden

Monique Boekaerts en Robert-Jan Simons beschrijven in hun boek Leren en instructie - de psychologie van de leerling en het leerproces de onderwijsleertheorie van Gagné en Briggs (1979). Binnen deze theorie worden vijf soorten intellectuele vaardigheden onderscheiden:

monique boekaerts robert-jan simons leren instructie

  1. Discriminaties: objecten als gelijk of verschillend waarnemen.

  2. Concrete begrippen: kenmerken van een object identificeren.

  3. Gedefinieerde begrippen: een definitie gebruiken.

  4. Principes: een regel toepassen.

  5. Probleem oplossen: een meer complexe regel genereren van simpele regels.

Bron: Leren en instructie - de psychologie van de leerling en het leerproces, Monique Boekaerts & P. Robert-Jan Simons

Laatst aangepast op zondag, 05 januari 2020 16:15  


JPAGE_CURRENT_OF_TOTAL

We would rather be ruined than changed,
We would rather die in our dread
Than climb the cross of the moment
And let our illusions die.

W. H. Auden

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 91 gasten online
Artikelen

without standards improvement taiichi ohno

Banner
Banner

coachingsinstrumenten boek susan ass

Het Coachingsinstrumenten Boek
Voor en door topcoaches
Susan van Ass

Bij Bol.com | Managementboek



Lean boekentips

Banner