eindrapport professionaliseren functioneel beheer

Kenmerk: SB/UIM/12/0801/FS Datum: Augustus 2012

“Professionaliseren functioneel beheer instellingssystemen” Eindrapport en bijlagen Inhoudsopgave:

1. Inleiding ........................................................................................................ 2

2. Resultaten ..................................................................................................... 3 2.1 Wijzigingenbeheer en contractmanagement ............................................................. 3 2.2 Samenhang instellingssystemen, toetsen en testen ................................................. 5 2.3 Training, communicatie en bewustwording ............................................................... 5

3. Bijlage 1: Inventarisatie en informatiebehoefte wijzigingenbeheer ......... 7

4. Bijlage 2: Overzicht van gewenste verantwoordelijkheden en bevoegdheden in het wijzigingenproces ................................................. 11

5. Bijlage 3: Voorstel voor onderzoek naar tool voor registratie gebruikerswensen. ..................................................................................... 12

6. Bijlage 4: Voorstel voor het maken van afspraken over instellingssystemen ................................................................................... 13

7. Bijlage 5: Overzicht van gewenste verantwoordelijkheden en bevoegdheden bij toetsen en testen ........................................................ 15

8. Bijlage 6: Overzicht instellingsystemen, overlegvormen en contactpersonen ........................................................................................ 16

9. Bijlage 7: UFO functieomschrijving functioneel (informatie)beheer ..... 20

10. Bijlage 8: Definities functioneel beheer, applicatiebeheer en technisch beheer ........................................................................................ 25

11. Bijlage 9: Voorstel voor een functioneel beheer overleg .................. 28

12. Bijlage 10: Inhoudelijke samenvatting van het project “professionaliseren functioneel beheer” (poster) ................................... 29

Eindrapportage project „Professionaliseren functioneel beheer instellingssystemen” 2

1. Inleiding

Begin 2011 is het project “professionalisering van functioneel beheer instellingssystemen” van start gegaan. Dit project beoogt het neerzetten van de discipline, of: het vak, van functioneel beheer in de UT-organisatie. Het betreft het beheer van UT-brede applicaties of: instellingssystemen waarbij wordt gekeken naar de niet-technische kant van het beheer, dus meer aan de kant van de houder en gebruiker dan de kant van de ICT-beheerder. De instellingssystemen worden, uiteraard, ook nu al beheerd. Het idee achter het project is om het beheer op een hoger kwaliteitsniveau te brengen en vooral meer geïntegreerd met het beheer van andere instellingssystemen. Als aanpak was gekozen “voor en door functioneel beheerders”.

Ter voorbereiding van het project hebben een aantal functioneel beheerders en leden van het I-beraad nagedacht welke resultaten het project moet opleveren;

In het project hebben diverse UT medewerkers meegewerkt aan de resultaten:

Eenheid Deelnemers

S&O Rudy oude Vrielink, Timo van Limbeek, Joyce Pasman, Miranda van Amstel

B&A Gert-Jan Boers, Miranda van Amstel, Jan van Wietmarschen, Lineke Klunder

FEZ Nolet Derksen, Carola Slot, Ellis Ruhlmann

HR Marja Roelofs, Hariët ter Horst, Marco Anzalone

M&C Gerty de Wolf, Anne Heining, Arjan Grobben

FB Marc Hulshof

ICTS Roger Quaedvlieg

S&B/UIM Frank Snels

Het rapport bestaat verder uit het samenvatten van de resultaten en een aantal bijlagen waarin de resultaten staan weergegeven. Drie van deze resultaten bestaan uit voorstellen voor vervolg: een onderzoek naar een tool voor het registreren van gebruikerswensen (bijlage 2), het maken van afspraken over instellingssystemen (bijlage 3) en het opzetten van een functioneel beheer overleg (bijlage 9).


2. Resultaten

De resultaten van het project kunnen grofweg in drie onderdelen verdeeld worden:

Wijzigingenbeheer en contractmanagement;

Samenhang, toetsen en testen;

Bewustwording, communicatie en training.

2.1 Wijzigingenbeheer en contractmanagement Meteen vanaf de start van het project ontstond de behoefte om inzicht te krijgen welke partijen/rollen betrokken (moeten) worden bij het opstellen van contracten of het opstellen van een wijzigingen proces. De projectgroep heeft hiervoor een veel gebruikte methode gehanteerd, waarbij de verantwoordelijkheden verdeeld worden in drie deelgebieden: technisch beheer, applicatie beheer en functioneel beheer. Gebleken is dat er geen eenduidige relatie bestaat tussen functioneel beheer, technisch beheer en applicatiebeheer. De reden hiervoor is dat de samenwerkingsvormen zeer divers zijn. Bijvoorbeeld: Bij sommige systemen is het applicatie beheer geoutsourced, bij sommige het technisch beheer en bij sommige beide. Beide kan bij 1 partij zijn, maar ook bij verschillende. Na een aantal sessies is geconcludeerd dat er voor de UT instellingssystemen alleen een algemene gewenste samenwerkingsvorm relatie beschreven kan worden tussen functioneel beheer, technisch beheer en applicatiebeheer.

Figuur 1: relatie tussen functioneel- applicatie- en technisch beheer


