2. Basis: ICT management, eisen, trends en nut architectuur. 2.1. Welke eisen stelt men aan ICT voorzieningen? 2.1.1. Service pit en service schil: producten en diensten. 2.1.2. Kwaliteitseisen: waar komen ze vandaan? 2.1.3. Realiseren van deze eisen. 2.1.3.1. Functionele eisen aan het product/dienst en het proces. 2.1.3.2. Prestatie eisen aan het product/dienst en het proces. 2.1.4. Wat wil je : verkleining van GAP´s tussen vraag en aanbod. 2.2. Waarmee start het leveren van ICT diensten dan ook?  Architectuur. 2.3. De basis: een architectuur voor het leveren van ICT diensten en producten. 2.3.1. Hoe ziet die architectuur eruit?. 2.3.2. Die architectuur moet meegroeien! 2.3.3. Hoe kun je die architectuur realiseren? 2.3.4. Ook aan architectuur is er niet direct……. 2.3.4.1. Hoe komen we van nu naar morgen? 2.3.4.2. Modelmatig kijken naar het tot stand komen van een architectuur. 2.3.5. Toetsen van die architectuur met standaard modellen.

2.1.1.Service pit &service schil: producten en diensten. In principe leveren we op de vraag én dan naar niveau: - keten - organisatie - delen organisatie En dat antwoord bestaat uit twee delen: - object : product/dienst - processen: eromheen waarbij soms ene, soms andere belangrijker is Functionaliteit Prestatie eisen -beschikbaarheid -capaciteit -tijdsgebonden aspecten

2.1.2. Kwaliteitseisen: waar komen ze vandaan? Functionele eisen : wat moet het product/dienst doen en wat het proces Prestatie eisen : hoe goed moet dat dan? Vul dat eens in met de service pit en de service schil (Ruijs c.s., 2003): E-mail: Functionele eisen: Prestatie eisen: Beschikbaarheid: Tijdsaspecten: Capaciteit: MS-Outlook -agenda en mail - 7x 24 uur - e-mails moeten - maximaal 2000 - max. 2x per maand binnen 2 seconden e-mails per dag onderbreking van verzonden worden max. 2 uur Gebruikers- - alleen technische - op werkdagen van - problemen moeten - per week gem. ondersteuning problemen 7.00 tot 18.00 binnen twee uur 5 contacten hersteld zijn per dag Wijzigingen: nvt - melden van wijzigin- -binnen 2 dagen na - max. 5 kleine gen op werkdagen indienen verzoek wijzigingen per van 8.00 tot 17.00 keer Beveiliging: - tegen alle bekende - 7x 24 uur - nvt - nvt virussen - encryptie van data- verkeer Calamiteiten: - alleen e-mail geen - binnen 24 uur na - e mails binnen 2 - minimaal 500 agenda optreden calamiteit min. verzenden e mails p dag

2.1.3.1. Functionele eisen aan het product/dienst en het proces. Functioneel : datgene wat het product/dienst/proces op welk niveau (ketens, organisatie, delen van de organisatie) moet doen. Vanuit diverse visies te benaderen: 1. gebruiker: wat moet het product kunnen/de dienst leveren om het werk te ondersteunen. Welke ondersteunende processen moeten erbij? 2. algemeen of business management: waarde voor de organisatie, als we deze diensten/producten kopen of door dit proces ondersteund wordt.. 3. beheerder: belang van de functie voor de beheerbaarheid van het product/de dienst. Bedenk dat elke dienst/product/proces een informatiestroom genereert over storingen, fouten en gebruik. 4. realisator: belang van de dienst/product/proces in het kader van de realisatie of levering. Wanneer moeten we de dienst opleveren? Hoe wordt de dienst zonder dit proces ervaren?

2.1.3.2. Prestatie eisen aan het product/dienst en het proces. Product/dienst/proces ISO9126 aangevuld met het Quint rapport doorvertaald (Boeters, 1997) Constateer  algemene eisen aan services voor keten; hele of deel v.e. organisatie de vijf doelen en hun doorvertaling naar ICT diensten (Slack, 2004)

2.1.4. Wat wil je: verkleining GAP´s tussen vraag& aanbod. En men kan wat discussie krijgen! 1 = verwachtingen klant ongelijk perceptie lev. 2 = beloven niet gelijk aan doen 3 = medewerkers volgen standaards organisatie niet 4 = rapportage rooskleuriger dan werkelijkheid 5 = werkelijke dienstverle- ning wijkt af van de verwachting. En dat geldt voor product/ dienst en voor het proces van dienstverlening! product/dienst en proces dienst/product en proces & product/dienst dienst/product en proces dienst/product en proces