De verzamelde informatie per instellingssysteem over de relaties tussen: technisch beheer, applicatiebeheer en functioneel beheer zijn beschikbaar in de gemeenschappelijke directory voor functioneel beheerders. Wijzigingenbeheer Er heeft een inventarisatie plaatsgevonden hoe de huidige wijzigingsprocessen plaatsvinden gezien vanuit functioneel beheer van de instellingssystemen (bijlage 1). In een aantal sessies hebben functioneel beheerders van diverse eenheden samen met ICTS gediscussieerd over deze inventarisatie. Een belangrijke constatering was dat er wisselend gedacht werd over de flow van activiteiten die uitgevoerd kunnen of moeten worden bij het doorvoeren van wijzigingen. Een breed gedragen conclusie was om een uniforme voorbeeld “flow” te bedenken met eenduidige bevoegdheden en verantwoordelijkheden. Het resultaat van dit actiepunt is een overzicht (zie bijlage 2) waarin de gewenste UT processtappen beschreven staan voor het doorvoeren van een wijziging met de bijbehorende verantwoordelijkheden. Uit de inventarisatie (bijlage 1) blijkt ook dat de meeste functioneel beheerders eigen lijsten, applicaties of mailboxen gebruiken voor het registeren van wensen, vragen en klachten die tot een wijziging (kunnen) leiden. De voortgang op een wijziging wordt bijgehouden door de functioneel beheerder zelf. Het is hierbij duidelijk geworden dat niet alle incidenten en voorstellen bij ICTS-ISA of de servicedesk bekend zijn of horen te zijn. Zo wordt bijvoorbeeld een wens uit een gebruikersoverleg wel geregistreerd door functioneel beheer, maar wordt niet altijd als een wijzigingsverzoek of vraag naar de leverancier gestuurd (ICTS of externe leverancier). Alle eenheden hebben aangegeven behoefte te hebben aan een eigen wijzigingen/wensen/klachten registratie. Als resultaat van dit project is namens alle eenheden een voorstel opgesteld voor onderzoek, selectie en implementatie van een tool voor het registeren van gebruikerswensen (zie bijlage 3). Contractmanagement Binnen het project is begonnen met het inventariseren van contracten, SLA’s en problemen rond contractmanagement. In de gezamenlijke directory zijn wel een aantal contracten opgenomen, maar het inventariseren is stopgezet. Reden is dat Inkoop en ICTS gezamenlijk een initiatief hebben gestart voor de ontwikkeling en implementatie van contractmanagement. Afstemming heeft plaatsgevonden om dubbel werk te voorkomen. Via dit traject zijn de meeste contracten van de externe instellingssystemen in het contractmanagement systeem opgenomen. ICTS gebruikt voor het procesmatig werken de ITIL en APM (Alignability Process Model) standaard. In 2010 heeft dat een impuls gekregen en wordt ondersteund door een Service Management tool. Door deze ICTS-interne voorbereidingen wordt het nu mogelijk om per instellingssysteem afspraken(interne contracten) in gezamenlijkheid tussen houders en ICTS op te stellen en af te sluiten. Als resultaat is een voorstel gemaakt om de beheerafspraken over instellingssystemen te verbeteren (zie bijlage 4). Samenvatting resultaten

Inzicht in de UT relaties tussen technisch beheer, applicatiebeheer en functioneel beheer;

Inventarisatie en informatiebehoefte wijzigingenbeheer (bijlage 1);

Overzicht gewenste UT verantwoordelijkheden wijzingenproces (bijlage 2);

Voorstel toolselectie registeren gebruikerswensen (bijlage 3);

Voorstel verbeteren beheerafspraken instellingssystemen (bijlage 4).


2.2 Samenhang instellingssystemen, toetsen en testen Toetsen en Testen Er is een vragenlijst opgesteld en ingevuld over het testbeleid per instellingssysteem. Bijvoorbeeld is gevraagd naar het releasebeleid, het testen van patches en updates, de testomgeving, de testorganisatie, et cetera. De ingevulde vragenlijsten zijn niet in een bijlage uitgewerkt, maar zijn wel beschikbaar in de gemeenschappelijke directory. In een aantal sessies is de inventarisatie gezamenlijk besproken om verschillen en overeenkomsten te analyseren. Testplannen en releasekalenders zijn verzameld en staan als best practices beschikbaar in de gemeenschappelijke directory voor functioneel beheerders. Als resultaat van de gemeenschappelijke sessies is een toets en testverantwoordelijkheden overzicht opgesteld (bijlage 5). Hierbij is gekozen voor het benoemen van de verantwoordelijke in de gehele keten van toetsen en testen (van het toetsen of een gebruikerswens goed is opgeschreven tot aan de acceptatie in de productieomgeving). Samenhang instellingssystemen De wens tot samenwerking wordt versterkt doordat de systemen meer en meer worden geïntegreerd. Eerder genoemde producten zoals een gewenste situatie voor het doorvoeren van wijzigingen en een uniforme aanpak voor testen, dragen bij aan een betere samenhang tussen instellingssystemen. Om ook de samenwerking te bevorderen is op basis van de officiële lijst van instellingsystemen (bron: ISA jaarplan), een overzicht gemaakt (Bijlage 6). Dit overzicht beschrijft van overlegvormen per systeem, de relaties die de systemen hebben met andere systemen en de contactpersonen bij de houders en ICTS. Samenvatting resultaten:

Best practices testen (gemeenschappelijke functioneel beheer directory)

Overzicht gewenste UT verantwoordelijkheden toetsen en testen (bijlage 5)

Overzicht instellingsystemen, overlegvormen, koppelingen en contactpersonen (bijlage 6)

2.3 Training, communicatie en bewustwording Training De meeste functioneel beheerders en enkele medewerkers van ICTS/ISA (Ongeveer 30 UT medewerkers) hebben een training functioneel beheer (BiSL) gevolgd via twee open inschrijvingen, een training voor de functioneel beheer voorbereidingswerkgroep en een training voor het functioneel beheer team van S&O. BiSL (Business Information Services Library) is de defacto standaard in Nederland voor het vakgebied van functioneel beheer. Het trainingsmateriaal en de trainingen zijn door medewerkers van de UT zelf verzorgd. Iedere trainee heeft een reader gekregen met sheets en artikelen, en heeft een BiSL boek gekregen dat dient als naslagwerk voor het werken als functioneel beheerder (BiSL). Communicatie en bewustwording Door de ontwikkelingen op het gebied van informatievoorziening wordt het vakgebied van functioneel beheer alleen maar belangrijker. De erkenning van het vak en de rol van functioneel beheer is daarbij essentieel. Door de komst van dit project krijgt functioneel beheer meer aandacht in de UT organisatie. De functioneel beheerders zelf hebben enthousiast meegewerkt in dit project. De aanpak “voor en door functioneel beheerders” heeft gewerkt. Er hebben een aantal inventarisaties plaatsgevonden, vele discussies over het vakgebied en de relaties met leveranciers. Door


functioneel beheerders met elkaar in contact te brengen, blijkt dat men meer gezamenlijk heeft dan van tevoren werd gedacht. In samenwerking met de concerndirectie HR is er in het een landelijke functie waardering systeem (UFO) een profiel opgesteld voor functioneel (informatie) beheer (bijlage 7). De UT is mede initiator geweest voor dit profiel. Het nieuwe (november 2011) UFO profiel is gebaseerd op de standaard methodiek BiSL. Door publicatie van een UFO mét functioneel beheer, wordt de functie meer zichtbaar en de taken eerder erkend. Op de website van informatiemanagement is een onderdeel gemaakt voor functioneel beheer (www.utwente.nl/im). Relevante resultaten van het project en andere wetenswaardigheden over functioneel beheer staan hier vermeld. Tevens is er een centrale directory voor de functioneel beheerders die in de projectgroepen hebben deelgenomen. Om de communicatie tussen functioneel beheerders en met leveranciers te verbeteren is BiSL als standaard geadopteerd. In de projectsessie is gebleken dat de definities en verantwoordelijkheden tussen functioneel beheer (FB), applicatiebeheer (AB) en technisch beheer (TB) cruciaal zijn voor een goede samenwerking. Om deze reden heeft het project een aparte bijlage gemaakt met daarin de definities van FB, AB en TB (bijlage 8). Er zijn diverse presentaties verzorgd voor functioneel beheerders en leden van het I-beraad over functioneel beheer. Na goedkeuring van de resultaten door het I-beraad wordt als laatste actie van het project een bijeenkomst gepland (najaar 2012) voor alle functioneel beheerders, leden I-beraad en relevante ICTS medewerkers. Deze bijeenkomst is bedoeld om de UT-medewerkers te informeren over de resultaten van dit project en om meer inzicht te krijgen in de (nieuwe) interne werkwijze van ICTS. Alle deelnemers van het project vonden het project een goede start om de communicatie tussen functioneel beheerders te verbeteren. Het kan en mag niet zo zijn dat door beëindiging van het project, ook de samenwerking tussen functioneel beheerders stopt. Om deze reden is één van de resultaten van dit project een voorstel voor een structureel functioneel beheer overleg (bijlage 9). Indien het I-beraad akkoord gaat, zal de bovengenoemde bijeenkomst tevens de start zijn van een functioneel beheerders overleg. Ook is nagedacht hoe we voorkomen dat de eindresultaten van dit project in de bureau la verdwijnen. Het beschrijven van een gewenste situatie is immers een startpunt voor samenwerking en niet het eindpunt. Om de belangrijkste resultaten goed onder de aandacht van UT medewerkers te kunnen brengen heeft de projectgroep een poster bedacht met daarop de belangrijkste resultaten van het project (bijlage 10). Samenvatting resultaten

30 UT medewerkers hebben een training functioneel beheer (BiSL) gevolgd;

25 BiSL boeken zijn aangeschaft als naslagwerk;

Diverse presentaties over functioneel beheer;

UFO profiel (functiewaardering) voor functioneel (informatie) beheer (bijlage 7).

Deel van website voor functioneel beheer (www.utwente.nl/im).

Definities functioneel beheer, applicatiebeheer en technisch beheer (bijlage 8)

Voorstel UT-breed functioneel beheer overleg (bijlage 9);

Poster functioneel beheer (bijlage 10)

http://www.utwente.nl/im


3. Bijlage 1: Inventarisatie en informatiebehoefte wijzigingenbeheer

Systeem ideeen, eisen , vragen en klachten voorstellen maken (offertes, ontwerpen, impact analyses, releasekalender)

afspraken en bevestiging (goedgekeurde offerte, vastgelegde afspraken, planning)

Oplevering, in productie, controle op uitvoering

Opmerkingen

Oracle Applications (proces)

"HR: De opmerkingen, wensen uit het DOP overleg worden verzameld, beoordeeld en uitgewerkt. Soms komt de salarisadministratie of de Service Desk met een wijzigings verzoek. De wet en regelgeving kan ook wijzigingen tot gevolg hebben. FEZ: Wensen worden via het administrateursoverleg bij FEZ-Infra aangedragen. Problemen worden vaak rechtstreeks bij FEZ-Infra gemeld." Jaarlijks vindt er afstemming plaats tussen FEZ en ICTS over grote projecten die opgenomen moeten worden in het ISA jaarplan.