2.2. Waarmee start het leveren van diensten dan ook? Gartner (2003) : 1. sturing, 2. service processen en 3. ICT architectuur “ Architectuur “ kan zijn - beschrijving bestaande organisatie (today architectuur) - blauwdruk van de gewenste situatie (tomorrow architectuur) - verzameling richtlijnen voor het realiseren van nieuwe ontwikkelingen (next minute architectuur. Wat is zo handig aan een architectuur? hier: combinatie: Architectuur = Een kader voor het voorzien in ICT, waarin de aanwezige ICT objecten en de ermee gepaard gaande diensten passen en dat aangeeft conform welke lijnen tot uitbreiding of aanpassingen wordt gekomen 1. Uitgangspunt voor communicatie rond beheer: zelfde taal 2. Orde en samenhang en toch snel mee kunnen gaan: samenhang 3. Hulp bij modelvorming bv. tav. integratie, interfaces overzicht 4. Nut bij doelmatig en effectief implementeren richtlijn

2.3.1. Hoe ziet die architectuur eruit? Objecten en recepten: Bv. inkooprichtlijnen  recepten: het hoe vastgelegd in? Beleidsuitgangspunten Modellen Voorschriften: Plannen: Best practices ( organisatiebrede uitgangspunten (blauwdrukken of (concrete uitwerkin- (meerjaren (uitwerkingen uit voor bv. inkoop, personeel, modellen voor bv. gen van modellen plannen of het verleden, die financiering, planning enz.) bedrijfsprocessen in procedures of projectplannen voor hergebruik (bv. ITIL), gege- wijzen van uitvoe- voor leveren in aanmerking komen) vensarchitectuur) ring van taken) ICT) wat is het object? - diensten - infrastructuren - applicaties - organisatie En dan zie je vaak verschijnen: - procedures administratieve organisatie - handboeken rekencentra, netwerken enz. - plannen van de ICT organisatie met als topics beleid, evaluatie, wensen, projecten, middelen en prioriteiten. Bv. Processen

2.3.2. Een architectuur moet meegroeien! En waarom? 1. want wat gebeurt er? cfr. EDS 200% groei internet enabled diensten, 50000 servers, 40000 applicaties. 2. en bedenk vrijwel elke strategie wijzging leidt tot andere IV en ICT. cfr. Kwik Fit besluit zelden gevraagde banden in distributie centra te leggen  locaal zicht op voorraad  impact op inrichting ICT Oorzaak complexiteit? Wat doen we eraan? Hoe? Vele autonome eenheden Afstemmen besluitvorming Sturing Ongrijpbare voordelen Betere justificatie Sturing en ICT management Vele leveranciers Gemeenschappelijke processen ICT management op basis consistent ICT model Wereldwijd werken met locale aanwezigheid ICT architectuur plus ICT mngm’nt Snelle veranderingen met stabiele objecten ICT architectuur

2.3.3. Hoe kun je die architectuur realiseren? Mintzberg leerde ons drie basis aanpakken bij het komen tot een strategie van der Aar cs. gebruiken deze bij ko- men tot architectuur: Top down: noodzaak? organisatie invullen grenzen afbakenen en bouwblokken invullen Vanuit visie: de leider bepaalt en men werkt uit. Bv. de scenario planning bij Shell. Bv. de winkels en hun inrichting bij Ikea. Bottom up: verza-mel alle ideeën en implementeer goede Bv. de plan- ning bij 3M Top down eist commitment en dus een gedegen organisatorische steun van de inspanning. Hiervoor aandacht nodig voor de rol, die beheer speelt bij het implementeren van projecten. Maar wel kans om structuur aan te brengen met concepten en modellen. Bottom up : vaak beginnen met verzamelen van de best practices en deze kennis bij een enkel aanspreekpunt te leggen. Kans echter dan integrale samenhang ontstaat is klein. Draagvlak en gebruik kan beperkt blijven tot een afdeling.

2.3.4.1. Hoe komen we van nu naar morgen? Doel, proces, besturing, info Sturing ICT vanuit klant proces

2.3.4.2. Modelmatig kijken naar tot stand komen van architectuur Metagroep (2000) “even eigen positie bepalen.” Gartner (2003): “dat ICT loopt fasen door” fasen

2.3.5. Toetsen van die architectuur met standaardmodellen. Open Systems group eisen voor een architectuur van ICT voorzieningen en dan maar afchecken (!): De Open Systems group geeft voorts een pad om te komen tot een dergelijke architectuur. Applicaties: Application platform interfaces: interface met technische&informatische infrastructuren: Infrastructuren: a. programma- tuur: Communicatie infrastructuur interface: verbindt software met fysieke omgeving. b. Apparatuur en verbindingen enz. Wijdverspreide applicaties als Office en internet, waarbij interoperabiliteit, gebruikers- interactie en de aanwezigheid van technische infrastructuur een must is. (bv. EFT diensten, intelligent agents, spreadsheets, tekstverwerking, electronic mail, publiceren en aanmelden) Bedrijfsprocessen ondersteunende applicaties voor een bepaald proces of voor een bepaald organisatiedeel, bv. ERP applicaties (bv. inkoopondersteuning, salarisapplicaties, CRM, ziekenhuisinformatiesystemen, belastingdienstapplicaties) Data uitwisselings diensten: bv. fax, tekst Netwerkdiensten: datacommunicatie als TCP/IP enz. Data management diensten: bv. DBMS Operating systemen: oa. batch, remote, file services Grafische ondersteuning, bv. tekenen en beelden Internationaal opereren, bv. lokale talen steun Locatie en directory diensten, bv. accounting, filteren Software engineering diensten, bv. case tools, editors Transaction processing services, bv. monitoren User interface diensten, bv. dialoog steun Beveiligingsdiensten: bv. encryptie en toegangscontrole Beheerdiensten: gebruikersmanagement, capaciteitsbeheer Programmatuur vd. technische en infor-matische infrastructuur Hardware/verbindingen en dicht erop liggende software.