HR: De wensen en klachten worden intern besproken en in het Oracle HR overleg op de agenda gezet. FEZ: Indien alle faculteiten / diensten akkoord gaan met de wijzigingen, worden deze met ICTS besproken. Waar nodig wordt de externe consultant geraadpleegd en eventueel om een offerte gevraagd.

HR: De wensen, klachten en noodzakelijke wijzigingen worden in het Oracle HR overleg besproken met ICTS en er wordt een prioritering aan gegeven. FEZ: Wijzigingen in de inrichting kunnen in sommige gevallen direct door FEZ-infra uitgevoerd worden. Overige punten worden door ICTS of externe consultants uitgevoerd. De planning / prioriteit wordt afgestemd. Bij grote wijzigingen wordt een projectgroep opgezet.

HR: testen in testen acceptatie omgeving; accesdatabase: datumgereed FEZ: testen volgens OTAP principe.

Het maatwerk binnen Oracle is door 2 partijen ontwikkeld, namelijk ICTS en TopConsult (externe partij). Indien er wijzigingen moeten komen in het maatwerk, wordt dit altijd bij ICTS aangemeld. De werkwijze hiervan is hetzelfde als bij de satellietsystemen. Indien nodig wordt TopConsult ingehuurd om de wijzigingen door te voeren.

Oracle Applications (vastgelegde gegevens)

HR: Notulen gebruikersoverleg, registratie probleemrapprotages, hierin staan alle beoordeelde en goedgekeurde wensen. FEZ: Notulen administrateursoverleg en mailtjes naar FEZ-Infra. De wijzigingen worden in een Excelbestand bijgehouden. Elke twee weken bespreekt een van de functioneel beheerders van FEZ de voortgang met ICTS en werkt dit bij in het bestand.

HR: accessdatabase (eigen) - beschrijving - is het uitgevoerd - datum/planning, nr. FEZ: Excelbestand (eigen) - beschrijving - datum/planning - voortgang

afhankelijk grootte project; opnemen in jaarplanning of in het overleg ICTS-HR de volgende release bepalen FEZ: - Opstellen projectplan - mail met afspraken naar consultants / ICTS - bijwerken Excelbestand

HR - Afsluiten probleemrapportage FEZ - bijwerken Excelbestand en gebruikers informeren.

Webhare lijstje (worddocument), gebruikerswensen, bugs A4 met probleembeschrijving (om de 10 maanden nieuwdocument) - ideen leverancier - offertes - bandbreedte in SLA

definitieve versie probleembeschrijving

testen in testomgeving ICTS doet alleen het serverbeheer/backup. Wijzigingen komen nauwelijks voor, omdat het een ‘volwassen’ systeem betreft. Wijzigingen worden projectmatig en in overleg met vertegenwoordigers van de gebruikersgroep circa één keer per jaar doorgevoerd, waarbij de wijzigingen (wensen) in een document omschreven en geregistreerd worden en S&C de voortgang bewaakt.

Studentenportal studentassistent verzamelt opmerkingen, hoe daar verder mee om wordt gegaan is nog niet bekend, op dit moment is het nog een pilot zonder verdere aanpassingen.

Op dit moment als pilot opgeleverd, daardoor voor alsnog beperkt wijzigingenbeheer: Nieuwe webapplicaties in het systeem (ICTS/S&C): Nog geen structureel beheer opgezet, op dit moment projectmatige (ICTS/S&C) verbetering van het systeem met twee vaste contactpersonen bij ICTS.





Opmerkingen

Osiris Wensen worden door functioneel beheer verzameld en vastgelegd via een wensenlijst (in Excel). De wensen worden of doorgegeven aan de leverancier van Osiris (2x per jaar), of aan ICTS (zoveel mogelijk verzameld; bijv. wijzigingen in SQL Word documenten). - De wijzigingsverzoeken die door functioneel beheer als service request zijn ingediend bij de ICTS Servicedesk worden bewaard in de Osiris mailbox. Zo ook de afmelding van de service request.

1e stap: landelijke wensenlijst met korte omschrijving wens en begroting door leverancier; stap 2: wens wordt uitgewerkt door leverancier tot detail ontwerp (incl. beoordeling door ontwerpgroep); stap 3: releasekalender

landelijke wensenlijst wordt in landelijke Commissie Adaptief Onderhoud besproken, instellingen zetten uren in op wensen. De uiteindelijke wensenlijst wordt goedgekeur in het Osiris Stategisch Overleg. Daarnaast worden de detail ontwerpen goedgekeurd door een ontwerpgroep waarin de diverse instellingen vertegenwoordigd zijn.

Oplevering release incl. releasenotes en definitieve detailontwerpen.Installatie en test in OTAP, gebruikers voeren acceptatietest uit. Go/no-go door FAB i.o.m. gebruikers. De planning en de voortgang van wijzigingen komen op de agenda van het beheeroverleg tussen functioneel beheer en ICTS.

Voor zeer grote wijzigingen wordt een project aangevraagd. Deze gewenste projecten worden beschreven in een zgn. programmaplan. - Knelpunten: o Er is binnen S&O geen goede tool beschikbaar voor het vastleggen van wensen.

SMS Wensen worden door functioneel beheer verzameld en vastgelegd via een wensenlijst (tot nu toe in een word document). De wensen worden doorgegeven aan ICTS (zoveel mogelijk verzameld). - De wijzigingsverzoeken die door functioneel beheer als service request zijn ingediend bij de ICTS Servicedesk worden bewaard in de Osiris mailbox. Zo ook de afmelding van de service request. - Knelpunten: o Er is geen gezamenlijke omgeving waar het wijzigingendocument (nu .doc) geraadpleegd en/of gewijzigd kan worden.

Wijzigingen/service requests worden bewaakt door functioneel beheer en ICTS (in geval tracking systeem). Meestal wordt hiervoor i.o.m. ICTS een planning voor opgesteld

Studielink Incidenten, wensen, etc. worden via een service desk tool gemeld bij Studielink. In deze tool wordt ook de status/voortgang, prioriteiten, ect. Bijgehouden (door SL). Daarnaast neemt de leverancier van Osiris deel aan diverse SL-werkgroepen, via dit onofficiele kanaal worden ook wensen gemeld.

SL bepaalt welke wensen er gerealiseerd worden en werken specificaties uit (black box voor ons). Wel krijgen we dan een reactie terug op de gemaakte call met daarin de oplossing of melding van "opgelost in release…". Daarnaast kondigt SL de releases aan met daarbij een planning en overzicht van de aanpassingen.

Wijzigingen die zijn ingediend bij Studielink, worden bewaakt door Studielink zelf en afgemeld middels mail met de vermelding wanneer en in welke release de wijziging in productie gaat.

De meeste aanpassingen zitten aan de SL-kant, hiervoor hoeft de UT niets te installeren/testen. Grote releases met echt nieuwe functionaliteit moeten wel ingericht en getest worden bij de UT. Installatie en test in Test, Acceptatie en Productie (door FAB ism CSA).

Metis Nog in projectstatus, procedure nog niet vastgelegd.





Opmerkingen

DECOS (proces) Verstoringen: Worden gemeld bij de servicedesk. Suggesties en klachten: Decos heeft een mailadres waar dit kenbaar kan worden gemaakt. Het kan ook via hun website Vragen: Bij de servicedesk of database met vraag en antwoord en ook "known issues" Eigen ontwikkeling: Verzoeken komen binnen bij afdeling Archief of Functioneel Beheer.

Verstoringen: De storing wordt gespecificeerd. Voorstel wordt gedaan door Decos hoe dit op te lossen. Bij een bug wordt dit vastgesteld. Suggesties en klachten: Hoe dit verder binnen Decos wordt afgehandeld is niet duidelijk. Wel is er een klankbordgroep met gebruikers die er invloed op kunnen uitoefenen. Eigen ontwikkeling: Op de testomgeving wordt een inrichting gemaakt. Soms wordt eerst een voorstel gedaan.

Verstoringen: Verstoring wordt bevestigd in een mail met daarbij de oplossing. Bij een bug wordt tevens aangegeven in welke versie deze wordt opgelost. Suggesties en klachten: Over de voortgang hiervan wordt je op de hoogte gehouden, tenminste dat is de bedoeling, duurt vaak lang. Eigen ontwikkeling: In het geval eerst een voorstel wordt gedaan, wordt deze na akkoord op test gezet. Daarna test de gebruiker.

Storingen op te lossen door Functioneel en Technisch Beheer: Invoeren en terugkoppelen met gebruiker. Soms is overleg vooraf nodig als bijv. de oplossing gevolgen heeft voor de gebruiker. Wijzigingen, bugfixes door Decos: Versie wordt op test gezet, getest door Technisch en Functioneel beheer en gebruiker en na akkoord op produktie gezet. Eigen ontwikkeling: Na goedkeuring van de gebruiker wordt de inrichting op produktie gezet

DECOS (vastgelegde gegevens)

mail, telefoon of website, worddocument, mondeling mail, telefoon, worddocument

mail Functioneel Beheer en gebruikers zetten hun testbevindingen in een excelsheet, mail, mondeling

Blackboard Wensen en uitgevoerde wijzigingen worden niet op een gestructureerde manier geregistreerd - De wijzigingsverzoeken die door functioneel beheer als service request zijn ingediend bij de ICTS Servicedesk worden bewaard in de Blackboard mailbox. Zo ook de afmelding van de service request. - Knelpunten: o Wensen en uitgevoerde wijzigingen worden niet op een gestructureerde manier geregistreerd

Als er voor een wijziging een change is gecreëerd, dan is de change coördinator (ISA contactpersoon) formeel verantwoordelijk voor de bewaking. Er is geen echte vervanger beschikbaar voor de ISA contactpersoon

voor zeer grote wijzigingen wordt een project aangevraagd. Deze gewenste projecten worden beschreven in een zgn. programmaplan - Knelpunten: o er is binnen S&o geen goede tool beschikbaar voor het vastleggen van wensen.

Planon De wijzigingen worden op Ad-Hoc basis gedaan. Indien er behoefte is aan een wijziging, gaat er een verzoek vanuit het FB richting de applicatiebeheerder bij ICTS, die het verzoek inplant en uitvoert. Kleinere wijzigingen kunnen door de functioneel beheerder binnen het FB zelf uitgevoerd worden. Van de uitgevoerde wijzigingen wordt geen administratie bijgehouden.

Voor het wijzigingenbeheer voor Planon is geen formele procedure afgestemd tussen het Facilitair Bedrijf en ICTS. Wel is er binnen het FB één persoon verantwoordelijk voor de wijzigingen, op dit moment Marc Hulshof.

4. Bijlage 2: Overzicht van gewenste verantwoordelijkheden en bevoegdheden in het wijzigingenproces

O Opdrachtgever/Stuurgroep FB Functioneel Beheer

AB Applicatie Beheer TB Technisch Beheer

E Eindgebruikers (Key-users)

Kenmerken: U Uitvoerend

V Verantwoordelijk


5. Bijlage 3: Voorstel voor onderzoek naar tool voor registratie gebruikerswensen.

In de werkgroep Wijzigingenbeheer & Contractmanagement is geïnventariseerd hoe wijzigingen in de instellingssystemen vastgelegd en bewaakt worden door de functioneel beheerders van de verschillende domeinen. De werkgroep heeft geconstateerd dat deze registratie op verschillende manieren gebeurt, bijvoorbeeld via notulen van overleggen, een eigen database of in een Excel-lijst. Deze registraties blijken echter niet afdoende of niet efficiënt en er is behoefte aan een tool voor het vastleggen van wensen/wijzigingen en het bewaken van de voortgang hiervan. De werkgroep adviseert om gebruik te gaan maken van een gezamenlijke tool voor het vastleggen en bewaken van wensen en wijzigingen voor de instellingssystemen. Een dergelijke tool is echter niet kant en klaar beschikbaar op de UT. De werkgroep adviseert daarom het I-beraad om een project op te nemen in het projectenportfolio 2013-2016 voor de selectie, aanschaf/ontwikkeling en invoering van een dergelijke tool en om vervolgens ICTS-ISA de opdracht te geven om een selectietraject te starten. Hierbij is het verstandig om naast een oriëntatie van standaard tools op de markt ook te onderzoeken of het servicedesksysteem van ICTS bruikbaar is en of de al bestaande HR database voor het vastleggen van wijzigingen verder ontwikkeld kan worden. De werkgroep adviseert om een werkgroep op te richten voor het uitwerken van de eisen waaraan de tool moet voldoen. Vanzelfsprekend zullen hier functioneel beheerders vanuit de verschillende domeinen bij betrokken moeten worden. Daarnaast zal de afdeling Inkoop betrokken moeten worden bij het selectietraject. Geadviseerd wordt om te steven naar implementatie van de tool in 2013 of 2014. Op dit moment kan nog geen indicatie geven van de benodigde interne uren van ICTS-ISA en functioneel beheer of van de out-of-pocket kosten die nodig zijn voor de uitvoering van dit project. Dit zal duidelijk moeten worden in een plan van aanpak voor het traject en is mede afhankelijk van de gekozen oplossing voor de tool.


6. Bijlage 4: Voorstel voor het maken van afspraken over instellingssystemen

Uit het overleg en de activiteiten van de werkgroepen bij het project “Professionalisering Functioneel Beheer” is naar voren gekomen dat goede afspraken van groot belang zijn voor het inrichten en beheren van informatiesystemen op de UT. Voor een deel worden deze afspraken gemaakt tussen de houders van informatiesystemen en leveranciers (zoals ICTS). Voor een goede samenwerking tussen de houders en leveranciers is het belangrijk dat deze afspraken op een zinvolle wijze worden vastgelegd in contracten. Een contract omvat de inhoud van de dienstverlening, de randvoorwaarden en condities waaronder deze geleverd wordt (Service Level Agreement cq. SLA), en de financiële afspraken tussen de contractanten. Deze afspraken zijn echter niet altijd (uniform) vastgelegd en er wordt niet of gebrekkig gemeten of voldaan wordt aan de afspraken zodat hierin bijgestuurd kan worden. De werkgroepen adviseren daarom om afspraken tussen houders en leveranciers eenduidig en op schrift vast te leggen, met een verschillende werkwijze voor interne leverancier ICTS en externe leveranciers

1. Dit

advies beperkt zich tot de afspraken tussen houders en ICTS. In detail ziet dit advies er als volgt uit: Doel contractbeheer informatiesystemen UT Voor eindgebruikers (studenten en medewerkers) borgen en verbeteren van het niveau van dienstverlening van instellingssystemen. Uitvoering Voor contracten tussen houder en ICTS:

Elk Functioneel Beheer domein (S&O, B&A, FEZ, HR, M&C, S&B, FB) verbindt zich aan een

resultaatverplichting om uiterlijk 1 januari 2013 voor ten minste één Instellingssysteem een

contract af te sluiten met leverancier ICTS. Het initiatief hiervoor ligt bij het domein

ICTS verbindt zich aan een resultaatverplichting om dit proces te begeleiden en te faciliteren, en te

zorgen voor deelname van ICTS medewerkers

Per contract moet nadrukkelijk aandacht zijn voor de meetbaarheid van afspraken, en regelmatig

voortgangsoverleg (minimaal 1x per kwartaal) opgenomen zijn waarin de meetresultaten besproken

worden en de dienstverlening (of afspraken!) bijgestuurd/bijgesteld wordt

De resultaten van dit proces worden in juni 2013 besproken in een gezamenlijk overleg van

houders, UIM en ICTS. Best practices voor de UT worden op basis van de resultaten vastgesteld, dit

moet onder andere leiden tot een generieke template voor een UT contract/SLA tussen een houder

van een Instellingssysteem en ICTS. Deze template zal ontwikkeld worden door ICTS en uiterlijk 1

oktober 2013 gereed zijn

Vanaf 1 oktober 2013 worden alle nieuwe contracten tussen ICTS en houders volgens deze template

afgesloten. Het initiatief hiervoor ligt bij ICTS

Elk Functioneel Beheer domein (S&O, B&A, FEZ, HR, M&C, S&B, FB) verbindt zich aan een

resultaatverplichting om uiterlijk 1 juli 2014 voor alle bestaande Instellingssystemen een contract af

te sluiten met leverancier ICTS volgens deze template. Het initiatief hiervoor ligt bij het domein

1 Noot: bij veel informatiesystemen op de UT zijn meerdere leveranciers betrokken. Meestal is

dit ICTS samen met een of meerdere externe leveranciers. In het project is geconstateerd dat de regie over de afstemming tussen leveranciers en houder daarbij soms onduidelijk is, wat weer leidt tot problemen in het beheer en de beschikbaarheid van het betreffende systeem.


ICTS verbindt zich aan een resultaatverplichting om dit proces te begeleiden en te faciliteren, en te

zorgen voor deelname van ICTS medewerkers

Voor contracten tussen UT en externe leveranciers:

Er wordt een eenduidige werkwijze vastgesteld tussen houders, UIM, ICTS en FB-Inkoop voor de

wijze waarop invulling gegeven wordt aan de behoefte voor een nieuw informatiesysteem

Elke behoefte voor een nieuw informatiesysteem wordt volgens deze werkwijze afgehandeld.

Onderdeel van de werkwijze is in ieder geval een onafhankelijk advies op de behoefte, van elk van

de betrokken partijen (houders, UIM, ICTS en FB-Inkoop)

In de werkwijze worden algemene afspraken gemaakt over de regie op de contacten tussen UT en

externe leveranciers tijdens het implementatietraject/project, indien besloten wordt tot de

aanschaf van een informatiesysteem bij een externe leverancier

In de werkwijze worden algemene afspraken gemaakt over de regie op de contacten tussen UT en

externe leveranciers, na het in beheer/productie nemen van het systeem


7. Bijlage 5: Overzicht van gewenste verantwoordelijkheden en bevoegdheden bij toetsen en testen

O Opdrachtgever/Stuurgroep

FB Functioneel Beheer AB Applicatie Beheer TB Technisch Beheer E Eindgebruikers (Key-users)

Kenmerken: U Uitvoerend

V Verantwoordelijk

8. Bijlage 6: Overzicht instellingsystemen, overlegvormen en contactpersonen


9. Bijlage 7: UFO functieomschrijving functioneel (informatie)beheer

10. Bijlage 8: Definities functioneel beheer, applicatiebeheer en technisch beheer

Omschrijving van functioneel beheer, applicatie beheer en technisch beheer.

Dit document beschrijft de drie vormen van beheer die op de Universiteit Twente

gebruikt worden bij het beheren en onderhouden van informatiesystemen. De drie

vormen zijn gebaseerd zijn op het boek “beheer van informatiesystemen”

(Looijen1997). De beheer definities zijn overgenomen uit het boek “BiSL, een

framework voor functioneel beheer en informatiemanagement” (Pols2005). Voor

enkele rollen (zoals de functioneel beheerder, opdrachtgever en projectleider) zijn

rolbeschrijvingen gedefinieerd die gebaseerd zijn op best practises vanuit de UT.

Functioneel beheer en informatiemanagement: Het functioneel beheer en informatiemanagement is namens de

gebruikersorganisatie verantwoordelijk voor het instandhouden en aansturen van de

informatievoorziening van een organisatie. Vanuit het perspectief van de

gebruikersorganisatie en het bedrijfsproces richt men zich daarbij op de

informatievoorziening die de organisatie en het bedrijfsproces ondersteunt.

Voorbeelden van functies zijn: functioneel beheerder, informatiemanager, systeemeigenaar

en informatieanalist.

De functioneel beheerder fungeert als gedelegeerd eigenaar en operationeel

opdrachtgever voor het informatiesysteem en beheert/coördineert de gegevens. De

functioneel beheerder gaat voortdurend na of de gebruikers wel alle mogelijkheden

benutten en of er aanpassingen nodig zijn. Bij vernieuwingen adviseert de

functioneel beheerder de opdrachtgever en/of projectleider over keuzes en invoering

en coördineert de operationele samenwerking met applicatie beheer en technisch

beheer. Tot dat werk behoren zaken als het organiseren van acceptatietests en

gebruikersopleidingen en zo nodig het maken van een gebruikershandleiding.


Applicatiebeheer: Het applicatiebeheer is verantwoordelijk voor de

instandhouding van de applicatieprogrammatuur en de gegevensbestanden. Onder

applicatieprogrammatuur wordt verstaan alle programmatuur die mede met behulp

van besturingsprogrammatuur, databasemanagementprogrammatuur en –

programmeermiddelen tot een informatiesysteem is ontwikkeld. Zodra wijzigingen

moeten worden aangebracht voor onderhoud, is het applicatiebeheer

verantwoordelijk voor het uitvoeren van die wijzigingen en het testen ervan. Dit geldt

eveneens voor de gegevensbanken ten aanzien van veranderingen in opslag en

plaats en gegevensbestandsstructuren. Applicatie architectuur en life cycle

management behoort tot het domein van applicatiebeheer. Voorbeelden van functies

zijn: programmeur, applicatiebeheerder, informatieanalist, databasebeheerder,

servicemanager en projectmanager.

De applicatiebeheerder draagt zorg voor een juiste werking en performance van

applicatiesoftware en database queries. Hij signaleert ontwikkelingen in de

gebruikersorganisatie en adviseert over updates/ontwikkelingen in programmatuur

of vervanging hiervan. Hij adviseert over de structuur van gegevensbestanden en de

wijze van vastlegging van informatie, vertaalt wensen van Functioneel

Beheer/Eindgebruikers naar specificaties voor programmatuur, en ontwikkelt en test

deze. De applicatiebeheerder ontwerpt en realiseert koppelingen met andere

systemen/gegevensbronnen en signaleert wanneer hierop wijzigingen nodig zijn. Bij

een samenspel van zelfgeschreven en ingekochte programmatuur coördineert hij de

afstemming tussen de software en tussen leveranciers.

Technisch beheer Het technisch beheer is verantwoordelijk voor de instandhouding van het

informatiesysteem, bestaande uit apparatuur, programmatuur en

gegevensverzamelingen, die vanuit het gebruik continu beschikbaar moeten zijn.

Vanuit deze algemene taakstelling richt het technisch beheer zich op alle aspecten

van het operationeel houden. Het bewaakt overeengekomen niveaus, speelt in op

afwijkingen en voert wijzigingen uit als gevolg van gebruikerswensen en

technologische ontwikkelingen. Technische architectuur en life cycle management

behoort tot het domein van technisch beheer. Technisch beheer komt overeen met

de functie van rekencentrum of ICTcentrum. Voorbeelden van functies zijn:

systeembeheerder, netwerkspecialist, databasebeheerder en servicemanager.

De technisch beheerder onderhoudt en configureert alle software en apparatuur die

nodig is om het informatiesysteem operationeel te houden. Hij controleert

voortdurend of het systeem voldoet aan de afspraken met de gebruikersorganisatie

en onderneemt actie als dit dreigt spaak te lopen. De technisch beheerder signaleert

ontwikkelingen in de gebruikte programmatuur en hardware, adviseert over

updates/upgrades in software of vervanging van apparatuur, en voert wijzigingen uit

in opdracht van de gebruikersorganisatie.

Eindgebruiker De eindgebruiker maakt gebruik van de diverse (informatie)systemen, waarbij de

toegangsrechten afhankelijk zijn van de rol die deze persoon heeft.

Opdrachtgever


De opdrachtgever is eindverantwoordelijke van de

informatiesystemen en geeft opdracht tot het verrichten van

de uit te voeren werkzaamheden.

Projectleider Voert uit, bewaakt en levert projecten op en stuurt interne medewerkers en/of derde

parten aan uitgaande van een projectplan, met dien verstande dat het project binnen

randvoorwaarden van kosten, kwaliteit, tijd, organisatie en communicatie wordt

gerealiseerd. De projectleider is een rol die zowel kan voorkomen bij functioneel

beheer, applicatiebeheer en/of technisch beheer.


11. Bijlage 9: Voorstel voor een functioneel beheer overleg

Gedurende het project “Professionalisering Functioneel Beheer” is door de deelnemers van de diverse domeinen/afdelingen (S&O, HR, FEZ, B&A, M&C, S&B, ICTS) het gezamenlijk overleg in de werkgroepen als zeer nuttig ervaren. Het horen van elkaars werkwijzen leidt tot nieuwe inzichten, onderlinge afstemming en een beter begrip voor elkaars problemen/activiteiten. De werkgroepen adviseren daarom om dit overleg na afronding van het project structureel te blijven voeren in de vorm van georganiseerde bijeenkomsten. In detail ziet dit advies er als volgt uit: Doel Bijeenkomsten Functioneel Beheer clusters Onderlinge afstemming tussen Functioneel Beheer clusters op de UT. Weet hebben van elkaars plannen (releases/wijzigingen op systemen en processen) en activiteiten, ervaringen uitwisselen en leren van elkaars successen en verbeterpunten, en zo mogelijk uniformeren van werkwijzen. Uitvoering Één keer per kwartaal wordt een bijeenkomst georganiseerd op een ochtend (09.00 – 13.00u) of een middag (13.00 – 17.00u)

Universitair Informatie Management organiseert de bijeenkomst en fungeert als secretaris

De rol van voorzitter rouleert onder de Functioneel beheer clusters

Deelname aan de bijeenkomst is open voor Functioneel Beheerders, UIM, en ICTS medewerkers die

op regelmatige basis te maken hebben met Functioneel Beheer clusters

Het algemene onderwerp van de bijeenkomsten is “De inrichting van het Functioneel Beheer op de

UT, en de interactie met leveranciers”

Om telkens zorg te dragen voor een zinvolle bijeenkomst wordt een agendacommissie

samengesteld die ruim voorafgaand aan elke bijeenkomst interessante

agendapunten/onderwerpen identificeert, zorgt dat het agendapunt voorbereid wordt en, indien

van toepassing, zorgdraagt voor sprekers. Deze commissie bestaat uit 4 à 5 personen van de diverse

FB-clusters, UIM en ICTS

Benodigde middelen Voor een zinvolle inrichting en uitvoering van de bijeenkomsten is het advies om de volgende middelen beschikbaar te stellen: Tijd voor Functioneel Beheerders om deel te kunnen nemen.

Gevraagd wordt ca. 2 dagen per FB’er per jaar

Hiernaast: tijd voor enkele personen voor deelname aan een agendacommissie.

Gevraagd wordt ca. 1 dag per persoon per jaar

Budget voor faciliterende zaken: zaalhuur, koffie/thee, externe sprekers.

Gevraagd wordt €5000,- ex. btw per jaar

De projectgroep heeft het plan opgevat om in september/oktober 2012 een laatste bijeenkomst te organiseren voor alle deelnemers aan het huidige project “Professionalisering Functioneel Beheer” en andere geïnteresseerden. Bij deze bijeenkomst zal het project voor de deelnemers formeel afgesloten worden en worden de resultaten van de 3 werkgroepen gepresenteerd. Tevens kan deze bijeenkomst dienen als start voor de bovengenoemde nieuwe overlegstructuur.


12. Bijlage 10: Inhoudelijke samenvatting van het project “professionaliseren functioneel beheer” (poster)

eindrapport professionaliseren functioneel beheer

Documents

Transcript of eindrapport professionaliseren functioneel beheer