IT Governance at Higher Education Institutes in Amsterdam

Transcriptie

1 Master Thesis - Information Studies IT Governance at Higher Education Institutes in Amsterdam T.M. van Bremen Student no.: Supervisor: drs. A.W. Abcouwer Case supervisor: Mw. S.W. Nolst Trenité Second reader: dr. T.M. van Engers 14 th August, 2014

2 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes IT Governance at Higher Education Institutes in Amsterdam Evaluating Business Process Requirements for Large-Scale Education Sector IT Governance and Change: A Case Study Student T.M. van Bremen University of Amsterdam bremen@uva.nl University Supervisor Dhr. drs. A.W. Abcouwer University of Amsterdam Case Supervisor Mw. S.W. Nolst Trenité University of Amsterdam Abstract. A case study was performed at the shared service units of two higher education institutes in Amsterdam. Their shared service departments were in the process of improving the governance of their IT systems. A major part in this process was the establishment of a list of requirements for the management of all of their information systems. The list was particularly aimed at the responsibilities and competences of system owners, a newly appointed role inside the organization, aiming to have one person responsible for the availability and quality of the information provision services that one information system should deliver. As part of the study, the current situation was benchmarked with regard to all requirements, to compare the current situation with its ideal counterpart. To do so, interviews with system owners and other employees were conducted, discussing all relevant requirements for their specific information system. Results indicated a poor to adequate fulfillment of the requirements, but a relatively high assessment of system owners intrinsic competences might prove vast improvement in the near future, even more so when more attention is given to guidance in the initial processes. Furthermore, an elaboration was made on the theme of change management, which concerns itself with keeping the system aligned with changing business processes and changing needs of the organization while maintaining the continuity of the information system. It was found that the organization, when the requirements are fulfilled, are able to adequately handle change management. Future work could investigate this, or replicate the same benchmark at a later point in time to investigate the development of the fulfillment of the requirements. Keywords. IT governance, business-it alignment, change management, IT decision making authority.

3 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes 1. Introduction The collaborating services of UvA and HvA 1 - consisting of the Administrative Center, Facility Services and the ICT Services department - have recently established new requirements on which the management of their information systems should be organized 2. The fulfillment of these requirements is the responsibility of the directors of each department and the IS owners appointed by them. The IS owner is the person responsible for the availability and quality of the information provision services his or her IS should deliver. The aim of the requirements is to increase the quality and availability of these information provision services. The first goal of this study is to compare the current situation at the shared services with an optimal situation where all requirements are met. This will be done using a fit-gap analysis based on interviews with system owners and other employees. The environment of the institutes is continuously changing, as is the reality for all organizations in all industries (Todnem By, 2005). To accommodate for this ever-changing environments, the organizations have to change with it. The institutes of this case study rely heavily on its information systems, with which they carry out numerous information provisioning tasks for thousands of students and employees. Therefore, if the organization wants to change, the information systems have to change too, which also counts for an increasing amount of organizations since the last two decades (Introna, 2007). The new requirements should allow for these changes by including requirements for changes in the information system, e.g. by requiring change management procedures, communication with end users, and the capability of system owners to implement the right changes. The second goal is therefore to come up with recommendations for this topic of change management, which is also one of the shared services main motivators for the establishment of the requirements, as stated in the introduction of the requirements document¹. This will include an analysis of the requirements from a change management perspective, laying bare its current role in the requirements, as well as exposing room for improvement on this topic. Research questions Based on the above-mentioned considerations, the following two research questions are proposed: RQ1: To what extent do the information provision services at the collaborating services of the two institutes fit the newly stated requirements? RQ2: To what degree do the requirements improve change management? 1 Universiteit van Amsterdam (academic level education); Hogeschool van Amsterdam (college level education) 2 Nolst Trenité, S. (2014). Uitgangspunten beheer informatiesystemen samenwerkende diensten. Amsterdam. See Appendix B. University of Amsterdam 2

4 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Approach The first research question was answered by discussing all newly stated requirements with the relevant people in the organization. These people were system owners and business process managers. The questions were designed in such a way that the current fulfillment of the requirements for a specific information system could be derived from its answers. The answers were rated on a Likert-scale ranging from 1-5, not unlike many other maturity models. This rating scale was based on the availability of certain required documents, whether those documents were validated, but most of all it was based on the system owners own assessments. The research field of the first question is depicted in Figure 1. It shows how the University van Amsterdam (UvA) and Hogeschool van Amsterdam share service units which have information systems in use, which are managed by system owners. The system owners should strive do this according to the newly stated requirements. The optimal situation is where all requirements are fulfilled. In practice, this is not the case. Research question 1 is aimed to measure the current fulfillment of the requirements. Figure 1. Conceptual model of part one of study The second research question regards the relation of the requirements and the change management that is required to ensure the continuity of all information provision services while working in an ever-changing environment. This research question was answered by comparing the requirements with popular change management requirements or competences stated in earlier scientific work. The extent to which they overlap or not showed a good representation of change management in the requirements, or in case of no overlap, it showed room for improvement on the subject of change management. Figure 2. Conceptual model of part two of this study University of Amsterdam 3

5 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Case study background: The shared services The case study conducted in this study took place at, and in collaboration with, the shared service departments of the University of Amsterdam and the Hogeschool van Amsterdam, mainly located at the HvA-building Leeuwenburg. Shared services (or collaborating services ) is merely an umbrella term used only in this paper for better readability. The services are made up of the Administrative Center, Facility Services, ICT Services, and its upper management levels up to the board of directors. The case study location: Leeuwenburg in Amsterdam Contents To answer the research questions, first the Theoretical background will be discussed. The Research method will be described, after which the Requirements are explained. Resulting from the applied method, the Results are shown, followed by the Discussion where those results are analyzed and the research questions answered. The paper will end with a Conclusion. 2. Theoretical background In this section several research fields are linked with the research topics of this paper. The requirements are seen as an implementation of IT governance, therefore the section starts with an elaboration on this topic. After that, change management will be discussed, to discover common practices of applying change management on a system management level. Related to change management, the concept of skill and competency requirements for IT management will be analyzed, an analysis which is later used to compare with the requirements of the institutes. Lastly, the research methods of this study are linked to literature, which is done in its relevant chapter: Research method. IT Governance Webb et al. tried to merge several diverse views of IT governance into one definition, and at the end of their study the following definition remained: IT Governance is the strategic alignment of IT with the business such that maximum business value is achieved through the development and maintenance of effective IT control and accountability, performance management and risk management (Webb, Pollard, & Ridley, 2006, p. 2) When comparing this definition with the topic of this study, one can clearly link the requirements to the effective IT control and accountability -part. According to Webb et al, control and accountability are even the main factors which differ between IT governance and basic strategic information systems planning. Furthermore, the IT specialization of these factors is what differentiates IT governance from corporate governance (Webb et al., 2006, p. 5), justly categorizing this study in the IT Governance domain. University of Amsterdam 4

6 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Broadbent (2002) states that IT governance is not about IT management and the detail of particular IT decisions and their implementations, but more about the arrangements for who makes critical decisions and who is accountable for them (Broadbent, 2002, p. 2). By clarifying who is able to make critical decisions and who is accountable for them, organizations are better able to deal with complexity. Broadbent further states that IT governance specifies the decision rights and accountability framework to encourage desirable behavior in the use of IT (Broadbent, 2002, p. 1), which is exactly what the shared services are trying to accomplish with these requirements. The requirements state several decision rights allocations, and states where accountabilities lie for various aspects of the governance of an IS, e.g. for application management, communication, or contracts and SLAs. Weill and Ross (2004) separate five types of IT decisions: IT principles: Clarifying the business role of IT IT architecture: Defining integration and standardization requirements IT infrastructure: Determining shared and enabling services Business application needs: Specifying the business need for purchased or internally developed IT applications IT investment and prioritization: Choosing which initiatives to fund and how much to spend The introduction of system owners could be seen as a centralization of IT decision rights of these types of decisions, i.e. all managerial decisions concerning the IS now fall under the responsibility of one and the same system owner, instead of being divided over all the different managerial layers. Such centralization may lead to increased organization efficiency (Bester, 2009). Aghion and Tirole found that centralization may jeopardize communication by making the agent concerned about being overruled, although it can also favor communication when the agent trusts his superior (1997). Robinson and Stocken (2013) suggest that the costs of inappropriately centralizing decision rights are lower than the costs of inappropriately decentralizing decision rights (Robinson & Stocken, 2013). While this study is not aimed potential costs of the centralization versus a decentralization, the abovementioned statements will be taken into consideration in this study. CobiT 3 is a framework proposed by the Information Systems Audit and Control Association 4. CobiT an international and generally accepted IT control framework enabling organizations to implement an IT Governance structure throughout the enterprise. Guldentops (2004) wrote on CobiT s definition of key performance indicators, and summarized them as such: Are measures of how well the process is performing Predict the probability of success or failure in the future, i.e., are lead indicators Are process-oriented, but IT-driven Focus on the process and learning dimensions of the Balanced Business Scorecard 3 Control Objectives for Information and related Technology 4 University of Amsterdam 5

7 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Are expressed in precisely measurable terms Help in improving the IT process when measured and acted upon Focus on those resources identified as the most important for this process The requirements of the shared services are similar to these indicators. The requirements serve as measures of how well the information provision process of an information system is performing. When fulfilled, it should predict the probability of success or failure. The requirements are not expressed in precisely measurable terms, but that is what this study aims to aid in. They requirements certainly help in improving the IT process when measured and acted upon, as is the case with CobiT s key performance indicators. Change management Change management has been defined as the process of continually renewing an organization s direction, structure, and capabilities to serve the ever-changing needs of external and internal customers (Moran & Brightman, 2000). For this study change management applies to the information systems, its employees, (at the shared services as well as scattered over the different faculties and departments), IT contractors and all the students. When looking at the subject of change management and necessary skills, Jiang, Klein & Margulis ranked 18 behavioral skills (originally developed for system analysts by Green (1989)) based on their importance for success of an IS project (Jiang, James J., Klein, Gary, Margulis, 1998). The highest ranked skills were 1) interviewing, 2) directing, 3) managing, 4) speaking and 5) listening. The top ten highest ranked skills are depicted in Table 1. Later in this paper these will be compared with the requirements of the shared services. Rank Skill Description 1 Interviewing Asking the right questions in order to obtain the information needed. 2 Directing Giving instructions and communicating user requirements to programming and support staff. 3 Managing Planning, organizing and controlling projects. 4 Speaking 5 Listening 6 Writing Presenting your ideas in a manner easily understood by your audience, both in group meetings and person to person. Paying attention to and concentrating on what is being said, and asking questions that refine points about which one is uncertain. Preparing written documents that accurately communicate ideas in a manner easily understood by intended readers. 7 Cooperation Working with others productively 8 Patience 9 Leadership Continually refining user requirements by requesting feedback; tolerating lack of computer literacy and specificity. Getting work done while keeping the team satisfied; effectively giving rewards and punishment. 10 Sensitivity Being aware of implications to the community Table 1. Behavioral skills (Jiang, James J., Klein, Gary, Margulis, 1998) University of Amsterdam 6

8 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Harison & Boonstra (2009) used the work of Jiang et al. (1998), Paré & Jutras (2004) Kendra and Taplin (2004) and Meredith and Mantel (2011) several others to derive a taxonomy of competences related to technochange processes. Technochange management is a change management form where the changes are initiated by technology, e.g. technological developments that allow for new possibilities. They validated this taxonomy by discussing them with experienced IT project managers. This method resulted in an adapted set of the taxonomy, which the researchers transposed to an assessment model, which is depicted in Table 2. This set of competences will be used together with the aforementioned behavioral skills to compare the requirements of the shared services with. Competence Information technology and information systems (IS/IT) know-how Organizational Change Technochange Risk and success factors Communication Process management Leadership Consequences of change Description Actual knowledge of the IS/IT field and experience in IS/IT projects in leading and responsible positions Knowledge of the field of organizational change and organizational development and experience in OC/OD projects in leading and responsible positions. Understanding of organizations in their context Knowledge of the process of IT-related organizational change and insight into the implications of such change for organizations. Experience in technochange projects in leading and responsible positions. Insight into essential risks and success factors of technochange. Experienced in using these factors during technochange projects. Able and experienced in conducting interviews, writing reports, present findings, listening, motivate and convince people Capable of and experienced in planning, managing and evaluation the process of IT-related organizational change Experience in directing and leading IT and organizational change projects. Able to provide direction, to facilitate and to advise managements, project employees and others with regard to the project. Empathic, diplomatic and skillful in organizational politics Able to recognize and anticipate consequences of technochange programmes Table 2. Assessment scales of technochange managers (Harison & Boonstra, 2009) Several reasons exist to implement change management in the requirements. Todnem By (2005) stated that there is a clear consensus that the pace of change has never been greater than in the current continuously evolving business environment. Therefore, the successful management of change is a highly required skill. However, the management of organizational change currently tends to be reactive, discontinuous and ad hoc with a reported failure rate of around 70 per cent of all change programmes initiated (Balogun and Hope Hailey, 2004). To counter this, the requirements should be able to transform change management into a transparent, well-managed matter, which each system owner is able to deal with. The set of requirements and its topics were constructed in a practical setting, rather than based on a scientific foundation. Theoretical background of the requirement themes and similarities can be found, however. Although a thorough analysis and critical evaluation of the requirements themselves is regarded out-of-scope for this study, some theoretical background is mentioned below. A more thorough analysis and critical evaluation could be interesting for future work for both education institutes, as it was not chosen as a part of this study. University of Amsterdam 7

9 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes A theoretical framework on which the requirements are partly based is represented by the use of the Business Information Services Library, or BiSL 5. This framework is aimed to aid organizations in their business process management and information management (Outvorst & van der Pols, 2005). It separates three management domains in an organization s IT: Technical management Application management Business process management 6 The requirements show strong ties with these departments and BiSL in general. For example, all R.4.2.x requirements are derived from the framework, most of them relating to the business process management layer, which steers the other layers. This strong connection is caused by the fact that the collaborating services would like their business process designed according to the BiSL framework. Use of a fit-gap analysis. As mentioned in the introduction, this study will contain a fit-gap analysis (Jennings, 2000). A fit-gap analysis is used to evaluate business processes achieving a specific goal. People conduct a gap analysis to compare actual performance with desired performance. The first part consists of analyzing the current situation. Then, desired outcomes are compared to the current levels to determine the gap. This technique is used in business improvement processes to identify potential problem areas where improvement is necessary, i.e. the gaps. Fit-gap analyses are usually requested when processes are not producing desired results or in this case: when fundamental changes are implemented and the organization wants to know to what extent the current situation relates to the desired outcome of the implemented changes. The steps of a fit-gap analysis are as follows 7 : 1. Identifying Current Performance 2. Identifying Desired Performance and Gap 3. Addressing the Gap This study will focus on step 1 and step 2, and within reach come up with recommendations for addressing the gaps in practice (step 3). The actual addressing of the gaps in practice, however, is left to the shared services themselves Functioneel beheer in Dutch, according to Outvorst & van der Pols (2005) 7 University of Amsterdam 8

10 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes 3. Research Method The practical part of the study consisted of a fit-gap analysis based on interviews with system owners, to investigate to what extent the current situation at the shared services fits the new requirements. For this practical part of this study, e.g. the fit-gap analysis and the interviews, the defined requirements (Appendix B) were regarded as as-is, therefore being fixed and undebatable. The managerial situation regarding the information system was be analyzed using this static set of requirements. Investigated information systems A subset of 17 systems has been analyzed. This was well in line with the preset goal of between 15 and 20 systems. The number of systems was evenly divided over the departments: six belonged to Facility Services, six to the ICT Services and five to the Administrative Center. The specific to be investigated information systems were selected by the case supervisor. A total number of thirteen people were interviewed, of which seven were system owner and five were business process manager 8. In total 15 interviews were held, meaning that in some multiple systems were discussed, and some people were interviewed on multiple occasions due to a need for more time. Detailed information on the interviews is depicted in Table 3. ID Date Time Role Department Duration I :00-11:00 SE FS 01:00:34 I1(cont.) :30-14:00 SE FS 00:27:34 I :00-14:00 SE FS 00:43:14 I :00-14:00 SE AC 00:43:22 I :00-14:00 SE ICTS 00:45:52 I :00-10:30 FB FS 00:26:50 I :30-15:00 FB ICTS 00:20:37 I :00-12:00 SE AC 00:48:37 I :30-09:30 SE ICTS 00:35:16 I :00-12:00 SE ICTS 00:45:22 I :00-16:00 SE AC 00:56:36 I :00-10:30 TC FS 00:41:05 I :00-11:30 FB ICTS 00:14:37 I :00-11:00 FB FS 00:23:50 I :00-12:00 SE ICTS 00:15:59 I :00-11:00 SE ICTS 00:30:56 Table 3. Interview data and reference IDs Interviews The requirements were transposed into interview questions that were used to question employees serving the information provision services. To illustrate this, Table 4 shows a requirement, and Table 5 depicts the questions asked to determine the current fulfilment of that requirement. 8 Functioneel beheerder in Dutch, according to Outvorst & van der Pols (2005) University of Amsterdam 9

11 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes In the example requirement 3.2 is translated to interview questions. All original requirements are stated list in Uitgangspunten beheer informatiesystemen samenwerkende diensten 9, which is included in Appendix B. A translated version can be found in the chapter Requirements, and a shortened and translated list can be found in Appendix A. Responsibility for governance of the IS [R3.2] Responsible for the complete chain of the daily management of the IS, from business information management to hosting and housing, including the education of relevant employees (excluding education of end users). Table 4. Example requirement (1 of 51 requirements) Example responsibility complete chain (translated) [R3.2.1] As system owner, you are now responsible for the complete chain of the daily management of your IS, from business information management to hosting and housing, including the education of relevant employees (excluding education of end users). Do you experience this responsibility in practice? Are you able to bear this responsibility? (please indicate on a scale of 1 to 10) If not, what would you need to be able to do so? Table 5. Interview questions for the requirement depicted in Table 2. Interview procedure The interviews happened only after an appointment had been made a week beforehand, so the list of questions could be sent them two days prior to the interview, so the interviewee would know what to expect and be well prepared, since it was a comprehensive list of questions. Each interview started off with a brief introduction, introducing and telling the interviewee about the research and the requirements, as strongly suggested by Tulder (2012, p.159). It was emphasized that the interview should not be regarded as a personal evaluation. Before the actual questioning part started, the interviewee was asked if he or she would object to the interview being recorded on audio, and notified that the potential recordings would be deleted after the research had been fully completed. At the end of the interview they were asked whether they would like the transcriptions to be sent them, to read through or potentially request revisions. Grounded theory The interviews were conducted using a grounded theory approach to provide a less biased way of questioning (Glaser & Strauss, 1967). By consistently asking the same questions to each system owner this should provide clear results that gives the ability to conduct a good comparison between the various systems. 9 Nolst Trenité, S. (2014). Uitgangspunten beheer informatiesystemen samenwerkende diensten. Vasa. Amsterdam. University of Amsterdam 10

12 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Furthermore, grounded theory concerns itself with the analysis of the interview answers, using the concept of coding. This is merely the process of assigning the interview answers to categories, to allow for further analysis and comparisons between interviews, e.g. by combining answers from two interviewees that made the same argument but used different wording. Glaser and Strauss differentiate three types of coding: open, axial and selective. They vary, as the names imply, from a very open approach to the creation of categories, to the derivation of sub-categories, based on a known core category. While the method of this study, mainly because of the use of the predefined requirements, did not allow for open or axial coding, it did allow for selective coding, using the requirement categories as the starting point (Corbin & Strauss, 1990). Grounded theory has also been criticized. Critics are concerned about the prerequisite of a lack of preconceived ideas when conducting research. An approach which is deemed nearly impossible because there is always some agenda for research by interview, otherwise nobody would spend resources on it (Allan, 2003). Another criticism stated by Allan is the lack of clear guidelines for the coding process, mainly on what to code and what not to code, and when to decide the coding process has ended. To counter these points, this study 1) focused more on the reproducibility of the study by consequently asking the same questions in the interviews, and 2) applied the coding process in the analysis part after the conducted interviews, making it possible to abstract similar answers into general conclusions. Fit-gap analysis The answers to the interview questions and all the relevant evidence (notes, documents, contracts) were gathered and summarized in tables. This was done to provide a clear overview of the current situation of the specific information provision service. Figure 3 illustrates this by depicting the table for information system 1. While the results are not readable in this form, it does show the previously mentioned overview. For the full details on the results, one should consult Appendix E. In order to determine fits and gaps, every requirement was discussed in the interviews. The full list of questions can be found (in Dutch) in Appendix C Interview Protocol. University of Amsterdam 11

13 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes ID Name Fuction Owner IS1 Name Kaartmanagementsysteem Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwali teitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten R3.1.2 Architectuurplaat Ja Ja 5 Beschikbaar. Gevalideerd. R3.1.3 Informatie over betrokkenen Nee Nee 1 subsysteem gevalideerd. Totaal 1 3 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 3 3 R3.2.2 Belegging rollen 4 4 R3.2.3 Escalatieschema s Nee 2 2 R3.2.4 Crisisplan Nee R3.2.5 Updates en upgrades Nee 2 2 Totaal 3 5 Applicatiebeheer uitbesteed aan ICTS. De rest van de verantwoordelijkheid goed te dragen. Externe partijen zijn erbij betrokken. Per systeem verschilt het of er contracten zijn of niet. Scholing is niet gestructureerd geregeld. Verschil in kennisniveau. Basiskwalificatie. Wel opleiding, geen verplichtingen. Rollen zijn helder belegd. Splitsing tussen funct ioneel en applicatiebeheer expliciet. Niet vastgelegd. Wel voor incident- en probleemmanagement, wijziging- en configuratiebeheer. Er zijn escalatieschema's bekend, maar niet vastgelegd, wel in gebruik. Crisisplannen zijn er en gedocumenteerd. Echter is dit niet bekend in alle lagen van de beheerorganisatie. FB: Crises deels binnen het systeem afgevangen. Regulier worden er updates en upgrades gedaan. Soms is dit vastgelegd in een releaseplan, maar dit is bij sommige systemen niet nodig. R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 2 2 R3.3.2 Regie wijzigingsbeheer Nee 3 3 R3.3.3 Afspraken wijzigingsbeheer Nee 3 3 R3.3.4 Afpraken met relevante SE'en Nee 3 3 R3.3.5 Afspraken met andere eenheden 2 2 Totaal 3 5 Éénmaal per kwartaal overleg tussen FB'er en leveranciers diensten. Niet door SE'er. Zo veel mogelijk volgens BiSL. SE direct betrokken. Wijzigingen worden overlegd. SE gaat uiteindelijk over alle wijzigingen. Overleg met FB-groep, applicatiecoördinator en evt. leveranciers. Afspraken bestaan informeel en gebeuren incidenteel, maar ze zijn er wel. Niet voor alle systemen. Capaciteitsprobleem. R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call -routering Ja 4 4 R3.4.2 Communicatieprotocol Nee 3 3 R3.4.3 Onderhoudsplannen Nee 3 3 Totaal 3 3 Call-routering is vastgelegd, ook in een document. Deze is bekend bij gebruikers, echter gaan sommigen direct naar de afdeling i.p.v. Servicedesk. Qua efficientie krijgt de call-routering een 8. Geen standaardplan. Er wordt wel gecommuniceerd, maar per issue. Niets is vastgelegd. Het meeste gaat via afdeling communicatie. Er zijn onderhoudsplannen, maar niet voor alle systemen. Deze zijn gedocumenteerd en alleen in te zien door systeembeheerder en Koen (coördinatie functioneel beheer) R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 beheer. Apart begroot. R3.5.4 Voldoende beschikbaar Budget 2 2 Capaciteit niet. R3.5.5 Voldoende deskundig personeel 2 2 R3.5.6 Toegang netwerk systeemeigenaren 4 4 R3.5.7 Invloed werkzaamheden maar als het belangrijker is -> SE. met studenten. R3.5.8 Noodzakelijke communicatiekanalen 4 4 wel gebruik van maken. R3.5.9 Advies centrale informatiemanagers 3 3 betreft het gebruik van een pas. R Geschoolde gebruikers 4 4 Totaal 4 10 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt van alle nieuwe ontwikkelingen. R3.6.1 Betrokkenheid innovatie 3 3 werkplekken. R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten 3 3 Totaal 3 3 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 3 3 R4.1.2 Invulling applicatiecoördinatie 4 4 R4.1.3 Beheerlagen als diensten 3 3 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 2 2 Totaal 3 4 Rollen zijn gescheiden, alleen applicatie en technisch beheer zijn samen. Host ing kan binnenshuis of erbuiten zijn, dit verschilt per systeem. Erg afhankelijk van externe partij wanneer een laag is uitbesteed. Applicatiebeheer is niet uitbesteed, coördinatie ligt bij ICTS. Technisch en applicatiebeheer is belegd bij ICTS. Soms ook hosting, dit ligt er aan om welk systeem het gaat. Nee, ligt bij ICTS. Hosting en KMS is extern. Verantwoordelijk voor uitvoering van contract. R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Ja. Meerdere mensen die FB uitvoeren. R4.2.2 FB ingericht volgens BiSL 5 5 Ja, destijds geïmplementeerd door Sanne. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 4 4 Ja. Mag wel minder uitvoerend (-> R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 huismeest ertaken). Zit een coördinator tussen. Wel direct R4.2.5 Afstand functioneel beheer en systeemeigenaar 4 4 contact en leidinggevende. Intern belegd. Kunnen elkaars rollen overnemen. FB: Uitgangspunt is dat iedereen alles zou moeten kunnen, dat is nu voor ong. R4.2.6 Vervanging functioneel beheerder % gerealiseerd. KMS kan iedereen. Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt R4.2.7 Rolbelegging functioneel beheerder 2 2 te weinig. Belegd bij ICTS. FB: Ook applicatiebeheer. R4.2.8 Geen applicatiebeheer of technisch beheer Soms technisch beheer. Niet benoemd. Input users puur via eventuele R4.2.9 Key-users benoemd individuele calls. Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel R Afstemming operationele BiSL processen met key-users 3 3 gecommuniceerd met die gebruikers. R Key-users/decentraal FB'er onderdeel functioneel beheer 3 3 Geen decentrale belegging. Ja, maandelijks. Ook met R Overleg SE met FB'er applicatiebeheerder. Totaal 12 4 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 2 2 R4.3.4 ICTS verantwoordelijk voor contractmanagement 3 3 R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Totaal 6 3 Totaal R Alle uitgangspunten 51 3 Ja, is sturend. ICTS naar aanleiding van wens, wijziging of probleem aan tafel met leverancier. Dit gaat op initiatief van FB. Applicatiebeheer neem niet onafhankelijk van FB besluiten. FB: Meest al wel, maar technisch beheer heeft ook zijn eigen agenda. Niet verantwoordelijk voor dienst en belegd bij ICTS. Wel verantwoordelijk. Overeenkomsten niet vastgelegd. Contracten liggen bij beide (FS en ICTS). Capaciteitsprobleem ICTS. Afspraken zijn er wel, maar niet vastgelegd. In verhouding met capaciteit wordt er redelijk aan de afspraken voldaan. Figure 3. Gap analysis for one information system. Quality Assessment The fulfilment of the requirements was measured using a Likert scale ranging from 1 (very poor) to 5 (very good). This quality assessment was based on several aspects: the interview answers, whether a required document was available, whether that document was validated, and the general consensus gathered from an answer. For certain requirements, the interviewee was asked to rate the fulfilment of the requirement himself, e.g. on a scale of 1 to 10. This 1-10 point scale was initially the Likert-scale used for the analysis. For replicability reasons (ten categories proved to be too much to separate from each other) this was later recoded into a 5-point Likert scale. University of Amsterdam 12

14 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes The self-assessment scale would later be recoded to fit the new Likert scale. In Table 6, the assessment method is described in detail. Result Assessment Likert scale Label Interview answer Document* Validation* 1 Very poor No knowledge Unavailable Not validated 2 3 Poor No knowledge Available Not validated Poor knowledge Unavailable Not validated Adequately Poor Knowledge Available Validated No knowledge Available Not validated 4 Good Good knowledge Available Not validated 5 Very good Good knowledge Available Validated *If the requirement mentions a document. Table 6. Quality assessment method Documenting results The answers to the interview questions were documented in transcripts of the interviews. For every information system every requirement is handled and its fulfillment assessed. All the results were documented in spreadsheets, of which a small part is depicted in Table 7. First the requirements are listed using their IDs and descriptions. Next, the availability of required documents is stated, along with a possible validated state of each document. The next two columns describe the system owner s judgement of each requirement, optionally along with that of the business information manager. The next column depicts the assessed quality of the fulfilment of the requirement. The last column provides a summarization of the answers given in the interviews, which provided the basis for the quality assessment in the preceding column. Requirements ID Description Beschikbaar Gevalideerd Beoordeling Schaal/grada tie/kwaliteits inschatting Verantwoordelijk heid basisinformatie Likert 1-5 R3.1 Basisinformatie System owner BPM R Toelichting Lijst IV-diensten en gebruikers Nee Nee 1 Toegezegd. Niet gevalideerd. R Architectuurplaat Ja Ja 5 Beschikbaar. Gevalideerd. R Informatie over betrokkenen Nee Nee 1 Totaal 1 Table 7. Method of documenting results fit-gap analysis. Leveranciers per systeem. Niet voor elk subsysteem gevalideerd. University of Amsterdam 13

15 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes 4. Requirements The shared services divide their set of requirements in two parts: the first part consists of responsibilities of the system owner and the second of requirements for the management of the information systems. The requirements are further divided into different chapters, which can be regarded as different categories. All requirements are depicted below. The original requirements, as stated by the collaborating services, can be found in Appendix B. Responsibilities of the system owner These requirements apply to every system owner to every information system they own, in a one-to-one matter. This means that these requirements have to be fulfilled for every information system in use, no matter who the system owner is Responsibility for basic information The first chapter provides for basic information of the information system, particularly aimed to provide a clear overview of the system and from an outside perspective, e.g. for higher (information) management, IT architects, or the board of directors. It also helps improving flexibility by aiding in transferability of management due to the centralization of information in an explicit form, as opposed to the decentralized presence of implicit knowledge at every system owner and their team. To provide for the basic information, the requirements request the presence of a list of information provision services and its users [R.3.1.1], architectural model [R3.1.2], information on involved parties [R3.1.3] Responsibility for management of IS Responsibility for the complete chain of management [R.3.2.1], role allocation [R.3.2.2], escalation scenarios [R3.2.3], crisis plans [R3.2.4], updates and upgrades management [R3.2.5] Responsibility for alignment and agreements with other parties Alignment with user organisation [R3.3.1], control over change management [R3.3.2], agreements with the user organization on the way the system owner controls change management [R3.3.3]. Alignment with system owners of other information systems which have interfaces with the IS [R3.3.4]. Written agreements with other units when the management is distributed [R3.3.5] Responsibility for the communication with end users The availability of call-routing schematics [R3.4.1], communication protocol for the communication with end users [R3.4.2]. The existence and publication of maintenance plans [R3.4.1] Conditions for quality fulfilment of system ownership Basic knowledge of information management, systems and architecture [R ]. Relation with the higher level i-governance and information provision project portfolio management [R3.5.3]. Whether budget suffices [R3.5.4]. Whether there are sufficient skilled employees [R3.5.5]. Access to the network of system owners [R3.5.6]. Influence on daily work of management layers [R3.5.7]. Available communication channels [R3.5.8]. Advice from central information managers [R3.5.9]. Education of end users [R3.5.10]. University of Amsterdam 14

16 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Other activities Involvement in innovation of information system [R3.6.1]. Alignment central information management [R3.6.2]. Involvement with contracts and SLAs [R3.6.3]. Requirements for management of information systems General requirements Division of management of information system in predefined layers of functional management, application coordination, application management, technical management and hosting and housing [R4.1.1]. Application coordination [R4.1.2]. Whether the different layers should be offered to the system owners as services by the different relevant departments [R4.1.3]. However the system owner remains responsible for all layers [R4.1.4] Business process management Business process management is done internally [R4.2.1], designed according to BiSL [R4.2.2], which is short for Business Information Services library, a framework for business process and information management. System owner is part of the controlling part of business information management layer [R4.2.3]. Business information managers are working on an operational level [R4.2.4]. Business process managers are placed as close to the system owner as possible [R4.2.5]. Replacement of business information manager(s) [R4.2.6]. Business information managers have an advising role [R4.2.7]. Role of business information manager. No application or technical management [R4.2.8]. Appointment of key-users depending on the need for key-users of the IS [R4.2.9]. Alignment of operational processes with keyusers [R4.2.10]. Key-users part of business process management [R4.2.11]. Regular meetings with business process management with a frequency that corresponds with the dynamicity of the IS [R4.2.12] Requirements regarding other management layers Business process management controls the other layers [R4.3.1]. The other layers are managed by ICT Services [R4.3.2]. The system owner is responsible for the service level contracts and SLAs [R4.3.3]. ICT Services handles all contracts and involves all relevant system owners [R4.3.4]. Application coordination [R4.3.5]. ICT Services takes care in providing sufficient available and qualified application management, technical management and hosting and housing to fulfil demands of the system owner [R4.3.6]. University of Amsterdam 15

17 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes 5. Results Requirements IS1 IS2 IS3 IS4 IS5 IS6 IS7 IS8 IS9 IS10 IS11 IS12 IS13 IS14 IS15 IS16 IS16 Totalen ID Description Name Name Name GBS-LWB (HvA) Name GBS-KMH (HvA) Name Name Name Name Name Name Name Name Name Name Name Gemiddelde Mediaan 0,25 0,75 R3 Verantwoordelijkheid basisinformatie R3.1 Responsibility for basic information R3.1.1 List of information provision services and its users , R3.1.2 Architectural model , ,25 R3.1.3 Information on involved parties , Total , ,25 R3.2 Responsibility for management of IS R3.2.1 Responsibility for the complete chain of management , R3.2.2 Role allocation , R3.2.3 Escalation scenarios , ,75 R3.2.4 Crisis plans , ,25 R3.2.5 Update and upgrade management , Total 2,5 2 2,5 2,5 4 3, ,4 2,5 1 3,75 R3.3 Responsibility for alignment and agreements with other parties R3.3.1 Alignment with user organisation , R3.3.2 Control over change management , ,25 R3.3.3 Agreements with user organization on control over change management , R3.3.4 Alignment with systemowners of other information systems which have interfaces with the 3 IS , ,25 R3.3.5 Written agreements with other units when the management is distributed , Total , ,25 R3.4 Responsibility for the communication with end users R3.4.1 Call-routing schematics ,0 3,5 1,5 4 R3.4.2 Communication protocol for the communication with end users , R3.4.3 Maintenance plans , ,25 Total , ,5 1, ,5 2,5 1,5 3 R3.5 Conditions for quality fulfilment of systemownership R3.5.1 Basic knowledge of information management and systems , R3.5.2 Basic knowledge of architecture , R3.5.3 Relation with the higher level i-governance and information provision project portfolio management , R3.5.4 Budget control , R3.5.5 Skill employees , R3.5.6 Access to the network of systemowners , R3.5.7 Influence on daily work of management layers , ,5 R3.5.8 Available communication channels , R3.5.9 Advice fromcentral information managers , R Education of end users , Total ,5 1, ,3 4 2,5 4 R3.6 Other activities R3.6.1 Involvement in innovation of information system , R3.6.2 Alignment central information management , R3.6.3 Involvement with contracts and SLAs , ,25 Total , Total R , ,25 R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 General requirements R4.1.1 Division of management of information systemin predefined layers of functional management, 3 application coordination, 3 application management, 3 technical management 2 and hosting and 2 housing , R4.1.2 Application coordination ,2 1,5 1 3 R4.1.3 Different layers are offered to the systemowners as services by the different relevant departments , ,25 R4.1.4 Systemowner responsible for all layers , Total ,5 2 3,5 3 2,5 2, , ,75 R4.2 Business process management requirements R4.2.1 Business process management is done internally , R4.2.2 Business process management designed according to BiSL , R4.2.3 Systemowner is part of the controlling part of business information management layer ,8 3 1,5 3,75 R4.2.4 Business process managers are working on an operational level , ,5 R4.2.5 Business process managers are placed as close to the systemowner as possible , R4.2.6 Replacement of business information manager(s) , R4.2.7 Business information managers have an advising role , R4.2.8 Business process managers do not performapplication or technical management , ,5 R4.2.9 Appointment of key-users depending on the need for key-users of the IS , R Alignment of operational processes with key-users , ,5 R Key-users part of business process management , R Regular meetings with business process management with a frequency that corresponds with 4 the dynamicity of the 4 IS , ,25 Total , , , R4.3 Requirements regarding other management layers R4.3.1 Business process management controls the other layers ,0 3 1,5 4 R4.3.2 The other layers are managed by ICT Services , R4.3.3 The systemowner is responsible for the service level contracts and SLAs , R4.3.4 ICT Services handles all contracts and involves all relevant system owners ,3 1,5 1 3,25 R4.3.5 ICT Services takes care in providing sufficient available and qualified application management, 3 technical management 3 and hosting and housing 3 to fulfil demands of 3 the systemowner , Total ,5 2,3 1 3 R ,5 3 2, ,3 2,5 1 3 R , , Alle uitgangspunten , Figure 4. Result table - All investigated systems University of Amsterdam 16

18 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Measurements The results are summarized in Table 8. These are the quality assessments of the fulfilment of each requirement, based on the conducted interviews. The requirements are grouped under their category and depicted by their median and interquartile range, which are derived from the answers to the questions belonging to each (sub-)requirement (see Appendix C - Interview Protocol for the full list of questions (in Dutch)). These statistics were chosen because the Likert-scale is an ordinal scale, so the calculations of the means would not be valid (Jamieson, 2004). The median depicts the mostly given rating to a requirement and the IQR gives insight into the spread of the values by showing the value at the 1 st and 3 rd quartile (when all values are ranked in order). For the sake of readability the results are grouped by system owners, rather than by the 17 investigated systems. These detailed results per system can be found in Appendix E. Furthermore, the results indicated that the results per systems of the same system owner did not differ much (approximately 4 of the 51 requirements differed on average, as one can see in Appendix E). This aspect will be discussed in the discussion. The results for the requirements of each chapter will be described in detail below, and analysed in the discussion. System owner # Total Requirements Median (IQR) Responsibilities Responsibility for basic information Responsibility for management of IS Responsibility for alignment and agreements with other parties Responsibility for the communication with end users Conditions for quality fulfilment of system ownership 1 (1-3) 1 (1-1) 1 (1-2) 2 (1.5-3) 4 (2.5-4) 1 (1-1) 5 (5-5) 1 (1-3.5) 2.5 (2-3) 2.5 (1-4) 1 (1-1) 4 (2.5-4) 3 (1-4) 2 (1-2) 4 (4-5) 2.5 (2¼ - 3¾) 3 (2-3) 4 (4-4) 1 (1-1) 3 (3-3) 3 (2-3) 2 (1-2) 5 (5-5) 3 (2.5-3¾) 3 (3-3.5) 3.5 (2¼ - 3¾) 2.5 (1¾ - 2¾) 3 (3-3.5) 2 (2-2.5) 1 (1-2) 5 (4.5-5) 3 (2¼ - 3.5) 4 (3¼ - 4) 4 (2¼ - 4) 1 (1-1) 2.5 (1¼ - 3¾) 4 (3¼ - 4) 4 (3¼ - 4) 4 (2¼ - 4¾) 4 (3¼ - 4) Other activities 3 (3-3.5) 4 (4-4.5) 1 (1-1) 4 (4-4) 3 (2-3.5) 1 (1-2) 5 (4-5) 3 (2-4) Management General requirements 3 (2¾ - 3¼) 2 (1¾ - 2¼) 1 (1-1¼) 2.5 (1¾ - 3¼) 3.5 (2.5-4) 3 (1¾ - 4¼) 1 (1-1¾) 2.5 (1.5-3) Business process management requirements Requirements regarding other management layers 4 (3-4¼) 2 (1-3) 1 (1-1) 3¾ (1-4) 4 (2¾ - 4¼) 3 (1-4) 5 (5-5) 3¾ (2.5-4) 3 (3-3) 2.5 (2-3) 1 (1-1) 4 (3.5-4) 2 (1-2) 1 (1-2) 3 (1-3) 2¼ (1.5-3) Total 3 (3-4) 3 (1-4) 1 (1-1) 3 (2-4) 3 (2-4) 2 (1-4) 5 (3-5) Table 8. Results of requirements for each interviewed system owner University of Amsterdam 17

19 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Although the assessments were done numerically, no statistical analysis other than describing statistics has been used. This was chosen mainly because of the relative small number of systems and owners and the notion that the insight which the median and interquartile ranges gave sufficed for all purposes of the study. Additionally, relevant quotes are added in each requirement chapter, providing insight in the interview answers, as well as the reasons behind the numerical assessments. The full transcripts (with redacted names for increased anonymity) of the interviews can be found in Appendix F, these transcripts interviews range from Appendix F1- F15, corresponding with Interview I1-I15. Basic information The basic information category yielded a median of 1 (IQR = 1-3.5). This was mainly caused by the requirement of a list of information provision services and its users each information systems should have, which fourteen of the seventeen systems (or five of the seven system owners) did not (Mdn = 1, IQR = 1-1). The same proved to be the case for the requirement for documented information on all parties involved with the IS (Mdn = 1, IQR = 1-1). The highest assessed fulfilment was that of the architectural plate, of which five of the seven owners had knowledge of its status (Mdn = 4, IQR = 2-4). Some system owners referred to the business process managers for the documents [I8, I15]. I8: No. I think you should ask the business process manager. He will know more on this subject. [Appendix F8 external 10 ] I14: No idea. [Appendix F14 - external] Others confused the requirement with other, unrelated documents [I1,I2,I3,I4,I5,I7], e.g. by stating: I2: Yes, in our service descriptions, these make it clear to the user what the service consists of and how it can be used. For example, how do you request a card? [Appendix F2] Management of IS The responsibility for the management of the IS totalled a median of 2.5 (IQR = ). Its first requirement, whether the system owner feels like he or she is responsible for the complete chain of management of his or her IS yielded mixed results (Mdn = 3, IQR = ). I1: It depends. The one rule is: the system owner makes decides all changes. [Appendix F1] I2: I can bear that responsibility. I could give it a 10, but it s just a 7 or 8. [Appendix F2] I3: No, not yet. I don t really have an image yet of what such an ownership contains. [Appendix F3] The role allocation of all involved employees was judged above average (Mdn = 3.5, IQR = 3,5-4). Escalation scenarios (Mdn=2), crisis plans (Mdn=1), and update and upgrade management (Mdn=2) were assessed as below average, meaning that those were mostly not available. 10 Externally available (in zip-file) University of Amsterdam 18

20 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes I2: There is no real structure, but we do want it and that s what we are going to work on. [Appendix F2] Alignment other parties The requirements under alignment with other parties combined gathered a median of 3 (IQR = ). All underlying requirements were assessed with a median of 3, however with much variation. Control over change management had an IQR of , Agreements with user organization on control over change management , alignment with system owners and written agreements with other units when management was I1: When financial consequences are in play, or the impact is large, the system owner is responsible. [ ] We handle the changes using a spreadsheet. Changes are discussed in meetings. If they have no impact on other systems, we go through with them. [ ] No, those are not defined, but the agreements are there, but informal and incidental. At a change you do a short impact analysis where one can denote who wants what and by that what other systems will play a role. [Appendix F1] I10: Change requests come in through users per institution. From there they go to representatives, who meet up with all institutes. There the requests are written out and prioritized. A commission adds things like costs and time needed for the changes. Then I match those requests with our budget and come up with an advice plan which is send to all institutes. We go through this twice a year, since we have two releases per year. [ ] Yes, we have agreements on a tactical level about which end user groups get precedence over others. [Appendix F10 - external] Communication with end users The communication with the end users consisted of the availability and quality of call routing schemes, communication protocols and maintenance plans, which were assessed as respectively 3.5 (IQR = ), 3 (IQR = 1.5-3) and 3 (IQR = ). I9: There is no protocol. We are busy making it possible for employees to see the status of their calls, but there is also no protocol on that. [Appendix F9 - external] I10: Yes, we hired a communication advisor at AC (Academic Centre, ed.). Now we have 2 FTE s on it. [Appendix F10 - external] Quality fulfilment of system ownership The chapter of quality fulfilment of system ownership consists of ten requirements, wherein the system owner assessed his or her own skills and some requirements requiring the shared services to provide, e.g. budget and skilled employees. The statements regarding the system owner s skill and competences were assessed as above average for all but one interviewee. The basic knowledge of information management and systems, architecture and the relation with the organization s higher level information governance all resulted in a median of 4 with quartile spreads of 2.5 to 4 (IM and governance) and 3.5 to 4 (architecture). University of Amsterdam 19

21 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Control over and sufficient budget resulted in a median of 4 with an IQR of One system owner explained It s being budgeted, but I do not have a lot of view on the matter. The controller has that.. The skill of the employees of the information systems was rated as 4 (IQR = ). The access to the network of all system owners was assessed with a median of 2 with an IQR of I7: I know how to find most of them and if not I will know after one phone call. [Appendix F7 - external] The amount of influence the interviewee had on the business process managers as system owner was rated with a median of 2, but with great diversity (IQR = ). One interviewee reported to have a lot of influence Yes, 10 (on a scale of 1 to 10, ed.), where another even said: I3: No, I have no direct influence. Just like every other user I would have to send in requests.. [Appendix F3] I5: Not directly, my maintenance management is in between. He does the work for me using his people. [ ] No, more indirectly. He is head of housing and there is somebody below that. [Appendix F5 - external] The availability of communication channels was assessed as above average (Mdn = 4, IQR = 3-4). Advice was rated rather low with a median of 3 (IQR = 1.5-2). The skills of the users of the IS was rated with a median of 3 (IQR = ). Other activities The chapter other activities is home to three requirements concerning innovation, alignment with information management and the system owner s involvement concerning contracts and SLAs. The system owner s involvement with the innovation of his or her IS was rated with a median of 4 (IQR = 3-4). The alignment with the shared services information management was with a median of 4 (IQR = 3-4). The involvement with contracts and SLAs was rated with a median of 3 (IQR = 2-4). I1: Yes, also direct (influence, ed.). I d rate it a 9. There aren t any project they can do without me. Third parties don t have the capacity, they have their hands full on keeping the system working. General requirements for management Division of management of information system in predefined layers of functional management, application coordination, application management, technical management and hosting and housing 4 (IQR = 2.5-4). Application coordination was rated very low, with a median of 1 (IQR = 1-1.5). The requirements also stated that the earlier mentioned managerial layers should be offered to the system owner as services by the relevant departments. This proved not to be the case (Mdn = 2, IQR = 1.5-2). The system owners are however still responsible for all managerial layers. The current situation on this was rated with a median of 2 (IQR = 1-3). University of Amsterdam 20

22 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Business process management requirements This chapter consists of twelve requirements, all regarding business process management layer 11. These requirements together gathered a median of 3.75 with an IQR of Business process management is done internally 5 (IQR = 5-5). Business process management designed according to BiSL 1 (IQR = 1-1). System owner is part of the controlling part of business information management layer 3 (IQR = 2-3.5). The extent to which business process managers are working on an operational level was rated with a median of 4 (IQR = 4-5). Whether the business process managers are placed as close to the system owner as possible was also rated with a median of 4 (IQR = ). Below are the relevant quotes from a very distant placement [I5] and a very close placement [I6] of the system owner in relation to the business process managers: I5: [ ] but there is no daily interference. [Appendix F5 - external] I6: Very close. Any closer is not possible. [Appendix F6- external] The replacement of business information manager(s) was rated with a median of 4 (IQR = 3-4). The advising role of business information managers was also assessed as a 4 (IQR = ). Whether business process managers do not perform application or technical management was rated with a median of 3 (IQR = ). Appointment of key-users depending on the need for key-users of the IS was rated with a 3 (IQR = ). Most systems however, did not have key-users appointed. Alignment of operational processes with key-users 1 (IQR = 1-1). Key-users part of business process management 1 (IQR = ). Regular meetings with business process management with a frequency that corresponds with the dynamicity of the IS 4 (IQR = ). Alignment other management layers The requirements of the chapter concerning the alignment with the other management layers accumulated to a median of 2.5 (IQR = 1.5-3). The extent to which business process management, the top layer of an IS management layers, controls the other layers was assessed as 4 (IQR = ). The other layers are managed by ICT Services 2 (IQR = ). Whether the system owner is responsible for the service level contracts and SLAs was rated with a median of 3 (IQR = 2-3). ICT Services handles all contracts and involves all relevant system owners 1.5 (IQR = 1-3.5). I5: We have a sourcing manager for that. I expect it to be well taken care of. [Appendix F5 - external] ICT Services takes care in providing sufficient available and qualified application management, technical management and hosting and housing to fulfil demands of the system owner 1 (IQR = 1-2.5). Summary The results seem to indicate a rather low current fulfillment of the requirements. The requirements regarding the basic information were assessed as the lowest. 11 Functioneel beheer in Dutch University of Amsterdam 21

23 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes The conditions for quality fulfilment of system ownership were assessed the highest. The results also different (sometimes greatly) between system owners. Possible explanations for these and more findings will be attended in the Discussion. Research questions 6. Discussion In this section the results from the gap-analysis will be used to answer the first and second research question. To what extent do the information provision services at the collaborating services of the two institutes fit the newly stated requirements? This question is answered by summarizing and analyzing the results of the fit-gap analysis. Using the gap analysis own terminology, the gaps are biggest when the assessment is rated the lowest, and the fit is best when the ratings are higher. For this study, this means that a rating of 1 equals a large gap between the current and desired situation, and a rating of 5 equals no gap and the desired situation. With this in mind conclusions can be drawn for the results of all requirement chapters, which will be done next. The responsibility for the basic information proved to be poorly managed. The required documentation was rarely available and even less times validated. The architectural plate was the only document that was adequately represented. A list of what information the information system provides and to whom was rarely available, just as a similar document listing all relevant parties for the information system. Since these are relatively simple documents, it might be that this gap is mainly caused due to a lack of guidance or information. If the system owners would be shown example documents of the required information, the information management department might have all the information they need in a very short period of time. I2: It s mostly just the inexperience in because it s all very recent. [ ] For me it s just a matter of time. In the past period it has become clear what a system owner can, must and is allowed to do. That makes it clear for me what I have to steer and manage, that s what I m going to fill in. [Appendix F2] The responsibility for daily management of the information system was judged as poorly adequate. Most system owners did feel like they were responsible for the whole governance chain. Most system owners also reported that the different roles of employees in their information system were clear. However, processes like incident management, updates and upgrades are not documented and take place ad-hoc. The responsibility for the alignment and agreements with other parties was assessed as poor. Alignment with the users of the information system is done poorly, as is the control over change management. Agreements with system owners of relevant systems is judged as adequate. The conditions for a quality fulfillment of the role of system owner is assessed as relatively well. Basic knowledge is widely acknowledged. No issues with employees were reported. Budget control is assessed as relatively poor, just as access to the network of system owners and the advice of the central information managers. While budget control is slightly out of scope, the access to the network of system owners is something University of Amsterdam 22

24 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes the information management could improve. To start with, some system owners did not even know of the network s existence, indicating some promotion is required. The management of contracts has not been delegated to the ICT Services departed, as stated in the requirements. Key users are rarely appointed. The distance between the system owner and the managerial layers below him differ greatly between systems, varying from very close to no meetings at all. I3: What does one expect of the system owner? What is it that he is going to do? For my boss it s also important how much the time consumption is going to be. It shouldn t be: You re system owner now and done. [ ] I understand that system owners are being guided in the process. That s what I m still missing. [Appendix F3] To what degree do the requirements improve change management? To answer this second research question on change management, first the requirements are compared with the competences acquired from the literature study. Going back to the behavioral skills of Jiang, Klein & Margulis (1998), not much overlap with the requirements can be found. After analyzing the requirements, one can conclude that most are rather practical requirements, rather than about individual characteristics or behavioral skills. They are not completely absent however, some aspects of patience (refining user requirements by requesting feedback) are related to some requirements (R3.3.1 Alignment with user organisation). More overlap can be found when comparing the requirements with the assessment scales of Harison & Boonstra (2009). Starting with the first competence Information technology and information systems (IS/IT) know-how, regarding actual knowledge of the information system and technology field and experience in information system projects in leading and responsible positions. This first topic is clearly represented by requirements like [R3.5.1] Basic knowledge of information management and systems and [R3.5.2] Basic knowledge of architecture. The fact that the interviewees are system owners fulfills the latter part on experience in leading and responsible positions. Organizational change competences are not really represented by the requirements. The system owners, solely in their role of system owner, are not leading organizational change or organizational development projects. They are however, in its technological counterpart: technochange, and with that the competences of leadership and process management, all with the following requirements: R3.3.1 R3.3.2 R3.3.3 R3.3.4 R3.5.3 R4.2.5 R Alignment with user organisation Control over change management Agreements with user organization on control over change management Alignment with system owners of other information systems which have interfaces with the IS Relation with the higher level i-governance and information provision project portfolio management Business process managers are placed as close to the system owner as possible Regular meetings with business process management with a frequency that corresponds with the dynamicity of the information system Together these requirements make it possible, when fulfilled in the best possible way, for a system owner to keep his system up-to-date to accommodate for the ever-changing environment it operates in. The changes in the environment find their way to the system owner trough the alignment with the user organization. The system owners control over change management then grants him the resources to update or change his system accordingly, e.g. by adding new functionality, adding new user groups, etc. University of Amsterdam 23

25 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Should these changes impact other systems, then the system owner consults the network of system owners, knows which system owners he should include in various processes, and is placed close to his business process management to prepare them for potential changes in the way they handle the IS and its processes. Below a system owner that scored highest on the abovementioned requirements explains there IS s change and update processes. Limitations I10: What we are doing now is that we keep developing and utilize the system more every day. [The software supplier] is open to our suggestions, which often lead to new functionalities. We investigate these, but that takes manpower and time. I don't want to hire consultants every time new functionality is developed. I want my own workers to be able to investigate the functionality themselves. They know the institutes, the users, and are managing the system. They know what the users need and what we should prioritize. [ ] The downside is that you have to educate your own people. When someone becomes unavailable, you can t get replacement by picking from a group people that are able to do this. [ ] It takes a lot of time and energy. [ ] The fact that I don t make use of consultants has yielded a lot of positive result. The other institutes are able to profit of the knowledge we develop. This section will describe the limitations of the conducted study. As mentioned before, more systems were investigated that system owners interviewed, since most system owners own more than one information system. However, between systems of the same owner. Not much variation was observed in the results. This might be caused because of the universal nature of some requirements, meaning that the fulfilment does not depend on the specific systems but more so on the system owner as an individual. Measuring instruments We are in the midst of some people call the information explosion, but there is too much information for anyone to assimilate, the information is of doubtful quality, and perhaps most important, the things we collect statistics about are primarily those things that are easiest to identify and count or measure which may have little or no connection with those factors of greatest importance. It is easy to collect statistics on number of hours worked, on cost of equipment, and on such statistical indexes as productivity of labour. It is much more difficult to collect statistics on the quality of a product or its effect on the quality of life. - Donald A. Norman, in: Things That Make Us Smart (1993) This quote from Norman still holds true, also for this study. However, the difficulty of measuring the requirements varied between requirements. Some were easy to identify and measure, e.g. the requirements for the basic information, where the presence of an easy to verify document and knowledge of its existence was enough to get assessed highest, and it s opposite enough to get assessed lowest. Others were harder to measure validly, such as the system owner s level of knowledge on a specific subject. The agreed method of measuring this was to let the owner rate it himself. University of Amsterdam 24

26 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Validity Continuing on the last mentioned requirement and its measurement method: those self-assessment requirements would most likely score lower on construct validity tests than easier to determine requirements like those with documents. However, this is not a reason to discard them. In other research disciplines such as psychology and sociology, self-assessment questionnaires are not uncommon (Horne & Ostberg, 1976; Taylor et al., 2001). Another interesting evaluation is this study s external validity, or to what extent its results can be generalized to other organizations. The first step of generalization would be to generalize the findings to other educational institutes. The question is to what extent this will prove to be fruitful. For certain aspects like the specific values of the results and its derived general conclusions, it is clear that those only apply to the investigated institutes. What might be applied to other institutes, however, are the requirements themselves. Reliability The reliability of a case study is the extent to which a later investigator would get the same results when conducting the same case study all over. It is known that case studies are usually poorly documented and therefore hard to replicate (Yin, 2013). However, this study might be considered as a less flexible case study, since all interviews followed the same list of questions with little room for digression. While this room was little, it did occur that interviewees elaborated on irrelevant topics. When replicated, these could prove to differ greatly. For the gap analysis however, the method can be considered very operational and therefore replicable. 7. Conclusion To end with some concluding remarks, one could start by stating that the current situation at the shared service departments does not fit the newly stated requirements very well. As the relevant people sometimes already stated themselves, several reasons could be the cause of this. The one mentioned most is the recency of the implementation. While the time of system ownership differed between interviewees, the longest experience was several months and the shortest a couple of days. Especially detailed requirements, containing prerequisites that were unknown in the pre-requirement era, such as certain documents or delegations of business processes at a specific department, proved to have the most room for improvement. Another reason mentioned was the lack of information given new system owners, or rather a lack of guidance in the early stages. Some system owners responded that they would like more guidance from the issuing upper management levels, rather than having to discover everything on their own. The same persons however did find the interviews themselves already very useful for this process, since this was the first time they heard of some, or even all, of the requirements. I1: It was like an awakening. My knowledge was not that bad at all. The details proved to be hard to think of. [..] On the one hand I think: I know quite a bit about it, at other times I think I don t know enough on this subject. Which is a good thing, because it makes me think about those things. The requirements for a quality fulfillment of the system ownership, or the system owner s intrinsic set of competences, was assessed rather well. This might make the inevitable better future fulfillment of other requirements easier to achieve, since those competences are the foundation for more extrinsic prerequisites. All in all, it all hints toward a request for more time, guidance and counsel. University of Amsterdam 25

27 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes At the request of the shared services, a research poster was made displaying the results of the gap analysis. This poster was on display for several weeks. It was viewed by system owners and directors alike, so they could all learn the current state of affairs of the fulfillment of the requirements, and the progress of the research begin conducted in their midst. The research poster is included in Appendix D. Regarding change management, the requirements did not overlap much with the behavioral competence taxonomy derived from the literature study. One might argue that such behavioral traits are evaluated at the time of the hiring of an employee and should therefore not have to be included in requirements for a new role inside the organization. On the other hand, as more and more systems need owners, or existing owners need to be replaced for any reason, including these competences in the requirements might aid in selecting the right people for the ownership. When the requirements were compared with the technochange competences taxonomy derived from the literature study, more correspondence was discovered. Although not in a one-to-one fashion, both sets required knowledge of the process of IT-related changes and its implications. Communication and leadership competences were represented by requirements stating meetings, close collaboration with business process management, other departments, suppliers and users. Limitations of this study indicated doubts about the nature of numerical measurements and the self-assessment methods used in the interviews. The reliability of this study was estimated as relatively high, mainly due to a strict approach towards the interview procedure. Future work To see whether the earlier stated future improvements of the fulfillment of the requirements will see the light of day, future work could include the same gap analysis at a later point in time, e.g. a year later. The operational steps of the gap analysis should be able to make it possible to compare those results with the results from this study. Another option is to investigate to what extent the earlier mentioned external validity holds true, by applying this study or the requirements to other educational institutes. Whether this is actually the case could be the topic of future studies. Future work that is already initiated at the shared services is a continued version of the gap analysis, this iteration with other information systems and their dedicated system owners. The control of a large force is the same in principle as the control of a few men. It is merely a question of dividing up their numbers. - Sun Tzu, 500 B.C. 8. Acknowledgements First of all, thank you, reader, for taking the time to read my master s thesis. This paper would not have been possible if it weren t for the involvement of the following people. I would like to thank drs. A.W. Abcouwer and S.W. Nolst Trenité for guiding me throughout both the case study and the thesis writing process. Furthermore, I would like to thank prof. dr. T.M. van Engers for acting as the second reader of this thesis. I thank my fellow master s student Bart van Eck with whom the first part of the case study was conducted, after which we would both write our individual theses. Lastly, I would like to thank my fellow student Joris Westerveld and friend Gavin McQuistin for their continuous feedback and support. University of Amsterdam 26

28 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes 9. References Aghion, P., & Tirole, J. (1997). Formal and Real Authority in Organizations, 105(1), Allan, G. (2003). A critique of using grounded theory as a research method. Electronic Journal of Business Research Methods, 2(1), Bester, H. (2009). Externalities, communication and the allocation of decision rights. Economic Theory, 41, doi: /s z Broadbent, M. (2002). CIO futures-lead with effective governance. ICA 36th Conference. Corbin, J. M., & Strauss, A. (1990). Grounded theory research: Procedures, canons, and evaluative criteria. Qualitative Sociology, 13, doi: /bf Glaser, B. G., & Strauss, A. L. (1967). The discovery of grounded theory. International Journal of Qualitative Methods (Vol. 5, pp. 1 10). doi: / Green, G. I. (1989). Perceived Importance of Systems Analysts Job Skills, Roles, and Non-Salary Incentives. MIS Quarterly, 13, doi: / Guldentops, E. (2004). Governing Information Technology through COBIT. In Strategies for Information Technology Governance (pp ). Harison, E., & Boonstra, A. (2009). Essential competencies for technochange management: Towards an assessment model. International Journal of Information Management, 29, doi: /j.ijinfomgt Horne, J. A., & Ostberg, O. (1976). A self-assessment questionnaire to determine morningness-eveningness in human circadian rhythms. International Journal of Chronobiology, 4(2), Retrieved from Introna, L. (2007). Strategy-as-Identity: An autopoietic contribution to the IS/IT strategy debate. Retrieved from Jamieson, S. (2004). Likert scales: How to (ab)use them. Medical Education. doi: /j x Jennings, M. (2000). Gap analysis: concepts, methods, and recent results*. Landscape Ecology, 15, Retrieved from Jiang, James J., Klein, Gary, Margulis, S. (1998). Important Behavioral Skills for IS Project Managers: The Judgments of Experienced is Professionals. Project Management Journal, 29, 39. Kendra, K., & Taplin, L. J. (2004). Project Success: A Cultural Framework. Project Management Journal, 35, doi: /s (03) Meredith, J. R., Mantel, S. J., & Jr. (2011). Project Management: A Managerial Approach. Retrieved from Moran, J. W., & Brightman, B. K. (2000). Leading organizational change. Journal of Workplace Learning. doi: / University of Amsterdam 27

29 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes Norman, D. (1993). Things that make us smart Addison-Wesley, Outvorst, R. D., & van der Pols, R. (2005). Introductie BiSL Een framework voor functioneel beheer en informatiemanagement 65. Paré, G., & Jutras, J.-F. (2004). HOW GOOD IS THE IT PROFESSIONAL S APTITUDE IN THE CONCEPTUAL UNDERSTANDING OF CHANGE MANAGEMENT? Communications of AIS, 2004, Retrieved from Robinson, L., & Stocken, P. (2013). Location of Decision-rights within Multinational Firms. Journal of Accounting and Economics, doi: / x this Taylor, Whincup, Hindmarsh, Lampe, Odoki, & Cook. (2001). Performance of a new pubertal self-assessment questionnaire: a preliminary study. Paediatric and Perinatal Epidemiology, 15(1), doi: /j x Todnem By, R. (2005). Organisational change management: A critical review. Journal of Change Management. doi: / Tulder, R. J. M. (2012). Skill Sheets. Retrieved from Webb, P., Pollard, C., & Ridley, G. (2006). Attempting to Define IT Governance: Wisdom or Folly? In Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS 06) (Vol. 8, p. 194a 194a). IEEE. doi: /hicss Weill, P., & Ross, J. (2004). IT governance: How top performers manage IT decision rights for superior results (Vol. 1). Retrieved from e+:+how+top+performers+manage+it+decision+rights+for+superior+results&ots=vbpgcyveop& sig=gqhhjjzoajdf4ctvajk0wmhkuxw Yin, R. K. (2013). Case Study Research: Design and Methods. Retrieved from University of Amsterdam 28

30 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes 10. List of Appendices Appendix A: Requirements list Appendix B: Requirements as stated by shared services Appendix C: Interview Protocol Appendix D: Research Poster Appendix E: Results tables (also available in.xslx format) Appendix F: Interview transcripts Appendix F1: Transcript Interview I1 Appendix F1: Transcript Interview I2 Appendix F1: Transcript Interview I3 Appendix F1: Transcript Interview I4 (not included here, in external document) Appendix F1: Transcript Interview I5 (not included here, in external document) Appendix F1: Transcript Interview I6 (not included here, in external document) Appendix F1: Transcript Interview I7 (not included here, in external document) Appendix F1: Transcript Interview I8 (not included here, in external document) Appendix F1: Transcript Interview I9 (not included here, in external document) Appendix F1: Transcript Interview I10 (not included here, in external document) Appendix F1: Transcript Interview I11 (not included here, in external document) Appendix F1: Transcript Interview I12 (not included here, in external document) Appendix F1: Transcript Interview I13 (not included here, in external document) Appendix F1: Transcript Interview I14 (not included here, in external document) Appendix F1: Transcript Interview I15 (not included here, in external document) Appendix G: Presentation slides University of Amsterdam 29

31 IT Governance at Higher Education Institutes in Amsterdam Appendix A Requirements List (Short) R3 Responsibilities of the system owner R3.1 Responsibility for basic information R3.1.1 List of information provision services and its users R3.1.2 Architectural model R3.1.3 Information on involved parties R3.2 Responsibility for management of IS R3.2.1 Responsibility for the complete chain of management R3.2.2 Role allocation R3.2.3 Escalation scenarios R3.2.4 Crisis plans R3.2.5 Update and upgrade management R3.3 Responsibility for alignment and agreements with other parties R3.3.1 Alignment with user organisation R3.3.2 control over change management R3.3.3 Agreements with user organization on control over change management R3.3.4 Alignment with system owners of other information systems which have interfaces with the IS R3.3.5 Written agreements with other units when the management is distributed R3.4 Responsibility for the communication with end users R3.4.1 Call-routing schematics R3.4.2 Communication protocol for the communication with end users R3.4.3 Maintenance plans R3.5 Conditions for quality fulfilment of system ownership R3.5.1 Basic knowledge of information management and systems R3.5.2 Basic knowledge of architecture R3.5.3 Relation with the higher level i-governance and information provision project portfolio management R3.5.4 Budget control R3.5.5 Skill employees R3.5.6 Access to the network of system owners R3.5.7 Influence on daily work of management layers R3.5.8 Available communication channels R3.5.9 Advice from central information managers R Education of end users R3.6 Other activities R3.6.1 Involvement in innovation of information system R3.6.2 Alignment central information management R3.6.3 Involvement with contracts and SLAs R4 Requirements for management of information systems R4.1 General requirements R4.1.1 Division of management of information system in predefined layers of functional management, application coordination, application management, technical management and hosting and housing R4.1.2 Application coordination R4.1.3 Different layers are offered to the system owners as services by the different relevant departments R4.1.4 System owner responsible for all layers R4.2 Business process management requirements R4.2.1 Business process management is done internally R4.2.2 Business process management designed according to BiSL R4.2.3 System owner is part of the controlling part of business information management layer R4.2.4 Business process managers are working on an operational level R4.2.5 Business process managers are placed as close to the system owner as possible R4.2.6 Replacement of business information manager(s) R4.2.7 Business information managers have an advising role R4.2.8 Business process managers do not perform application or technical management R4.2.9 Appointment of key-users depending on the need for key-users of the IS R Alignment of operational processes with key-users R Key-users part of business process management R Regular meetings with business process management with a frequency that corresponds with the dynamicity of the IS R4.3 Requirements regarding other management layers R4.3.1 Business process management controls the other layers R4.3.2 The other layers are managed by ICT Services) R4.3.3 The system owner is responsible for the service level contracts and SLAs R4.3.4 ICT Services handles all contracts and involves all relevant system owners R4.3.5 ICT Services takes care in providing sufficient available and qualified application management, technical management and hosting and housing to fulfil demands of the system owner T.M. van Bremen - University of Amsterdam

32 UITGANGSPUNTEN BEHEER INFORMATIESYSTEMEN SAMENWERKENDE DIENSTEN Onderdeel van Verbetertraject beheer informatiesystemen samenwerkende diensten (winter 2013/2014) Auteur : Sanne Nolst Trenité Versie : 1.0 Datum : Status : Definitieve versie Versiebeheer Versie Datum Verstuurd naar Doel Systeemeigenaren AC/FS; andere geïnteresseerden Feedback/input; ter informatie n.v.t. Tussenversie MT FS Discussie

33 Directeuren AC, FS, ICTS Ter vaststelling Definitief Uitgangspunten beheer IS samenwerkende diensten Page. 2 of 15

34 Index Index Inleiding Beleggen van het systeemeigenaarschap Verantwoordelijkheden van de systeemeigenaar VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS VERANTWOORDELIJKHEID HET BEHEER VAN HET IS VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPEELT Uitgangspunten bij het beheer van de informatiesystemen ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN Bijlage A. BiSL model Bijlage B. kwaliteitskenmerken van software (ISO norm) Uitgangspunten beheer IS samenwerkende diensten Page. 3 of 15

35 1 Inleiding Deze notitie beschrijft de uitgangspunten op basis waarvan de samenwerken diensten van de HvA en UvA (AC, FS, ICTS) het beheer van hun informatiesystemen (IS en) willen organiseren. De uitgangspunten worden gedragen door de directeuren en de door hen benoemde systeemeigenaren. Voor ieder systeem wordt getracht de uitgangspunten te hanteren bij de inrichting van de beheerorganisatie en het dagelijks beheer. Beargumenteerd afwijken van de uitgangspunten voor specifieke systemen is mogelijk na overeenstemming met de directeur van de dienst die verantwoordelijk is voor het betreffende informatiesysteem 1. Het doel van overeenstemming over de rol van de systeemeigenaar en uitgangspunten bij het beheer van de informatiesystemen is het verhogen van de kwaliteit en beschikbaarheid van de IV diensten die door de samenwerkende diensten middels de informatiesystemen geleverd worden. De notitie wordt opgeleverd aan de directeuren van de samenwerkende diensten als onderdeel van het Verbetertraject beheer informatiesystemen samenwerkende diensten en zal in de MT s van de verschillende diensten vastgesteld worden. Uitgangspunten beheer IS samenwerkende diensten Page. 4 of 15

36 2 Beleggen van het systeemeigenaarschap Ieder informatiesysteem heeft één systeemeigenaar, dit is geen functie maar een rol die toebedeeld wordt door de directeur van de dienst die verantwoordelijk is voor het betreffende informatiesysteem. De systeemeigenaar is verantwoordelijk voor de beschikbaarheid en kwaliteit van de informatiediensten die door het systeem geleverd worden. Uitgangspunten m.b.t. beleggen van de rol systeemeigenaar per informatiesysteem zijn: Wordt belegd op het niveau van afdelingshoofd; divisiemanager of directeur Wordt zo laag mogelijk in de organisatie belegd. Alleen wanneer het systemen betreft die de dienstverlening van verschillende afdelingen of divisies overstijgen ligt het voor de hand het systeemeigenaarschap bij de divisiemanager of directeur van de dienst te beleggen. Wordt belegd bij die afdeling/divisie/dienst die de dienstverlening levert die het nauwst verweven is met het betreffende informatiesysteem. Gaat gepaard met de budgetverantwoordelijkheid voor het dagelijks beheer van het betreffende informatiesysteem. Bij afwezigheid van de systeemeigenaar is de directeur van de betreffende dienst de vervanger bij eventuele crisessituaties of wanneer dat zo afgesproken is een collega systeemeigenaar Rol systeemeigenaar wordt besproken als onderdeel van de functioneringsgesprekken van betrokken medewerkers Op basis van bovenstaande uitgangspunten hebben de directeuren van AC en FS voor al hun IS en de systeemeigenaren benoemd. Het MT van ICTS zal op korte termijn voorlopige systeemeigenaar benoemen onder voorbehoud van wijzigingen die voortkomen uit de organisatieplannen ICTS en IRS. 2 Voor het uitzetten van de strategische lijnen en innovatie m.b.t. onze informatiesystemen hebben de HvA en UvA de i-governance 3 ingericht. De systeemeigenaar zal hierbij wel betrokken worden. 2 2 Zie voor actueel overzicht systemen, verantwoordelijke diensten en systeemeigenaren: 03.1 rationalisatie systeemeigenaarschap (uit betrokkenen 1.33).pdf 3 Zie CvB besluit Uitgangspunten beheer IS samenwerkende diensten Page. 5 of 15

37 Ieder informatiesysteem ondersteunt één of meerdere processen met verschillende proceseigenaren. De systeemeigenaar moet daarom in goed overleg met de betrokken proceseigenaren eventuele wijzigingen in het systeem afstemmen. Vooral bij grote systemen met veel gebruikers en een directe rol in het onderwijs of onderzoek is het organiseren van deze afstemming essentieel en tegelijkertijd vrij complex. De vorm zal daarom in goed overleg met de gebruikersrepresentatie per systeem bepaald moeten worden. Uitgangspunten beheer IS samenwerkende diensten Page. 6 of 15

38 3 Verantwoordelijkheden van de systeemeigenaar In hoofdlijnen is de systeemeigenaar verantwoordelijk voor: de beschikbaarheid en kwaliteit van de informatiediensten die door het informatiesysteem (IS) geleverd worden. De systeemeigenaar heeft daarbij ook de verantwoordelijkheid voor de begroting en exploitatie ten behoeve van het beheer, de licenties en overige kosten voor het bewaren van de continuïteit van het informatiesysteem. In dit hoofdstuk wordt in meer detail beschreven wat de verantwoordelijkheden van de systeemeigenaar zijn, welke randvoorwaarden er zijn om aan deze verantwoordelijkheden te voldoen en bij welke overige activiteiten de systeemeigenaar betrokken is. Dit is geen uitputtende opsomming maar wel een eerste aanzet om de belangrijkste aspecten van het systeemeigenaarschap te benoemen. In de komende periode zal systeemeigenaarschap verder geïmplementeerd worden bij AC, FS en ICTS en zal duidelijk worden welke aspecten er nog missen in dit stuk. Voor alle systeemeigenaren geldt dat minstens een aantal van onderstaande punten nieuw is en dat de impact op de dagelijkse werkzaamheden nog onbekend is. Ook is nog niet in alle gevallen aan de voorwaarden voldaan om de verantwoordelijkheid van systeemeigenaar optimaal te kunnen dragen 4. Onderstaande is dan ook eindresultaat waar we samen naar steven waarin de systeemeigenaren de komende maanden begeleid zullen worden. 3.1 Verantwoordelijkheid voor de basisinformatie van het IS De lijst van informatiediensten met bijbehorende gebruikers die door het IS geleverd worden 5 Beschikbaarheid van een up-to-date architectuurplaat van het IS met daarin de interfaces met andere IS en en de data die hierover gaat Het up-to-date houden en/of valideren van de informatie over de betrokkenen bij het beheer van het IS 3.2 Verantwoordelijkheid het beheer van het IS De volledige beheerketen voor het dagelijks beheer van het IS van functioneel beheer tot en met hosting/housing inclusief scholing van de betrokken medewerkers (exclusief scholing van de gebruikers) Heldere belegging van rollen in de beheerorganisatie inclusief een beschrijving van beheerprocessen zoals incidentmanagement, wijzigingsbeheer, probleemmanagement, configuratiebeheer 4 Zie ook: 03.4 Faciliteren van de systeemeigenaren v1.0.pdf voor een verslag van gesprekken met systeemeigenaren 5 Zie als voorbeeld 10.1 Eerste aanzet IVdienstenportfolio Gevalideerd v0.4.pdf Uitgangspunten beheer IS samenwerkende diensten Page. 7 of 15

39 Het bestaan en gebruik van escalatieschema s binnen de beheerketen Het bestaan en gebruik van een crisisplan en bekendheid hiervan in alle lagen van de beheerorganisatie Het laten uitvoeren van updates/upgrades om de continuïteit van het IS te garanderen 3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming met de gebruikersorganisatie op tactisch niveau om aansluiting op de werkprocessen en behoeften van de organisatie te waarborgen De regie op het wijzigingenbeheer (functionele wijzigingen, volgens BiSL 6 ) Het maken van afspraken met de gebruikersorganisatie op tactisch niveau over de manier waarop de systeemeigenaar de regie over het wijzigingsbeheer voert. Afstemming met systeemeigenaren van informatiesystemen waarmee interfaces bestaan Vastgelegde afspraken met andere eenheden wanneer een deel van het beheer daar wordt uitgevoerd (e.g. SLA met ICTS voor applicatiebeheer). 3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers Het bestaan en bekend zijn van efficiënte call-routering voor alle gebruikers van het IS Het bestaan en gebruik van een communicatieprotocol met de gebruikers en overige stakeholders Het bestaan en publiceren van onderhoudsplannen 3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis van informatiesystemen, informatiemanagement en BiSL Kennis van architectuurprincipes 7 Begrip van de relatie met de i-governance en iv-projectportfoliomaangement Voldoende beschikbaar budget Voldoende deskundig personeel beschikbaar Toegang tot het netwerk van systeemeigenaren Directe invloed op de werkzaamheden van de functioneel beheerders van het IS (hiërarchische of functionele aansturing voor dat deel dat de beheerders voor het betreffende IS werken) De noodzakelijke communicatiekanalen ter beschikking 6 Zie Bijlage A BiSL model 7 Zie ook t.b.v. architectuurprincipes: Bijlage B. Kwaliteitskenmerken van software (ISO-25010) Uitgangspunten beheer IS samenwerkende diensten Page. 8 of 15

40 Advies van de centrale informatiemanagers over o.a. technologische ontwikkelingen Voldoende geschoolde gebruikers, de systeemeigenaar heeft wel een rol in planning van de scholing en doorbelasting kosten maar is niet verantwoordelijk voor de kwaliteit van de betrokken gebruikers. Hier worden in de dienstbeschrijving afspraken over gemaakt. 3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid bij de innovatie van het IS, inclusief het aanmelden en aansturen van iv-projecten die het IS betreffen Afstemming met centraal informatiemanagement rondom iv-projectportfolio en overige relevante zaken Betrokkenheid bij de relatie tussen het IS en de HvA/UvA werkplekken Betrokkenheid bij het opstellen van de contracten en SLA s tussen ICTS en externe leveranciers Uitgangspunten beheer IS samenwerkende diensten Page. 9 of 15

41 4 Uitgangspunten bij het beheer van de informatiesystemen De samenwerkende diensten hanteren onderstaande uitgangspunten bij het dagelijks beheer van hun informatiesystemen. Van deze uitgangspunten is geargumenteerd af te wijken na akkoord van de directeur van de voor het IS verantwoordelijke dienst. Ook is een deel van de gevolgen van het aanhouden van deze uitgangspunten nog niet geïmplementeerd. Zo worden bijvoorbeeld nog een groot aantal contracten met externe ICT leveranciers bij AC en FS beheert die volgens de uitgangspunten aan ICTS overgedragen zullen moeten worden Algemene uitgangspunten m.b.t. beheer Het beheer van ieder IS is opgedeeld in de volgende lagen: functioneel beheer, applicatiecoo rdinatie, applicatiebeheer, technisch beheer, hosting, housing. Applicatiecoördinatie is ingevuld wanneer applicatiebeheer uitbesteed is aan een externe partij. De uitvoering van applicatiecoo rdinatie, applicatiebeheer, technisch beheer, hosting en housing ligt voor alle IS en bij ICTS. Deze beheerlagen worden als diensten aangeboden aan de systeemeigenaren. De systeemeigenaar is verantwoordelijk voor alle lagen van het beheer, ook die lagen die bij andere eenheden als dienst worden afgenomen. Functioneel beheer Applicatiecoördinatie Applicatiebeheer Technisch beheer Housing & hosting 4.2 Uitgangspunten m.b.t. functioneel beheer Functioneel beheer wordt voor alle IS en intern belegd (bij outsourcing spreken we van een informatiedienst die door een externe partij wordt verzorgd en is er geen sprake van systeemeigenaarschap of informatiesysteem) 8 Zie ook: 08.1 Overzicht contracten met IVICT component def.pdf Uitgangspunten beheer IS samenwerkende diensten Page. 10 of 15

42 Uitvoerend en sturend functioneel beheer wordt in hoofdlijnen ingericht volgens BiSL 9 waarbij in elk geval de hoofdprocessen belegd zijn. De systeemeigenaar is onderdeel van de sturende laag van functioneel beheer. Functioneel beheerders zijn onderdeel van de uitvoerende laag van functioneel beheer. De functioneel beheerders worden zo dicht mogelijk bij de systeemeigenaar geplaats en vallen in elk geval binnen dezelfde dienst als waar de systeemeigenaar onderdeel van is. Er is voor ieder informatiesysteem minsten één persoon met de rol van functioneel beheerder en één persoon die als plaatsvervangend functioneel beheerder kan optreden beschikbaar. (Plaatsvervanging kan eventueel wel extern belegd worden). De functioneel beheerders hebben een adviserende en uitvoerende rol en nemen zelf geen besluiten over de functionele inrichting en/of gebruikersautorisaties van het IS zonder akkoord van de systeemeigenaar. Functioneel beheerders voeren geen applicatiebeheer of technisch beheer activiteiten uit en zijn bij het contractmanagement alleen op operationeel niveau betrokken. Afhankelijk van de aard van het IS worden key-users of decentraal functioneel beheerders benoemd als onderdeel van de uitvoerende functioneel beheer organisatie. Dit gebeurt in nauwe afstemmen met de gebruikersrepresentatie op tactisch niveau. De operationele BiSL processen worden afgestemd met de key-users of decentraal functioneel beheerders. De term decentraal functioneel beheerder wordt alleen in die gevallen gebruikt wanneer een aanzienlijk aantal van de operationele functioneel beheerprocessen volgens BiSL decentraal belegd worden, wanneer dat niet het geval is wordt gekozen voor een andere term zoals key-user. De systeemeigenaar heeft regulier overleg met (representatie van) de functioneel beheerder(s) met een frequentie die aansluit bij de dynamiek van het betreffende IS. 4.3 Uitgangspunten m.b.t. de andere beheerlagen Functioneel beheer is sturend ten opzichte van de andere beheerlagen. Alle beheerlagen onder functioneel beheer worden onder verantwoordelijkheid van ICTS uitgevoerd (ook het beheer dat geoutsourcet is) en doorbelast aan de betreffende systeemeigenaren. De systeemeigenaar en de service manager(s) van ICTS zijn verantwoordelijk voor het juiste serviceniveau van de dienstverlengingsovereenkomst tussen ICTS en de dienst/ divisie waaronder het IS valt. 9 Zie bijlage A. BiSL model Uitgangspunten beheer IS samenwerkende diensten Page. 11 of 15

43 ICTS is verantwoordelijk voor het contractmanagement van contracten met eventuele externe leveranciers van beheeractiviteiten en betrekt daarbij altijd de relevante systeemeigenaren. Wanneer (een deel van) het applicatiebeheer wordt uitbesteed wordt applicatiecoo rdinatie ingericht, in andere gevallen kan er ook voor gekozen worden het in te richten. ICTS zorgt voor voldoende beschikbaar en gekwalificeerd applicatiebeheer, technisch beheer, hosting en housing om aan de afspraken met de systeemeigenaar te kunnen voldoen. Uitgangspunten beheer IS samenwerkende diensten Page. 12 of 15

44 Bijlage A. BiSL model Uitgangspunten beheer IS samenwerkende diensten Page. 13 of 15

45 Uitgangspunten beheer IS samenwerkende diensten Page. 14 of 15

46 Bijlage B. kwaliteitskenmerken van software (ISO norm) Uitgangspunten beheer IS samenwerkende diensten Page. 15 of 15

47 MASTER THESIS BEHEER IS SAMENWERKENDE DIENSTEN UVA-HVA Interview Protocol Authors : Tim van Bremen, Bart van Eck Case Supervisor : Mw. S.W. Nolst Trenité UvA Supervisor : Dhr. drs. A.W. Abcouwer Version : 0.2 Date : Status : First draft Version management Version Date Sent to Goal Mw. S.W. Nolst Trenité, Feedback/input Information Manager FS UvA Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 1 of 18

48 Index Index Te onderzoeken systemen AC ICTS FS Introductie interview R3 Verantwoordelijkheid voor de basisinformatie van het IS VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS R3.2 VERANTWOORDELIJKHEID VOOR HET BEHEER VAN HET IS VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN R3.4 VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS R3.5 RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP R3.6 OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPELT R4 Uitgangspunten bij het beheer van de informatiesystemen R 4.1 ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER R4.2 UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER R4.3 UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN AFSLUITING INTERVIEW Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 2 of 18

49 1 Te onderzoeken systemen 1.1 AC 1.2 ICTS 1.3 FS ARIS o Marianne Noordergraaf -> Paul Franssen SAP FICO (HvA) o Paul Franssen SAP FICO (UvA) o Paul Franssen SAP HR (HvA) o Jan Moorman SAP HR (UvA) o Jan Moorman Active Directory 2AT (HvA) o Lex Welman Active Directory 2AT (UvA) o Lex Welman Blackboard (UvA) o Gimène Spaans DLWO (HvA) o Gimène Spaans Medewerkersmail o Gimène Spaans SAP PI o Lex Welman Gebouwbeheersystemen (GBS) o Gerben Smit Servicekaartsystemen o Aaron Meyer o VRS (HvA) o KMS o TisM (HvA) o SmartAccess (HvA) o Salto (UvA) o Salto (HvA) o Pasfoto upload (UvA) o Pasfoto upload (HvA) Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 3 of 18

50 1.4 Systeemeigenaren fase 1 Aaron Meyer Gerben Smit Gimène Spaans Jan Moorman Lex Welman Paul Franssen Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 4 of 18

51 2 Introductie interview Wie zijn wij? o Masterstudenten UvA o Afstudeeronderzoek HvA/UvA Wat doen we? o Vastgestelde uitgangspunten vergelijken m.b.t. huidige situatie o Analyse o Academische onderbouwing door koppeling met literatuur Doel van de analyse o Inzicht huidige situatie over verschillende Doel van dit interview o Inzicht verkrijgen over invulling van uitgangspunten voor uw IS en informatievoorzieningen o Niet te beschouwen als evaluatiegesprek Verzoeken tot opname interview o Wissen na afsluiten onderzoek (juli 2014) Samenvatting interview voorleggen aan geïnterviewde voor eventuele aanpassingen Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 5 of 18

52 3 R3 Verantwoordelijkheid voor de basisinformatie van het IS Onderstaande vragen alleen voor SE. 3.1 Verantwoordelijkheid voor de basisinformatie van het IS R3.1.1 Lijst van informatiediensten die het IS levert met bijbehorende gebruikers Vooraf checken bij Soenita Indien niet aanwezig: Zijn deze gegevens voor uw systeem bekend? Heeft u deze gegevens gevalideerd bij Soenita Sitabi? [Lijst IV-diensten en gebruikers] / Checken bij Soenita (Laatste versie continu verkrijgen) R3.1.2 Architectuurplaat Is er een architectuurplaat/model van interfaces en data transfer van het IS? Beschrijft dit model de huidige situatie? Heeft u dit model gevalideerd bij Soenita Sitabi? Wat is de huidige status? Checken in ARIS Checken bij René Visscher / Soenita [Architectuurplaat] / Checken bij René Visscher / ARIS R3.1.3 Informatie over betrokkenen Is er een overzicht over welke rol door welke beheerder of partij wordt uitgevoerd? Wordt dit up-to-date gehouden? Heeft u dit overzicht bij Soenita gevalideerd? [Overzicht betrokken beheerders] / Checken bij Tineke Vonk (Laatste versie continu verkrijgen) Checken bij Tineke / Soenita Linken aan R4.1.1 Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 6 of 18

53 3.2 R3.2 Verantwoordelijkheid voor het beheer van het IS U bent nu als systeemeigenaar verantwoordelijk volledige beheerketen voor het dagelijks beheer van {IS}, van functioneel beheer tot en met hosting/housing inclusief scholing van de betrokken medewerkers (exclusief scholing van de gebruikers) R3.2.1 Volledige beheerketen Beleeft u deze verantwoordelijkheid zo? Kunt u op dit moment deze verantwoordelijk voor de hele beheerketen dragen? Zijn er externe partijen betrokken bij {IS}? Zijn er contracten met die externe partijen? [Contract] Zo nee, wat zou u ervoor nodig hebben? Hoe is de scholing geregeld? R3.2.2 Belegging rollen Zijn de verschillende rollen in de beheerorganisatie helder belegd? Staat dit ergens op papier? [Document] [Mondeling] Zijn er beschrijvingen van incidentmanagement? [Document] Zijn er beschrijvingen van wijzigingsbeheer? [Document] Zijn er beschrijvingen van probleemmanagement? [Document] Zijn er beschrijvingen van configuratiebeheer? [Document] R3.2.3 Escalatieschema s Zijn er escalatieschema s binnen de beheerketen? Staan ze op papier? [Document] [Mondeling] Zijn ze in gebruik? Checken bij de mensen onderdeel van de escalatieschema s Naar wie escaleer je als iemand zijn/haar werk niet doet? Belangrijk bij externe partijen. Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 7 of 18

54 3.2.4 R3.2.4 Crisisplan Is er een crisisplan? Waar is die te vinden? Staan ze op papier? [Document] [Mondeling] Is het crisisplan bekend in alle lagen van de beheerorganisatie? Noot: Niet de bedoeling dat dit overal op dezelfde manier gebeurt (crisisplannen kunnen verschillen) R3.2.5 Updates en upgrades Worden er regulier, planmatig of incidenteel updates/upgrades uitgevoerd bij {IS} om de continuïteit van het IS en haar IV-diensten te waarborgen (t.b.v. security, compatability)? Bij wie kunnen wij dat wel achterhalen? Wat zijn de gevolgen voor {IS}? Wat is het belang van updates voor {IS}? [Document] [Mondeling] 3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming met de gebruikersorganisatie op tactisch niveau om aansluiting op de werkprocessen en behoeften van de organisatie te waarborgen Wie zit er op tactisch niveau van de gebruikersorganisatie? Op welke frequentie wordt er door wie met wie gesproken (+ rollen)? Heeft u de indruk dat er hierdoor sprake is van aansluiting op de werkprocessen en behoeften van de organisatie? R3.3.2 De regie op het wijzigingenbeheer (functionele wijzigingen, volgens BiSL 1 ) Wordt er volgens BiSL gewerkt bij functionele wijzigingen in {IS}? Bent u daar zelf direct bij betrokken? Zo ja, hoe? Staat dit op papier? [Document] [Mondeling] 1 Zie Bijlage A BiSL model Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 8 of 18

55 3.3.3 R3.3.3 Het maken van afspraken met de gebruikersorganisatie op tactisch niveau over de manier waarop de systeemeigenaar de regie over het wijzigingsbeheer voert. Zijn er afspraken gemaakt met de gebruikersorganisatie over de manier waarop de systeemeigenaar de regie over het wijzigingsbeheer voert? Is er sprake van aparte afspraken / onderscheid verschillende partijen? Hoe wordt het afgestemd in het geval van meerdere partijen? (Bijv. UvA en HvA) Met wie zijn welke afspraken gemaakt (+ rollen)? Welke gebruikersgroep(en) representeert diegene? Gremia bedrijfsvoerdersoverleg Zijn die afspraken vastgelegd? Document Hoe vaak vinden er vergaderingen plaats? R3.3.4 Afstemming met systeemeigenaren van informatiesystemen waarmee interfaces bestaan Is er sprake van afstemming met systeemeigenaren informatiesystemen waarmee interfaces bestaan? Zijn die afspraken vastgelegd? Zo ja, hoe? Document Hoe vaak vindt er overleg plaats? R3.3.5 Vastgelegde afspraken met andere eenheden wanneer een deel van het beheer daar wordt uitgevoerd (e.g. SLA met ICTS voor applicatiebeheer). Wordt er deel van het beheer in een andere eenheid uitgevoerd? Zijn er vastgelegde afspraken met andere eenheden wanneer een deel van het beheer daar wordt uitgevoerd? (Noot: Bijv. SLA met ICTS voor applicatiebeheer) Noot: Mag expliciet verwijzen naar functioneel beheerder (alleen van leveren informatie) Checken bij die functioneel beheerder Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 9 of 18

56 3.4 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Het bestaan en bekend zijn van efficiënte call-routering voor alle gebruikers van het IS Checken in [Bijlage 02_1 Inzicht call routering_ pdf] Wat is de call-routering voor elke groep gebruikers? Is de call-routering geregeld? Is er call-routering vastgelegd? Zo ja, waar? Is dit bekend bij alle gebruikers? Is dit helder voor eindgebruiker van {IS}? Is de call-routering volgens u efficiënt? Noot: zie [100-Dagen plan Juli 2013] R3.4.2 Het bestaan en gebruik van een communicatieprotocol met de gebruikers en overige stake-holders Bestaat er een communicatieprotocol met de gebruikers en de overige stakeholders van {IS}? Is dit vastgelegd? Zo ja, waar? [Document] [Analyse] Noot: zie [100-Dagen plan Juli 2013] en [Advies 100-Dagen plan Juli 2013] Wordt hier gebruik van gemaakt? R3.4.3 Het bestaan en publiceren van onderhoudsplannen Zijn er onderhoudsplannen? Staat dit op papier? Document Zijn de onderhoudsplannen gepubliceerd? Zo ja, waar? En voor wie is dit toegankelijk? Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 10 of 18

57 3.5 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis van informatiesystemen, informatiemanagement en BiSL Heeft u de indruk dat u genoeg basale kennis heeft van informatiesystemen, informatiemanagement en BiSL? R Kennis van architectuurprincipes Heeft u de indruk voldoende kennis te hebben van architectuurprincipes? R Begrip van de relatie met de i-governance en iv-projectportfoliomaangement Heeft u de indruk dat.. Snapt u de relatie van de i-governance met iv-portfoliomanagement? R Voldoende beschikbaar budget Beschikt u over voldoende beschikbaar budget? Voor welke aspecten van het systeemeigenaarsschap heeft u budget beschikbaar? Wordt dit apart begroot? R Voldoende deskundig personeel beschikbaar Is er u voldoende personeel beschikbaar? Is het personeel voldoende deskundig? R Toegang tot het netwerk van systeemeigenaren Heeft u voldoende toegang tot het netwerk van systeemeigenaren? Maakt u gebruik van dit netwerk? R Directe invloed op de werkzaamheden van de functioneel beheerders van het IS (hiërarchische of functionele aansturing voor dat deel dat de beheerders voor het betreffende IS werken) Heeft u directe invloed op de werkzaamheden van de functioneel beheerders van {IS}? R De noodzakelijke communicatiekanalen ter beschikking Heeft u de noodzakelijke communicatiekanalen ter beschikking om over uw IS te communiceren met de eindgebruikers? Zo nee, welke kanalen mist u? Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 11 of 18

58 3.5.9 R Advies van de centrale informatiemanagers over o.a. technologische ontwikkelingen Maakt u gebruik van advies van de centrale informatiemanagers over o.a technologische ontwikkelingen in uw rol als systeemeigenaar? R Voldoende geschoolde gebruikers, de systeemeigenaar heeft wel een rol in planning van de scholing en doorbelasting kosten maar is niet verantwoordelijk voor de kwaliteit van de betrokken gebruikers. Hier worden in de dienstbeschrijving afspraken over gemaakt. Vindt u dat de gebruikers van {IS} voldoende zijn geschoold? Kunnen ze goed overweg met het informatie systeem? Plant u wel eens extra scholing of trainingen in voor de gebruikers? 3.6 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij spelt R3.6.1 Betrokkenheid bij de innovatie van het IS, inclusief het aanmelden en aansturen van iv-projecten die het IS betreffen Bent u voldoende betrokken bij de innovatie van uw Informatie Systeem? Bent u betrokken bij het aanmelden en aansturen van iv-projecten van uw Informatie Systeem? R3.6.2 Afstemming met centraal informatiemanagement rondom iv-projectportfolio en overige relevante zaken Is er een goede afstemming met centraal informatiemanagement rondom het ivprojectportfolio en overige relevante zaken? Bent u betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken? R3.6.3 Betrokkenheid bij het opstellen van de contracten en SLA s tussen ICTS en externe leveranciers Bent u zelf betrokken bij het opstellen van de contracten en SLA s tussen ICTS en externe leveranciers? Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 12 of 18

59 4 R4 Uitgangspunten bij het beheer van de informatiesystemen De samenwerkende diensten hanteren onderstaande uitgangspunten bij het dagelijks beheer van hun informatiesystemen. Van deze uitgangspunten is geargumenteerd af te wijken na akkoord van de directeur van de voor het IS verantwoordelijke dienst. Ook is een deel van de gevolgen van het aanhouden van deze uitgangspunten nog niet geïmplementeerd. Zo worden bijvoorbeeld nog een groot aantal contracten met externe ICT leveranciers bij AC en FS beheert die volgens de uitgangspunten aan ICTS overgedragen zullen moeten worden R 4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Het beheer van ieder IS is opgedeeld in de volgende lagen: functioneel beheer, applicatiecoördinatie, applicatiebeheer, technisch beheer, hosting, housing. Is het beheel van IS opgedeeld in de lagen: a. functioneel beheer b. applicatiecoo rdinatie c. applicatiebeheer d. technisch beheer e. hosting en housing? Zijn deze rollen gescheiden? Zijn er lagen uitbesteed? Is dit vastgelegd? Hoe afhankelijk is het IS van deze uitbestedingen? Hoe afhankelijk is de externe partij van UvA/HvA? R4.1.2 Applicatiecoördinatie is ingevuld wanneer applicatiebeheer uitbesteed is aan een externe partij. Is er applicatiebeheer uitbesteed aan een externe partij? Zo ja, is de applicatiecoördinatie vastgelegd? [Document] R4.1.3 De uitvoering van applicatiecoördinatie, applicatiebeheer, technisch beheer, hosting en housing ligt voor alle IS en bij ICTS. Deze beheerlagen worden als diensten aangeboden aan de systeemeigenaren. Is van applicatiecoo rdinatie, applicatiebeheer, technisch beheer, hosting en housing belegd bij ICTS? Zo nee, welke lagen niet? 2 Zie ook: 08.1 Overzicht contracten met IVICT component def.pdf Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 13 of 18

60 4.1.4 R4.1.4 De systeemeigenaar is verantwoordelijk voor alle lagen van het beheer, ook die lagen die bij andere eenheden als dienst worden afgenomen. Bent u ook verantwoordelijk voor lagen van het beheer die bij ICTS belegd zijn? Zijn er lagen van het beheer die bij andere eenheden als dienst worden afgenomen? Zo ja, in hoeverre bent u daar verantwoordelijk voor? 4.2 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 Functioneel beheer wordt voor alle IS en intern belegd (bij outsourcing spreken we van een informatiedienst die door een externe partij wordt verzorgd en is er geen sprake van systeemeigenaarschap of informatiesysteem) Is functioneel beheer voor uw IS geoutsourcet? R4.2.2 Uitvoerend en sturend functioneel beheer wordt in hoofdlijnen ingericht volgens BiSL 3 waarbij in elk geval de hoofdprocessen belegd zijn. Is uitvoerend en sturend functioneel beheer ingericht volgens BiSL? Welke processen zijn volgens BiSL ingericht? In elk geval de hoofdprocessen R4.2.3 De systeemeigenaar is onderdeel van de sturende laag van functioneel beheer Welke besluiten mag de functioneel beheerder zelf nemen? Voor welke besluiten wordt de systeemeigenaar gevraagd?* R4.2.4 Functioneel beheerders zijn onderdeel van de uitvoerende laag van functioneel beheer. Heeft u het idee dat u onderdeel bent van de uitvoerende laag? Beleeft u operationeel, sturend of strategisch R4.2.5 De functioneel beheerders worden zo dicht mogelijk bij de systeemeigenaar geplaatst en vallen in elk geval binnen dezelfde dienst als waar de systeemeigenaar onderdeel van is. Hoe dicht staat u organisatorisch bij de functioneel beheerders van {IS}? Vallen binnen dezelfde dienst? 3 Zie bijlage A. BiSL model Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 14 of 18

61 Hiërarchische relatie R4.2.6 Er is voor ieder informatiesysteem minsten één persoon met de rol van functioneel beheerder en één persoon die als plaatsvervangend functioneel beheerder kan optreden beschikbaar. (Plaatsvervanging kan eventueel wel extern belegd worden). Hoe is vervanging geregeld voor de functioneel beheerder? Wie? Zijn er meerdere? R4.2.7 De functioneel beheerders hebben een adviserende en uitvoerende rol en nemen zelf geen besluiten over de functionele inrichting en/of gebruikersautorisaties van het IS zonder akkoord van de systeemeigenaar. Hebben de functioneel beheerders een adviserende uitvoerende rol en nemen ze zelf geen besluiten over de functionele inrichting en/of gebruikersautorisaties van het IS zonder uw akkoord?* R4.2.8 Functioneel beheerders voeren geen applicatiebeheer of technisch beheer activiteiten uit en zijn bij het contractmanagement alleen op operationeel niveau betrokken. Voeren de functioneel beheerders applicatiebeheer of technisch beheer activiteiten uit? Zijn functioneel beheerders alleen op operationeel niveau betrokken bij contractmanagement? Zo nee, welk niveau? R4.2.9 Afhankelijk van de aard van het IS worden key-users of decentraal functioneel beheerders benoemd als onderdeel van de uitvoerende functioneel beheer organisatie. Dit gebeurt in nauw afstemmen met de gebruikersrepresentatie op tactisch niveau. Zijn er key-users benoemd als onderdeel van uitvoerend functioneel beheer? Zijn er decentrale functioneel beheerders voor {IS}? Wanneer met wie? R De operationele BiSL processen worden afgestemd met de key-users of decentraal functioneel beheerders. Welke operationele BiSL-processen worden afgestemd met de key-users? En met decentrale functioneel beheerders? Wat wordt er afgestemd? Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 15 of 18

62 R De term decentraal functioneel beheerder wordt alleen in die gevallen gebruikt wanneer een aanzienlijk aantal van de operationele functioneel beheerprocessen volgens BiSL decentraal belegd worden, wanneer dat niet het geval is wordt gekozen voor een andere term zoals key-user. Is er sprake van een decentraal functioneel beheerder? Zo ja, hoe groot is het aantal van de operationele functioneel beheerprocessen dat volgens BiSL decentraal belegd wordt? R De systeemeigenaar heeft regulier overleg met (representatie van) de functioneel beheerder(s) met een frequentie die aansluit bij de dynamiek van het betreffende IS. Heeft u regulier overleg met functioneel beheerders? Wat voor frequentie? Waarom is er gekozen voor die frequentie? Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 16 of 18

63 4.3 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 Functioneel beheer is sturend ten opzichte van de andere beheerlagen. Is functioneel beheer van {IS} sturend t.o.v. andere beheerlagen? Neemt applicatiebeheer onafhankelijk van functioneel beheer besluiten? R4.3.2 Alle beheerlagen onder functioneel beheer worden onder verantwoordelijkheid van ICTS uitgevoerd (ook het beheer dat geoutsourcet is) en doorbelast aan de betreffende systeemeigenaren. Hoe zijn de beheerlagen onder functioneel beheer geregeld? Wie is er verantwoordelijk voor? Vallen die onder de verantwoordelijkheid van ICTS? Zijn er beheerlagen geoutsourcet? Zijn ook die beheerlagen de verantwoordelijkheid van ICTS? R4.3.3 De systeemeigenaar en de service manager(s) van ICTS zijn verantwoordelijk voor het juiste serviceniveau van de dienstverlenging overeenkomst tussen ICTS en de dienst/ divisie waaronder het IS valt. Is dat zo? Hoe blijkt dit? R4.3.4 ICTS is verantwoordelijk voor het contractmanagement van contracten met eventuele externe leveranciers van beheeractiviteiten en betrekt daarbij altijd de relevante systeemeigenaren. Hoe is het management van contracten geregeld? Liggen de contracten bij ICTS? Is er verschil tussen contractmanagement voor geoutsourcete en interne dienstverlening overeenkomsten? Betrekt ICTS u bij de beheeractiviteiten met externe leveranciers van beheeractiviteiten? R4.3.5 Wanneer (een deel van) het applicatiebeheer wordt uitbesteed wordt applicatiecoördinatie ingericht, in andere gevallen kan er ook voor gekozen worden het zelf in te richten. Is er applicatiecoördinatie? Is een deel van het applicatiebeheer uitbesteed? Zo nee, waarom is er toch gekozen voor applicatiecoördinatie? Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 17 of 18

64 4.3.6 R4.3.6 ICTS zorgt voor voldoende beschikbaar en gekwalificeerd applicatiebeheer, technisch beheer, hosting en housing om aan de afspraken met de systeemeigenaar te kunnen voldoen. Heeft u de indruk dat ICTS voldoende. Afspraken te voldoen Zijn er afspraken met ICTS over applicatie- en technisch beheer, hosting en housing? Zo ja, wordt er aan die afspraken voldaan? Afsluiting interview Master Thesis Beheer IS UvA-HvA Interview Protocol Page. 18 of 18

65 Master Thesis Beheer Informatiesystemen UvA/HvA Introductie Methode Wie zijn wij? Masterstudenten UvA. Afstudeeronderzoek bij HvA/UvA. Wat doen we? Vastgestelde uitgangspunten m.b.t. beheer van de informatiesystemen vergelijken met de huidige situatie. Analyse van verschillen hiertussen. Academische onderbouwing door koppeling met wetenschappelijke literatuur (vervolgonderzoek). Doel van de analyse Inzicht verschaffen huidige situatie over verschillende systemen. Uitgangspunten vertaald naar interview-vragen. Te onderzoeken informatiesystemen vastgesteld. Interviews gehouden met de systeemeigenaren van deze systemen. Antwoorden van interview vertaald naar elk uitgangspunt, d.m.v. een Likertschaal van 1 tot 5, om zo een beeld te geven van de huidige invulling van elk uitgangspunt. Aanvullende interviews met functioneel beheerders gehouden daar waar mogelijk/gewenst. Interviews schriftelijk verwerkt en ter inzage geleverd aan desbetreffende geïnterviewde. Algemene Conclusies Invulling uitgangspunten De vereiste documentatie van de basisinformatie is bij de meeste onderzochte systemen niet geregeld. Verschillende stukken schijnen er wel te zijn, maar moeten opgevraagd worden bij een andere afdeling. Beoordeling: 2/5 De randvoorwaarden voor een goede invulling van het systeemeigenaarschap zijn relatief goed beoordeeld. De basale kennis is er, maar soms is er niet voldoende beschikbaar budget. Beoordeling: 4/5 Een aantal systeemeigenaren gaf aan (nog) te weinig weten over hun systeemeigenaarschap en de uitgangspunten. Dit heeft dan vooral te maken met de invulling van applicatiecoördinatie en de verantwoordelijkheid voor de verschillende beheerlagen. Beoordeling: 2/5. De meeste ondervraagde systeemeigenaren weten niet of het functioneel beheer is ingericht volgens BiSL. Daarvan weet er ook een aantal niet wat BiSL inhoudt. Beoordeling: 2/5 Het merendeel van de ondervraagde systeemeigenaren weet niet van het netwerk van systeemeigenaren, of ze hier toegang toe hebben of maakt hier gebruik van. Beoordeling: 2/5 Het contractmanagement is veelal nog niet bij ICTS belegd. Soms is er wel verantwoordelijkheid maar is dit niet vastgelegd of liggen de contracten ergens anders dan bij ICTS. Beoordeling: 2/5 Vaak zijn er geen key-users of decentraal functioneel beheerders benoemd. Beoordeling: 2/5 De afstand tussen de systeemeigenaar en functioneel beheer verschilt tussen systemen, variërend van heel dicht tot nooit overleg mee. Beoordeling: 3/5 Beoordeling op Likert schaal 3 Zeer goed 1 Zeer slecht ,7 2,4 2,6 2,5 3,3 2,7 2,2 3,0 2,5 Onderzochte Informatiesystemen Vervolg van het onderzoek 1. Hoe kunnen de uitgangspunten het beste geïmplementeerd worden, met betrekking tot risico s en weerstand bij verandering? 2. Hoe kunnen de uitgangspunten helpen bij de uitvoering van wijzigingsbeheer? Uitgevoerd door: Tim van Bremen (T.M.vanBremen@uva.nl) Bart van Eck (B.vanEck@uva.nl) Supervisors: UvA/HvA: S.W. Nolst Trenité UvA: dhr. drs. A.W. Abcouwer Zomer 2014

66 Requirements IS1 IS2 IS3 IS4 IS5 IS6 IS7 IS8 IS9 IS10 IS11 IS12 IS13 IS14 IS15 IS16 IS16 Totalen ID Description Name Name Name GBS-LWB (HvA) Name GBS-KMH (HvA) Name Name Name Name Name Name Name Name Name Name Name Gemiddelde Mediaan 0,25 0,75 R3 Verantwoordelijkheid basisinformatie R3.1 Responsibility for basic information R3.1.1 List of information provision services and its users , R3.1.2 Architectural model , ,25 R3.1.3 Information on involved parties , Total , ,25 R3.2 Responsibility for management of IS R3.2.1 Responsibility for the complete chain of management , R3.2.2 Role allocation , R3.2.3 Escalation scenarios , ,75 R3.2.4 Crisis plans , ,25 R3.2.5 Update and upgrade management , Total 2,5 2 2,5 2,5 4 3, ,4 2,5 1 3,75 R3.3 Responsibility for alignment and agreements with other parties R3.3.1 Alignment with user organisation , R3.3.2 Control over change management , ,25 R3.3.3 Agreements with user organization on control over change management , R3.3.4 Alignment with system owners of other information systems which have interfaces with the 3 IS , ,25 R3.3.5 Written agreements with other units when the management is distributed , Total , ,25 R3.4 Responsibility for the communication with end users R3.4.1 Call-routing schematics ,0 3,5 1,5 4 R3.4.2 Communication protocol for the communication with end users , R3.4.3 Maintenance plans , ,25 Total , ,5 1, ,5 2,5 1,5 3 R3.5 Conditions for quality fulfilment of system ownership R3.5.1 Basic knowledge of information management and systems , R3.5.2 Basic knowledge of architecture , R3.5.3 Relation with the higher level i-governance and information provision project portfolio management , R3.5.4 Budget control , R3.5.5 Skill employees , R3.5.6 Access to the network of system owners , R3.5.7 Influence on daily work of management layers , ,5 R3.5.8 Available communication channels , R3.5.9 Advice from central information managers , R Education of end users , Total ,5 1, ,3 4 2,5 4 R3.6 Other activities R3.6.1 Involvement in innovation of information system , R3.6.2 Alignment central information management , R3.6.3 Involvement with contracts and SLAs , ,25 Total , Total R , ,25 R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 General requirements R4.1.1 Division of management of information system in predefined layers of functional management, 3 application coordination, 3 application management, 3 technical management 2 and hosting and 2 housing , R4.1.2 Application coordination ,2 1,5 1 3 R4.1.3 Different layers are offered to the system owners as services by the different relevant departments , ,25 R4.1.4 System owner responsible for all layers , Total ,5 2 3,5 3 2,5 2, , ,75 R4.2 Business process management requirements R4.2.1 Business process management is done internally , R4.2.2 Business process management designed according to BiSL , R4.2.3 System owner is part of the controlling part of business information management layer ,8 3 1,5 3,75 R4.2.4 Business process managers are working on an operational level , ,5 R4.2.5 Business process managers are placed as close to the system owner as possible , R4.2.6 Replacement of business information manager(s) , R4.2.7 Business information managers have an advising role , R4.2.8 Business process managers do not perform application or technical management , ,5 R4.2.9 Appointment of key-users depending on the need for key-users of the IS , R Alignment of operational processes with key-users , ,5 R Key-users part of business process management , R Regular meetings with business process management with a frequency that corresponds with 4 the dynamicity of the 4 IS , ,25 Total , , , R4.3 Requirements regarding other management layers R4.3.1 Business process management controls the other layers ,0 3 1,5 4 R4.3.2 The other layers are managed by ICT Services , R4.3.3 The system owner is responsible for the service level contracts and SLAs , R4.3.4 ICT Services handles all contracts and involves all relevant system owners ,3 1,5 1 3,25 R4.3.5 ICT Services takes care in providing sufficient available and qualified application management, 3 technical management 3 and hosting and housing 3 to fulfil demands of 3 the system owner , Total ,5 2,3 1 3 R ,5 3 2, ,3 2,5 1 3 R , , Alle uitgangspunten , IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables T.M. van Bremen - University of Amsterdam

67 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS1 Name Kaartmanagementsysteem Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting R3 Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Responsibility for basic information Systeemeigenaar Functioneel beheerder R3.1.1 List of information provision services and its users Nee Nee 1 Toegezegd. Niet gevalideerd. R3.1.2 Architectural model Ja Ja 5 Beschikbaar. Gevalideerd. R3.1.3 Information on involved parties Nee Nee 1 Leveranciers per systeem. Niet voor elk subsysteem gevalideerd. Total 1 3 R3.2 Responsibility for management of IS R3.2.1 Responsibility for the complete chain of management 3 3 R3.2.2 Role allocation 4 4 R3.2.3 Escalation scenarios Nee 2 2 R3.2.4 Crisis plans Nee R3.2.5 Update and upgrade management Nee 2 2 Total 3 5 Applicatiebeheer uitbesteed aan ICTS. De rest van de verantwoordelijkheid goed te dragen. Externe partijen zijn erbij betrokken. Per systeem verschilt het of er contracten zijn of niet. Scholing is niet gestructureerd geregeld. Verschil in kennisniveau. Basiskwalificatie. Wel opleiding, geen verplichtingen. Rollen zijn helder belegd. Splitsing tussen functioneel en applicatiebeheer expliciet. Niet vastgelegd. Wel voor incident- en probleemmanagement, wijziging- en configuratiebeheer. Er zijn escalatieschema's bekend, maar niet vastgelegd, wel in gebruik. Crisisplannen zijn er en gedocumenteerd. Echter is dit niet bekend in alle lagen van de beheerorganisatie. FB: Crises deels binnen het systeem afgevangen. Regulier worden er updates en upgrades gedaan. Soms is dit vastgelegd in een releaseplan, maar dit is bij sommige systemen niet nodig. R3.3 Responsibility for alignment and agreements with other parties R3.3.1 Alignment with user organisation 2 2 R3.3.2 Control over change management Nee 3 3 R3.3.3 Agreements with user organization on control over change management Nee 3 3 R3.3.4 Alignment with system owners of other information systems which have ISNee 3 3 interfaces with the R3.3.5 Written agreements with other units when the management is distributed 2 2 Total 5 3 Éénmaal per kwartaal overleg tussen FB'er en leveranciers diensten. Niet door SE'er. Zo veel mogelijk volgens BiSL. SE direct betrokken. Wijzigingen worden overlegd. SE gaat uiteindelijk over alle wijzigingen. Overleg met FB-groep, applicatiecoördinator en evt. leveranciers. Afspraken bestaan informeel en gebeuren incidenteel, maar ze zijn er wel. Niet voor alle systemen. Capaciteitsprobleem. R3.4 Responsibility for the communication with end users R3.4.1 Call-routing schematics Ja 4 4 R3.4.2 Communication protocol for the communication with end users Nee 3 3 R3.4.3 Maintenance plans Nee 3 3 Total 3 3 Call-routering is vastgelegd, ook in een document. Deze is bekend bij gebruikers, echter gaan sommigen direct naar de afdeling i.p.v. Servicedesk. Qua efficientie krijgt de call-routering een 8. Geen standaardplan. Er wordt wel gecommuniceerd, maar per issue. Niets is vastgelegd. Het meeste gaat via afdeling communicatie. Er zijn onderhoudsplannen, maar niet voor alle systemen. Deze zijn gedocumenteerd en alleen in te zien door systeembeheerder en Koen (coördinatie functioneel beheer) R3.5 Conditions for quality fulfilment of system ownership R3.5.1 Basic knowledge of information management and systems 4 4 R3.5.2 Basic knowledge of architecture 4 4 R3.5.3 Relation with the higher level i-governance and information provision project portfolio management 4 4 Ja en nee. Budget voor onderhoud en beheer. Apart begroot. R3.5.4 Budget control 2 2 Nee. Aantal panden en gebruikers stijgt. Capaciteit niet. R3.5.5 Skill employees 2 2 R3.5.6 Access to the network of system owners 4 4 Ja, CIM. Wordt gebruik van gemaakt. R3.5.7 Influence on daily work of management 5 5 Zeker. Heel direct. FB: Heel veel gaat via mij, maar als het belangrijker is -> SE. layers 4 Heeft noodzakelijke communicatiekanalen. Soms afhankelijkheden, bijv. voor comm. met studenten. R3.5.8 Available communication channels 4 4 Nog niet aan de orde geweest. SE zou er wel gebruik van maken. R3.5.9 Advice from central information managers 3 3 Niet veel scholing vereist bij dit systeem, betreft het gebruik van een pas. R Education of end users 4 4 Total 10 4 R3.6 Other activities Direct betrokken en voldoende op de hoogte van alle nieuwe ontwikkelingen. R3.6.1 Involvement in innovation of information system 3 3 Zeer goede afstemming en indirect betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken. R3.6.2 Alignment central information management 4 4 R3.6.3 Involvement with contracts and SLAs 3 3 Nee, is nog te recent. Total 3 3 Total R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 General requirements R4.1.1 Division of management of information system in predefined layers of functional management, application coordination, application management, technical 3 management and hosting and housing 3 R4.1.2 Application coordination 4 4 R4.1.3 Different layers are offered to the system owners as services by the different relevant departments 3 3 R4.1.4 System owner responsible for all layers 2 2 Total 4 3 Rollen zijn gescheiden, alleen applicatie en technisch beheer zijn samen. Hosting kan binnenshuis of erbuiten zijn, dit verschilt per systeem. Erg afhankelijk van externe partij wanneer een laag is uitbesteed. Applicatiebeheer is niet uitbesteed, coördinatie ligt bij ICTS. Technisch en applicatiebeheer is belegd bij ICTS. Soms ook hosting, dit ligt er aan om welk systeem het gaat. Nee, ligt bij ICTS. Hosting en KMS is extern. Verantwoordelijk voor uitvoering van contract. R4.2 Business process management requirements R4.2.1 Business process management is done internally 5 5 Ja. Meerdere mensen die FB uitvoeren. R4.2.2 Business process management designed according to BiSL 5 5 Ja, destijds geïmplementeerd door Sanne. R4.2.3 System owner is part of the controlling part of business information management layer 4 4 R4.2.4 Business process managers are working on an operational level 4 4 Ja. Mag wel minder uitvoerend (-> huismeestertaken). R4.2.5 Business process managers are placed as close to the system owner as possible 4 4 Zit een coördinator tussen. Wel direct contact en leidinggevende. R4.2.6 Replacement of business information manager(s) 5 5 Intern belegd. Kunnen elkaars rollen overnemen. FB: Uitgangspunt is dat iedereen alles zou moeten kunnen, dat is nu voor ong. 70% gerealiseerd. KMS kan iedereen. R4.2.7 Business information managers have an advising role 2 2 Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt te weinig. R4.2.8 Business process managers do not perform application or technical management 5 4 Belegd bij ICTS. FB: Ook applicatiebeheer. Soms technisch beheer. 2 Niet benoemd. Input users puur via eventuele individuele calls. R4.2.9 Appointment of key-users depending on the need for key-users of the IS Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. R Alignment of operational processes with key-users 3 3 R Key-users part of business process management 3 3 Geen decentrale belegging. R Regular meetings with business process management 4 4 Ja, maandelijks. Ook met applicatiebeheerder. with a frequency that corresponds with the dynamicity of the IS 4 Total 12 4 R4.3 Requirements regarding other management layers R4.3.1 Business process management controls the other layers R4.3.2 The other layers are managed by ICT Services 3 3 T.M. van Bremen - University of Amsterdam R4.3.3 The system owner is responsible for the service level contracts and SLAs 2 2 R4.3.4 ICT Services handles all contracts and involves all relevant system owners 3 3 R4.3.5 ICT Services takes care in providing sufficient available and qualified application management, technical management and hosting and housing to fulfil demands 3 of the system owner 3 Total R R4 Ja, is sturend. ICTS naar aanleiding van wens, wijziging of probleem aan tafel met leverancier. Dit gaat op initiatief van FB. Applicatiebeheer neem niet onafhankelijk van FB besluiten. FB: Meestal wel, maar technisch beheer heeft ook zijn eigen agenda. Niet verantwoordelijk voor diensten belegd bij ICTS. Wel verantwoordelijk. Overeenkomsten niet vastgelegd. Contracten liggen bij beide (FS en ICTS). Capaciteitsprobleem ICTS. Afspraken zijn er wel, maar niet vastgelegd. In verhouding met capaciteit wordt er redelijk aan de afspraken voldaan.

68 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS2 Name Toegangsbeheersysteem Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 Toegezegd. Niet gevalideerd. R3.1.2 Architectuurplaat Ja Ja 5 Beschikbaar. Gevalideerd. R3.1.3 Informatie over betrokkenen Nee Nee 1 Leveranciers per systeem. Niet voor elk subsysteem gevalideerd. Totaal 1 3 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 3 3 R3.2.2 Belegging rollen 4 4 R3.2.3 Escalatieschema s Nee 2 2 R3.2.4 Crisisplan Nee R3.2.5 Updates en upgrades Nee 2 2 Totaal 2 5 Applicatiebeheer uitbesteed aan ICTS. De rest van de verantwoordelijkheid goed te dragen. Externe partijen zijn erbij betrokken. Per systeem verschilt het of er contracten zijn of niet. Scholing is niet gestructureerd geregeld. Verschil in kennisniveau. Basiskwalificatie. Wel opleiding, geen verplichtingen. Rollen zijn helder belegd. Splitsing tussen functioneel en applicatiebeheer expliciet. Niet vastgelegd. Wel voor incident- en probleemmanagement, wijziging- en configuratiebeheer. Er zijn escalatieschema's bekend, maar niet vastgelegd, wel in gebruik. Crisisplannen zijn er en gedocumenteerd. Echter is dit niet bekend in alle lagen van de beheerorganisatie. FB: Crises deels binnen het systeem afgevangen. Regulier worden er updates en upgrades gedaan. Soms is dit vastgelegd in een releaseplan, maar dit is bij sommige systemen niet nodig. R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 2 2 R3.3.2 Regie wijzigingsbeheer Nee 3 3 R3.3.3 Afspraken wijzigingsbeheer Nee 3 3 R3.3.4 Afpraken met relevante SE'en Nee 3 3 R3.3.5 Afspraken met andere eenheden 2 2 Totaal 3 5 Éénmaal per kwartaal overleg tussen FB'er en leveranciers diensten. Niet door SE'er. Zo veel mogelijk volgens BiSL. SE direct betrokken. Wijzigingen worden overlegd. SE gaat uiteindelijk over alle wijzigingen. Overleg met FB-groep, applicatiecoördinator en evt. leveranciers. Afspraken bestaan informeel en gebeuren incidenteel, maar ze zijn er wel. Niet voor alle systemen. Capaciteitsprobleem. R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 4 4 R3.4.2 Communicatieprotocol Nee 3 3 R3.4.3 Onderhoudsplannen Nee 3 3 Totaal 3 3 Call-routering is vastgelegd, ook in een document. Deze is bekend bij gebruikers, echter gaan sommigen direct naar de afdeling i.p.v. Servicedesk. Qua efficientie krijgt de call-routering een 8. Geen standaardplan. Er wordt wel gecommuniceerd, maar per issue. Niets is vastgelegd. Het meeste gaat via afdeling communicatie. Er zijn onderhoudsplannen, maar niet voor alle systemen. Deze zijn gedocumenteerd en alleen in te zien door systeembeheerder en Koen (coordinatie functioneel beheer) R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 Ja en nee. Budget voor onderhoud en beheer. Apart begroot. R3.5.4 Voldoende beschikbaar Budget 2 2 Nee. Aantal panden en gebruikers stijgt. Capaciteit niet. R3.5.5 Voldoende deskundig personeel 2 2 R3.5.6 Toegang netwerk systeemeigenaren 4 4 Ja, CIM. Wordt gebruik van gemaakt. R3.5.7 Invloed werkzaamheden 5 5 Zeker. Heel direct. FB: Heel veel gaat via mij, maar als het belangrijker is -> SE. 4 Heeft noodzakelijke communicatiekanalen. Soms afhankelijkheden, bijv. voor comm. met studenten. R3.5.8 Noodzakelijke communicatiekanalen 4 4 Nog niet aan de orde geweest. SE zou er wel gebruik van maken. R3.5.9 Advies centrale informatiemanagers 3 3 Niet veel scholing vereist bij dit systeem, betreft het gebruik van een pas. R Geschoolde gebruikers 4 4 Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt Direct betrokken en voldoende op de hoogte van alle nieuwe ontwikkelingen. R3.6.1 Betrokkenheid innovatie 3 3 Zeer goede afstemming en indirect betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken. R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten en SLA's 3 3 Nee, is nog te recent. Totaal 3 3 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 3 3 R4.1.2 Invulling applicatiecoördinatie 4 4 R4.1.3 Beheerlagen als diensten 3 3 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 2 2 Totaal 3 4 Rollen zijn gescheiden, alleen applicatie en technisch beheer zijn samen. Hosting kan binnenshuis of erbuiten zijn, dit verschilt per systeem. Erg afhankelijk van externe partij wanneer een laag is uitbesteed. Applicatiebeheer is niet uitbesteed, coördinatie ligt bij ICTS. Technisch en applicatiebeheer is belegd bij ICTS. Soms ook hosting, dit ligt er aan om welk systeem het gaat. Nee, ligt bij ICTS. Hosting en KMS is extern. Verantwoordelijk voor uitvoering van contract. R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Ja. Meerdere mensen die FB uitvoeren. R4.2.2 FB ingericht volgens BiSL 5 5 Ja, destijds geïmplementeerd door Sanne. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 4 4 R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 Ja. Mag wel minder uitvoerend (-> huismeestertaken). R4.2.5 Afstand functioneel beheer en systeemeigenaar 4 4 Zit een coördinator tussen. Wel direct contact en leidinggevende. R4.2.6 Vervanging functioneel beheerder 4 4 Intern belegd. Kunnen elkaars rollen overnemen. FB: Uitgangspunt is dat iedereen alles zou moeten kunnen, dat is nu voor ong. 70% gerealiseerd. Salto (HvA) kan iedereen kan iedereen. R4.2.7 Rolbelegging functioneel beheerder 2 2 Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt te weinig. R4.2.8 Geen applicatiebeheer of technisch beheer 5 4 Belegd bij ICTS. FB: Ook applicatiebeheer. Soms technisch beheer. 2 Niet benoemd. Input users puur via eventuele individuele calls. R4.2.9 Key-users benoemd Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. R Afstemming operationele BiSL processen met key-users 3 3 R Key-users/decentraal FB'er onderdeel functioneel beheer 3 3 Geen decentrale belegging. R Overleg SE met FB'er 4 4 Ja, maandelijks. Ook met applicatiebeheerder. 4 Totaal 12 4 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 5 5 R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 2 2 T.M. van Bremen - University of Amsterdam R4.3.4 ICTS verantwoordelijk voor contractmanagement 3 3 R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Totaal 3 6 Totaal R Alle uitgangspunten 51 3 Ja, is sturend. ICTS naar aanleiding van wens, wijziging of probleem aan tafel met leverancier. Dit gaat op initiatief van FB. Applicatiebeheer neem niet onafhankelijk van FB besluiten. FB: Meestal wel, maar technisch beheer heeft ook zijn eigen agenda. Niet verantwoordelijk voor diensten belegd bij ICTS. Wel verantwoordelijk. Overeenkomsten niet vastgelegd. Contracten liggen bij beide (FS en ICTS). Capaciteitsprobleem ICTS. Afspraken zijn er wel, maar niet vastgelegd. In verhouding met capaciteit wordt er redelijk aan de afspraken voldaan.

69 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS3 Name Uploaden pasfoto's medewerkers en studenten Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 Toegezegd. Niet gevalideerd. R3.1.2 Architectuurplaat Ja Ja 5 Beschikbaar. Gevalideerd. R3.1.3 Informatie over betrokkenen Nee Nee 1 Leveranciers per systeem. Niet voor elk subsysteem gevalideerd. Totaal 1 3 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 3 3 R3.2.2 Belegging rollen 4 4 R3.2.3 Escalatieschema s Nee 2 2 R3.2.4 Crisisplan Nee R3.2.5 Updates en upgrades Nee 2 2 Totaal 3 5 Applicatiebeheer uitbesteed aan ICTS. De rest van de verantwoordelijkheid goed te dragen. Externe partijen zijn erbij betrokken. Per systeem verschilt het of er contracten zijn of niet. Scholing is niet gestructureerd geregeld. Verschil in kennisniveau. Basiskwalificatie. Wel opleiding, geen verplichtingen. Rollen zijn helder belegd. Splitsing tussen functioneel en applicatiebeheer expliciet. Niet vastgelegd. Wel voor incident- en probleemmanagement, wijziging- en configuratiebeheer. Er zijn escalatieschema's bekend, maar niet vastgelegd, wel in gebruik. Crisisplannen zijn er en gedocumenteerd. Echter is dit niet bekend in alle lagen van de beheerorganisatie. FB: Crises deels binnen het systeem afgevangen. Regulier worden er updates en upgrades gedaan. Soms is dit vastgelegd in een releaseplan, maar dit is bij sommige systemen niet nodig. R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 2 2 R3.3.2 Regie wijzigingsbeheer Nee 3 3 R3.3.3 Afspraken wijzigingsbeheer Nee 4 4 R3.3.4 Afpraken met relevante SE'en Nee 3 3 R3.3.5 Afspraken met andere eenheden 2 2 Totaal 3 5 Éénmaal per kwartaal overleg tussen FB'er en leveranciers diensten. Niet door SE'er. Zo veel mogelijk volgens BiSL. SE direct betrokken. Wijzigingen worden overlegd. SE gaat uiteindelijk over alle wijzigingen. Overleg met FB-groep, applicatiecoördinator en evt. leveranciers. Afspraken bestaan informeel en gebeuren incidenteel, maar ze zijn er wel. Niet voor alle systemen. Capaciteitsprobleem. R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 4 4 R3.4.2 Communicatieprotocol Nee 3 3 R3.4.3 Onderhoudsplannen Nee 3 3 Totaal 3 3 Call-routering is vastgelegd, ook in een document. Deze is bekend bij gebruikers, echter gaan sommigen direct naar de afdeling i.p.v. Servicedesk. Qua efficientie krijgt de call-routering een 8. Geen standaardplan. Er wordt wel gecommuniceerd, maar per issue. Niets is vastgelegd. Het meeste gaat via afdeling communicatie. Er zijn onderhoudsplannen, maar niet voor alle systemen. Deze zijn gedocumenteerd en alleen in te zien door systeembeheerder en Koen (coordinatie functioneel beheer) R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 Ja en nee. Budget voor onderhoud en beheer. Apart begroot. R3.5.4 Voldoende beschikbaar Budget 2 2 Nee. Aantal panden en gebruikers stijgt. Capaciteit niet. R3.5.5 Voldoende deskundig personeel 2 2 R3.5.6 Toegang netwerk systeemeigenaren 4 4 Ja, CIM. Wordt gebruik van gemaakt. R3.5.7 Invloed werkzaamheden 5 5 Zeker. Heel direct. FB: Heel veel gaat via mij, maar als het belangrijker is -> SE. 4 Heeft noodzakelijke communicatiekanalen. Soms afhankelijkheden, bijv. voor comm. met studenten. R3.5.8 Noodzakelijke communicatiekanalen 4 4 Nog niet aan de orde geweest. SE zou er wel gebruik van maken. R3.5.9 Advies centrale informatiemanagers 3 3 Niet veel scholing vereist bij dit systeem, betreft het gebruik van een pas. R Geschoolde gebruikers 4 4 Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt Direct betrokken en voldoende op de hoogte van alle nieuwe ontwikkelingen. R3.6.1 Betrokkenheid innovatie 3 3 Zeer goede afstemming en indirect betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken. R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten en SLA's 3 3 Nee, is nog te recent. Totaal 3 3 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 3 3 R4.1.2 Invulling applicatiecoördinatie 4 4 R4.1.3 Beheerlagen als diensten 3 3 Rollen zijn gescheiden, alleen applicatie en technisch beheer zijn samen. Hosting kan binnenshuis of erbuiten zijn, dit verschilt per systeem. Erg afhankelijk van externe partij wanneer een laag is uitbesteed. Applicatiebeheer is niet uitbesteed, coördinatie ligt bij ICTS. Technisch en applicatiebeheer is belegd bij ICTS. Soms ook hosting, dit ligt er aan om welk systeem het gaat. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 2 2 Totaal 4 3 Nee, ligt bij ICTS. Hosting en KMS is extern. Verantwoordelijk voor uitvoering van contract. R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Ja. Meerdere mensen die FB uitvoeren. R4.2.2 FB ingericht volgens BiSL 5 5 Ja, destijds geïmplementeerd door Sanne. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 4 4 R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 Ja. Mag wel minder uitvoerend (-> huismeestertaken). R4.2.5 Afstand functioneel beheer en systeemeigenaar 4 4 Zit een coördinator tussen. Wel direct contact en leidinggevende. R4.2.6 Vervanging functioneel beheerder 4 4 Intern belegd. Kunnen elkaars rollen overnemen. R4.2.7 Rolbelegging functioneel beheerder 2 2 Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt te weinig. R4.2.8 Geen applicatiebeheer of technisch beheer 5 4 Belegd bij ICTS. FB: Ook applicatiebeheer. Soms technisch beheer. 2 Niet benoemd. Input users puur via eventuele individuele calls. R4.2.9 Key-users benoemd Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. R Afstemming operationele BiSL processen met key-users 3 3 R Key-users/decentraal FB'er onderdeel functioneel beheer 3 3 Geen decentrale belegging. R Overleg SE met FB'er 4 4 Ja, maandelijks. Ook met applicatiebeheerder. 4 Totaal 12 4 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 5 5 R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 2 2 R4.3.4 ICTS verantwoordelijk voor contractmanagement 3 3 R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Totaal 6 3 Ja, is sturend. ICTS naar aanleiding van wens, wijziging of probleem aan tafel met leverancier. Dit gaat op initiatief van FB. Applicatiebeheer neem niet onafhankelijk van FB besluiten. FB: Meestal wel, maar technisch beheer heeft ook zijn eigen agenda. Niet verantwoordelijk voor diensten belegd bij ICTS. Wel verantwoordelijk. Overeenkomsten niet vastgelegd. Contracten liggen bij beide (FS en ICTS). Capaciteitsprobleem ICTS. Afspraken zijn er wel, maar niet vastgelegd. In verhouding met capaciteit wordt er redelijk aan de afspraken voldaan. Totaal R Alle uitgangspunten 51 3 T.M. van Bremen - University of Amsterdam

70 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS4 GBS-LWB (HvA) Gebouwbeheersysteem Leeuwenburg Gerben Smit Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 1 Staat in PDC. (*is dat het juiste overzicht?*) R3.1.2 Architectuurplaat Nee Nee Onbekend bij SE. R3.1.3 Informatie over betrokkenen Nee Nee 1 1 Overzicht is in de maak. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 4 4 R3.2.2 Belegging rollen 4 4 R3.2.3 Escalatieschema s Nee R3.2.4 Crisisplan Nee 1 1 R3.2.5 Updates en upgrades Nee Totaal 5 3 Onervaren door recentheid aanstelling. Nu wel duidelijk wat de SE mag, kan en moet. Select aantal mensen mee bezig.' Niet op papier. FB: calimiteitenwijzers Structuur is er nog niet, maar wel gewenst. FB: Weet ik niet, zijn anderen voor R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 4 4 Juiste temperatuur van zalen etc. R3.3.2 Regie wijzigingsbeheer 4 4 Wel bij betrokken. Nog niet veel aan de orde geweest. R3.3.3 Afspraken wijzigingsbeheer 4 4 Wijzigingen worden vastgelegd. R3.3.4 Afpraken met relevante SE'en 4 4 Ja. Bijvoorbeeld met Salto. R3.3.5 Afspraken met andere eenheden 1 1 Technisch beheer zou ICTS moeten (gaan) doen. Totaal 5 4 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja Is er. Zou bekend moeten zijn bij alle gebruikers. FB: Is er wel maar niet bekend bij alle gebruikers R3.4.2 Communicatieprotocol 1 1 Verward met call-routering. R3.4.3 Onderhoudsplannen Ja Ja, zijn beschreven. Totaal 3 4 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 3 3 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar Budget 5 5 Controle over budget (meerjarig). R3.5.5 Voldoende deskundig personeel 5 5 R3.5.6 Toegang netwerk systeemeigenaren 1 1 SE weet niet of er toegang is, maakt er geen gebruik van. R3.5.7 Invloed werkzaamheden Teamleider zit ertussen. FB: Niet direct, teamleider zit er tussen R3.5.8 Noodzakelijke communicatiekanalen 4 4 R3.5.9 Advies centrale informatiemanagers 2 2 Te vakspecialistisch. Ontwikkeling komt uit de business zelf. R Geschoolde gebruikers 4 4 Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 4 4 R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten en SLA's 5 5 Totaal 3 4 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 2 2 Niet echt opgedeeld. R4.1.2 Invulling applicatiecoördinatie FB: regelen via main-contractor R4.1.3 Beheerlagen als diensten 2 2 Zit nog in de transitiefase, juiste rollen moeten aangenomen worden. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 3 3 Als SE daar verantwoordelijk voor Totaal 4 2 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd Ja, bij FS. FB: Ligt bij main-contractors R4.2.2 FB ingericht volgens BiSL 1 1 Nee, kan ook geen sturende processen noemen die ingericht zijn volgens BiSL. R4.2.3 Systeemeigenaar onderdeel sturende laag FB Alleen voor functiewijzigingen. FB: Alles zelf behalve wanneer er hoge kosten mee gemoeid zijn. R4.2.4 FB'er onderdeel uitvoerende laag FB R4.2.5 Afstand functioneel beheer en systeemeigenaar Zit één laagje tussen. Vallen wel onder dezelfde dienst en er is een hierarchische realtie. FB: Niet heel dicht bij. Veel delegeren aan Teamleider. R4.2.6 Vervanging functioneel beheerder Lossen elkaar af. FB: Geen vervaning, wel waarnemer of iemand die handeld zoals FB. R4.2.7 Rolbelegging functioneel beheerder Ja en wordt ook uitgevoerd. FB: een adviserende rol, soms ook bijsturen R4.2.8 Geen applicatiebeheer of technisch beheer Voeren wel technisch en applicatiebeheer uit. FB: main contractor en de subcontractors R4.2.9 Key-users benoemd Niet benoemd. R Afstemming operationele BiSL processen met key-users R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 R Overleg SE met FB'er Bijna nooit, dat doet de teamleider. FB: via teamleider Totaal 12 2 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 2 2 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 R4.3.4 ICTS verantwoordelijk voor contractmanagement R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Totaal 6 3 Totaal R Alle uitgangspunten 51 3 T.M. van Bremen - University of Amsterdam FB: Veel is verouderd, en opzichzelf staand. Applicatiebeheer niet van toepassing Nog niet, gaat wel veranderen. Misschien ondertussen ook wel in beweging Weet niet hoe dat is geborgd. Hoop op één SLA met appendix. Niet voor elk systeem aparte afspraken. Ligt bij verschillende eenheden van FS. Gaat jaren duren, binnenkort mee beginnen. FB: Ik ben verantwoordelijk, ze liggen bij de main-contractor. Interne moet wel meer met ICTS. Afspraken zijn er, weet niet of het vastgelegd is. Voldoen aan afspraken is niet altijd helder.

71 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS5 Name Gebouwbeheersysteem Science Park Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 1 Staat in PDC. (*is dat het juiste overzicht?*) R3.1.2 Architectuurplaat Nee Nee 1 1 Onbekend bij SE. R3.1.3 Informatie over betrokkenen Nee Nee 1 1 Overzicht is in de maak. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 4 4 Onervaren door recentheid aanstelling. Nu wel duidelijk wat de SE mag, kan en moet. R3.2.2 Belegging rollen 4 4 R3.2.3 Escalatieschema s Nee 4 4 Select aantal mensen mee bezig.' Niet op papier. R3.2.4 Crisisplan Nee 1 1 Onbekend bij SE. R3.2.5 Updates en upgrades Nee 1 1 Structuur is er nog niet, maar wel gewenst. Totaal 5 4 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 4 4 Juiste temperatuur van zalen etc. R3.3.2 Regie wijzigingsbeheer Nee 2 2 Wel bij betrokken. Nog niet veel aan de orde geweest. R3.3.3 Afspraken wijzigingsbeheer Nee 2 2 Wijzigingen worden vastgelegd. R3.3.4 Afpraken met relevante SE'en Nee 3 3 Ja. Bijvoorbeeld met Salto. R3.3.5 Afspraken met andere eenheden 1 1 Technisch beheer zou ICTS moeten (gaan) doen. Totaal 5 2 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 4 4 Is er. Zou bekend moeten zijn bij alle gebruikers. R3.4.2 Communicatieprotocol Nee 1 1 Verward met call-routering. R3.4.3 Onderhoudsplannen Nee 2 2 Ja, zijn beschreven. Niet ontvangen. Totaal 3 2 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 3 3 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar Budget 5 5 Controle over budget (meerjarig). R3.5.5 Voldoende deskundig personeel 5 5 R3.5.6 Toegang netwerk systeemeigenaren 1 1 SE weet niet of er toegang is, maakt er geen gebruik van. R3.5.7 Invloed werkzaamheden 2 2 Teamleider zit ertussen. R3.5.8 Noodzakelijke communicatiekanalen 4 4 R3.5.9 Advies centrale informatiemanagers 2 2 Te vakspecialistisch. Ontwikkeling komt uit de business zelf. R Geschoolde gebruikers 4 4 Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 4 4 R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten en SLA's 5 5 Totaal 3 4 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 2 2 Niet echt opgedeeld. R4.1.2 Invulling applicatiecoördinatie 2 2 R4.1.3 Beheerlagen als diensten 2 2 Zit nog in de transitiefase, juiste rollen moeten aangenomen worden. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 3 3 Als SE daar verantwoordelijk voor Totaal 4 2 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Ja, bij FS. R4.2.2 FB ingericht volgens BiSL 1 1 Nee, kan ook geen sturende processen noemen die ingericht zijn volgens BiSL. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 3 3 Alleen voor functiewijzigingen. R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 R4.2.5 Afstand functioneel beheer en systeemeigenaar 3 3 Zit één laagje tussen. Vallen wel onder dezelfde dienst en er is een hierarchische realtie. R4.2.6 Vervanging functioneel beheerder 4 4 Lossen elkaar af. R4.2.7 Rolbelegging functioneel beheerder 5 5 Ja en wordt ook uitgevoerd. R4.2.8 Geen applicatiebeheer of technisch beheer 1 1 Voeren wel technisch en applicatiebeheer uit. R4.2.9 Key-users benoemd 1 1 Niet benoemd. R Afstemming operationele BiSL processen met key-users 1 1 R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 R Overleg SE met FB'er 2 2 Bijna nooit, dat doet de teamleider. Totaal 12 3 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 3 3 R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 2 2 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 R4.3.4 ICTS verantwoordelijk voor contractmanagement 2 2 R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Totaal 6 3 Totaal R Alle uitgangspunten 51 3 Nog niet, gaat wel veranderen. Misschien ondertussen ook wel in beweging Weet niet hoe dat is geborgd. Hoop op één SLA met appendix. Niet voor elk systeem aparte afspraken. Ligt bij verschillende eenheden van FS. Gaat jaren duren, binnenkort mee beginnen. Afspraken zijn er, weet niet of het vastgelegd is. Voldoen aan afspraken is niet altijd helder. T.M. van Bremen - University of Amsterdam

72 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS6 GBS-KMH (HvA) Gebouwbeheersysteem Koetsier-Mantaignehuis Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 1 Staat in PDC. (*is dat het juiste overzicht?*) R3.1.2 Architectuurplaat Nee Nee Onbekend bij SE. R3.1.3 Informatie over betrokkenen Nee Nee 1 1 Overzicht is in de maak. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 4 4 R3.2.2 Belegging rollen 4 4 R3.2.3 Escalatieschema s Nee R3.2.4 Crisisplan Nee 1 1 R3.2.5 Updates en upgrades Nee Totaal 5 4 Onervaren door recentheid aanstelling. Nu wel duidelijk wat de SE mag, kan en moet. Select aantal mensen mee bezig.' Niet op papier. FB: calimiteitenwijzers Structuur is er nog niet, maar wel gewenst. FB: Weet ik niet, zijn anderen voor R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 4 4 Juiste temperatuur van zalen etc. R3.3.2 Regie wijzigingsbeheer Nee 4 4 Wel bij betrokken. Nog niet veel aan de orde geweest. R3.3.3 Afspraken wijzigingsbeheer Nee 4 4 Wijzigingen worden vastgelegd. R3.3.4 Afpraken met relevante SE'en Nee 4 4 Ja. Bijvoorbeeld met Salto. R3.3.5 Afspraken met andere eenheden 1 1 Technisch beheer zou ICTS moeten (gaan) doen. Totaal 5 4 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja Is er. Zou bekend moeten zijn bij alle gebruikers. FB: Is er wel maar niet bekend bij alle gebruikers R3.4.2 Communicatieprotocol Nee 1 1 Verward met call-routering. R3.4.3 Onderhoudsplannen Ja Ja, zijn beschreven. Niet ontvangen. Totaal 3 2 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 3 3 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar Budget 5 5 Controle over budget (meerjarig). R3.5.5 Voldoende deskundig personeel 5 5 R3.5.6 Toegang netwerk systeemeigenaren 1 1 SE weet niet of er toegang is, maakt er geen gebruik van. R3.5.7 Invloed werkzaamheden Teamleider zit ertussen. FB: Niet direct, teamleider zit er tussen R3.5.8 Noodzakelijke communicatiekanalen 4 4 R3.5.9 Advies centrale informatiemanagers 2 2 Te vakspecialistisch. Ontwikkeling komt uit de business zelf. R Geschoolde gebruikers 4 4 Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 4 4 R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten en SLA's 5 5 Totaal 3 4 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 2 2 Niet echt opgedeeld. R4.1.2 Invulling applicatiecoördinatie FB: regelen via main-contractor R4.1.3 Beheerlagen als diensten 2 2 Zit nog in de transitiefase, juiste rollen moeten aangenomen worden. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 3 3 Als SE daar verantwoordelijk voor Totaal 4 2 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd Ja, bij FS. FB: Ligt bij main-contractors R4.2.2 FB ingericht volgens BiSL 1 1 Nee, kan ook geen sturende processen noemen die ingericht zijn volgens BiSL. R4.2.3 Systeemeigenaar onderdeel sturende laag FB Alleen voor functiewijzigingen. FB: Alles zelf behalve wanneer er hoge kosten mee gemoeid zijn. R4.2.4 FB'er onderdeel uitvoerende laag FB R4.2.5 Afstand functioneel beheer en systeemeigenaar Zit één laagje tussen. Vallen wel onder dezelfde dienst en er is een hierarchische realtie. FB: Niet heel dicht bij. Veel delegeren aan Teamleider. R4.2.6 Vervanging functioneel beheerder Lossen elkaar af. FB: Geen vervaning, wel waarnemer of iemand die handeld zoals FB. R4.2.7 Rolbelegging functioneel beheerder Ja en wordt ook uitgevoerd. FB: een adviserende rol, soms ook bijsturen R4.2.8 Geen applicatiebeheer of technisch beheer Voeren wel technisch en applicatiebeheer uit. FB: main contractor en de subcontractors R4.2.9 Key-users benoemd Niet benoemd. R Afstemming operationele BiSL processen met key-users R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 R Overleg SE met FB'er Bijna nooit, dat doet de teamleider. FB: via teamleider Totaal 12 2 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 2 2 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 R4.3.4 ICTS verantwoordelijk voor contractmanagement R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Totaal 6 3 Totaal R Alle uitgangspunten 51 3 T.M. van Bremen - University of Amsterdam FB: Veel is verouderd, en opzichzelf staand. Applicatiebeheer niet van toepassing Nog niet, gaat wel veranderen. Misschien ondertussen ook wel in beweging Weet niet hoe dat is geborgd. Hoop op één SLA met appendix. Niet voor elk systeem aparte afspraken. Ligt bij verschillende eenheden van FS. Gaat jaren duren, binnenkort mee beginnen. FB: Ik ben verantwoordelijk, ze liggen bij de main-contractor. Interne moet wel meer met ICTS. Afspraken zijn er, weet niet of het vastgelegd is. Voldoen aan afspraken is niet altijd helder.

73 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS7 Name SAP Finance and Control Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 Lijst met gebruikers (=autorisaties) R3.1.2 Architectuurplaat Ja Nee 3 3 Wel eens gezien. R3.1.3 Informatie over betrokkenen Nee Nee 2 1 Rollen gekoppeld aan functies. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 1 1 R3.2.2 Belegging rollen 3 3 Rol van ICTS niet duidelijk. R3.2.3 Escalatieschema s Nee. 1 1 R3.2.4 Crisisplan Nee. 1 1 R3.2.5 Updates en upgrades Nee. 1 1 Totaal 5 1 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 1 1 R3.3.2 Regie wijzigingsbeheer Nee 1 1 R3.3.3 Afspraken wijzigingsbeheer Nee 1 1 R3.3.4 Afpraken met relevante SE'en Nee 1 1 R3.3.5 Afspraken met andere eenheden 3 3 Binnen AC. Totaal 5 1 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja Geen idee. FB: Dat gaat via Topdesk. R3.4.2 Communicatieprotocol Nee 1 1 R3.4.3 Onderhoudsplannen Nee 3 3 Er is een onderhoudskalender. Totaal 3 3 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 1 1 R3.5.2 Kennis architectuurprincipes 1 1 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 1 1 R3.5.4 Voldoende beschikbaar Budget 1 1 R3.5.5 Voldoende deskundig personeel 1 1 R3.5.6 Toegang netwerk systeemeigenaren 1 1 R3.5.7 Invloed werkzaamheden 1 1 R3.5.8 Noodzakelijke communicatiekanalen 1 1 R3.5.9 Advies centrale informatiemanagers 1 1 R Geschoolde gebruikers 4 4 Totaal 10 1 Ø Het is net zoals een andere gebruiker dat ik een verzoek indien. Ik heb daar niet direct iets over te zeggen. Voldoende deskundig. Je zou misschien wel een groep mensen ergens heen moeten sturen om meer uit het systeem te kunnen halen. R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 1 1 R3.6.2 Afstemming centraal IM 1 1 R3.6.3 Betrokkenheid contracten en SLA's 1 1 Totaal 3 1 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 2 2 In ieder gevan FB van TB gescheiden. R4.1.2 Invulling applicatiecoördinatie Nee Nee 1 1 R4.1.3 Beheerlagen als diensten 1 1 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Totaal 4 1 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Binnen dezelfde afdeling. R4.2.2 FB ingericht volgens BiSL 1 1 R4.2.3 Systeemeigenaar onderdeel sturende laag FB 1 1 Weet ik niet. FB: Grote lijnen bepalen we het zelf en dat is niet goed. R4.2.4 FB'er onderdeel uitvoerende laag FB 1 1 R4.2.5 Afstand functioneel beheer en systeemeigenaar 1 1 Ø Ik beleef nog helemaal geen rol. Dat blijkt ook wel uit de antwoorden. Het is slechts een aankondiging geweest. R4.2.6 Vervanging functioneel beheerder 3 3 Intern geregeld binnen FB-afdeling. Geen gedetailleerde kennis. R4.2.7 Rolbelegging functioneel beheerder 1 1 R4.2.8 Geen applicatiebeheer of technisch beheer 1 1 R4.2.9 Key-users benoemd 1 1 R Afstemming operationele BiSL processen met key-users 1 1 R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 R Overleg SE met FB'er 1 1 Totaal 12 1 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 1 1 R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 1 1 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 1 1 R4.3.4 ICTS verantwoordelijk voor contractmanagement 5 5 Contracten lopen via ICTS. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 Totaal 6 1 Totaal R Alle uitgangspunten 51 1 T.M. van Bremen - University of Amsterdam

74 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS8 Name SAP Finance and Control Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 Lijst met gebruikers (=autorisaties) R3.1.2 Architectuurplaat Ja Nee 3 3 Wel eens gezien. R3.1.3 Informatie over betrokkenen Nee Nee 2 1 Rollen gekoppeld aan functies. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 1 1 R3.2.2 Belegging rollen 3 3 Rol van ICTS niet duidelijk. R3.2.3 Escalatieschema s Nee. 1 1 R3.2.4 Crisisplan Nee FB: Wij bellen ICTS moet het oplossen. R3.2.5 Updates en upgrades Nee 1 1 Totaal 5 1 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 1 1 R3.3.2 Regie wijzigingsbeheer Nee 1 1 R3.3.3 Afspraken wijzigingsbeheer Nee 1 1 R3.3.4 Afpraken met relevante SE'en Nee 1 1 R3.3.5 Afspraken met andere eenheden 3 3 Binnen AC. Totaal 5 1 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja Geen idee. FB: Dat gaat via Topdesk. R3.4.2 Communicatieprotocol Nee 1 1 R3.4.3 Onderhoudsplannen Nee 3 3 Er is een onderhoudskalender. FB: Onderhoudsplannen noemen we upgrades en die gebeuren periodiek. Daar is een lijst van. Totaal 3 2 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 1 1 R3.5.2 Kennis architectuurprincipes 1 1 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 1 1 R3.5.4 Voldoende beschikbaar Budget 1 1 R3.5.5 Voldoende deskundig personeel 1 1 R3.5.6 Toegang netwerk systeemeigenaren 1 1 R3.5.7 Invloed werkzaamheden 1 1 R3.5.8 Noodzakelijke communicatiekanalen 1 1 R3.5.9 Advies centrale informatiemanagers 1 1 R Geschoolde gebruikers 4 4 Totaal 10 1 Het is net zoals een andere gebruiker dat ik een verzoek indien. Ik heb daar niet direct iets over te zeggen. Voldoende deskundig. Je zou misschien wel een groep mensen ergens heen moeten sturen om meer uit het systeem te kunnen halen. R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 1 1 R3.6.2 Afstemming centraal IM 1 1 R3.6.3 Betrokkenheid contracten en SLA's 1 1 Totaal 3 1 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 2 2 In ieder gevan FB van TB gescheiden. R4.1.2 Invulling applicatiecoördinatie Nee Nee 1 1 R4.1.3 Beheerlagen als diensten 1 1 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Totaal 4 1 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Binnen dezelfde afdeling. R4.2.2 FB ingericht volgens BiSL 1 1 R4.2.3 Systeemeigenaar onderdeel sturende laag FB Weet ik niet. FB: Grote lijnen bepalen we het zelf en dat is niet goed. R4.2.4 FB'er onderdeel uitvoerende laag FB FB: Wij zitten in de uitvoering. R4.2.5 Afstand functioneel beheer en systeemeigenaar 1 1 Ik beleef nog helemaal geen rol. Dat blijkt ook wel uit de antwoorden. Het is slechts een aankondiging geweest. R4.2.6 Vervanging functioneel beheerder 3 3 Intern geregeld binnen FB-afdeling. Geen gedetailleerde kennis. R4.2.7 Rolbelegging functioneel beheerder 1 1 R4.2.8 Geen applicatiebeheer of technisch beheer 1 1 R4.2.9 Key-users benoemd 1 1 R Afstemming operationele BiSL processen met key-users 1 1 R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 R Overleg SE met FB'er 1 1 Totaal 12 1 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen FB: Zou wel moeten, maar is niet altijd het geval. Soms stuurt techniek. R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 1 1 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 1 1 R4.3.4 ICTS verantwoordelijk voor contractmanagement Contracten lopen via ICTS. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 Geen interne contracten. Totaal 6 1 Totaal R Alle uitgangspunten 51 1 T.M. van Bremen - University of Amsterdam

75 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS9 Name Elektronische leeromgeving Name Requirements ID Description Aantal Document beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 Niet bekend -> FB R3.1.2 Architectuurplaat Nee Nee 1 Niet bekend -> FB R3.1.3 Informatie over betrokkenen Nee Nee 1 Niet bekend -> FB Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 1 1 Nee, nog niet officiëel overgedragen. R3.2.2 Belegging rollen 2 2 Functioneel beheerder neemt meeste rollen op zich. Nog geen applicatiecoördinatie. R3.2.3 Escalatieschema s 1 1 Onbekend bij SE. R3.2.4 Crisisplan 2 2 Meeste controle bij functioneel beheerder. R3.2.5 Updates en upgrades 3 3 Vastgelegd, ook t.a.v. bijhorende communicatie. Totaal 5 2 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 2 2 R3.3.2 Regie wijzigingsbeheer Nee 1 1 FB. Eenzijdig gevoel aansluiting werkprocessen. Niet bekend -> FB. Niet bij betrokken, diensteigenaar in combinatie met FB wel. R3.3.3 Afspraken wijzigingsbeheer Nee 1 1 FB voor nodig. Geen idee over afspraken. R3.3.4 Afpraken met relevante SE'en Nee 1 1 Ja, maar met diensteigenaren. Is wel de bedoeling R3.3.5 Afspraken met andere eenheden 2 2 Totaal 5 1 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 3 3 Hetzelfde als incidentmanagement. Is wel iets van een proces. R3.4.2 Communicatieprotocol Nee 1 1 Niet bekend. R3.4.3 Onderhoudsplannen Nee 3 3 Leverancier geeft dit aan. Totaal 3 3 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 3 3 Praktijk anders dan theorie. R3.5.4 Voldoende beschikbaar Budget 1 1 Gaat afdelingshoofd (diensteigenaar) over. R3.5.5 Voldoende deskundig personeel 2 2 Te weinig inzicht over. R3.5.6 Toegang netwerk systeemeigenaren 1 1 Maak er geen gebruik van. Niet het gevoel dat ik er iets mee moet. R3.5.7 Invloed werkzaamheden 1 1 Nu niet. R3.5.8 Noodzakelijke communicatiekanalen 2 2 Moeilijk communiceren met eindgebruiker, moet via communicatie. R3.5.9 Advies centrale informatiemanagers 1 1 Kan er geen antwoord op geven. R Geschoolde gebruikers 3 3 T.a.v. systeem wel. Wel wat te verbeteren t.a.v. werken in een grote organisatie. Oude manier van werken. Andere mindset nodig. Totaal 10 2 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 1 1 Nu niet. R3.6.2 Afstemming centraal IM 3 3 Geen idee over afstemming CIM, wel betrokken bij werkplekken. R3.6.3 Betrokkenheid contracten en SLA's 1 1 Niet met BlackBoard i.v.m. scheiding van afdelingen. Totaal 3 1 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 3 3 Volgens mij gescheiden. R4.1.2 Invulling applicatiecoördinatie Nee Nee 1 1 Applicatiecoordinatie moet nog ingericht worden. R4.1.3 Beheerlagen als diensten 4 4 Ja, behalve applicatiecoordinatie. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Nee Totaal 4 2 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Intern belegd R4.2.2 FB ingericht volgens BiSL 1 1 Geen idee. Vermoed dat er key-users zijn of decentrale FB. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 4 4 Volgens mij doet FB praktisch alles, behalve grote wijzigingen of wanneer er geld mee gemoeid gaat. R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 FB is operationeel, maar door sommige zaken ook tactisch i.v.m. groot aantal studenten als gebruiker. R4.2.5 Afstand functioneel beheer en systeemeigenaar 2 2 Niet genoeg i.v.m. transitie. Afdelingshoofd zit ertussen. R4.2.6 Vervanging functioneel beheerder 1 1 Niet bekend. R4.2.7 Rolbelegging functioneel beheerder 1 1 Niet bekend. R4.2.8 Geen applicatiebeheer of technisch beheer 2 2 Applicatiebeheer niet bekend, vernoed van wel. Technisch bejeer niet. FB alleen op operationeel betrokken bij contractmanagement zou wel moeten. Is nu niet het geval R4.2.9 Key-users benoemd 4 4 Ja, maar kan alleen FB benoemen R Afstemming operationele BiSL processen met key-users 1 1 Niet bekend. R Key-users/decentraal FB'er onderdeel functioneel beheer 3 5 R Overleg SE met FB'er 2 2 Frequentie niet bekend. Totaal 12 2 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 1 1 Geen idee hoe dit in de praktijk is, zou wel zo moeten zijn R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 2 2 Heel ruim R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 1 1 Zou zo moeten zijn. Er is alleen maar een diensteigenaar. R4.3.4 ICTS verantwoordelijk voor contractmanagement 1 1 via de sourcingmanager, onder klantmanagement een andere afdeling R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 Nog in transitie, nu op een andere manier geregeld. Totaal 6 1 Totaal R Alle uitgangspunten 51 1 T.M. van Bremen - University of Amsterdam

76 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS10 Name Mail, agenda en online notities medewerkers UvA /HvA Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 Alleen in dienstencatalogus. R3.1.2 Architectuurplaat Ja Nee 4 Beschikbaar. SE geen weet van. FB: Ja, permanent wijzigingen. Gebruiken methode van microsoft, erg uitgebreid. R3.1.3 Informatie over betrokkenen Nee Nee 2 FB: alle beheertaken zijn belegd. Wel gedocumenteerd, beheer het niet zelf. Totaal 3 2 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 1 1 Nog niet. R3.2.2 Belegging rollen 4 4 Incidentmanagement, wijzigingsbeheer, configuratiebeheer. Geen probleemmanagement. R3.2.3 Escalatieschema s Ja 4 4 Ja, valt onder Code Rood-procedure. R3.2.4 Crisisplan Ja Alleen globaal voor UvA. FB: Staat in het beheerplan. Wordt 'Fire-drill'genoemd. Als die is geregeld heb je ook een crisisplan. R3.2.5 Updates en upgrades Ja Totaal 5 4 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 3 3 FB: JA, gaat via de change-advisor. Breder dan alleen voor deze dienst. Gaan uit van een melding van de leverancier. FB'er verantwoordelijk voor. Aantal keyusers aangesteld. Zouden er meer moeten zijn. Werkproces afstemming gaat reactief en niet pro-actief. R3.3.2 Regie wijzigingsbeheer Nee 3 3 SE alleen betrokken bij major wijzigingen of als er echt escalaties plaatsvinden. R3.3.3 Afspraken wijzigingsbeheer Nee 3 3 Geen afspraken met gebruikersorganisatie. Wel overleg. R3.3.4 Afpraken met relevante SE'en Nee 3 3 Geen afspraken met andere SE'en, wel met FB'ers. R3.3.5 Afspraken met andere eenheden 3 3 Geen afspraken. Speelt binnen ICTS. Totaal 5 3 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 4 4 FB: Sjabloon in Topdesk R3.4.2 Communicatieprotocol Nee 3 3 Geen vastgelegd protocol. Wel een vaste manier van werken. R3.4.3 Onderhoudsplannen Nee 3 3 Ligt bij Microsoft. Totaal 3 3 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 3 3 Praktijk anders dan theorie. R3.5.4 Voldoende beschikbaar budget 4 4 Inzicht bij controller. Voor alles wat nodig is is er budget beschikbaar. R3.5.5 Voldoende deskundig personeel 2 2 Voldoende bechikbaar. Deskundigheid minder geworden door integratie met HvA. R3.5.6 Toegang netwerk systeemeigenaren 1 1 Maak er geen gebruik van. Niet het gevoel dat ik er iets mee moet. R3.5.7 Invloed werkzaamheden Nu niet. FB: eigenlijk niet, formeel wel. Doe niets zonder akkoord van de SE R3.5.8 Noodzakelijke communicatiekanalen 2 2 Moeilijk communiceren met eindgebruiker, moet via communicatie. R3.5.9 Advies centrale informatiemanagers 1 1 Nog niet eerder meegemaakt. R Geschoolde gebruikers 3 3 Nee, daar is dan geen budget voor. Totaal 10 3 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 4 4 R3.6.2 Afstemming centraal IM 4 4 R3.6.3 Betrokkenheid contracten en SLA's 4 4 Totaal 3 4 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 4 4 Is opgedeeld, er is alleen geen applicatiecoördinatie ingericht. R4.1.2 Invulling applicatiecoördinatie 1 1 Niet ingevuld. R4.1.3 Beheerlagen als diensten 2 2 Niet als diensten maar als onderdeel van een IV-dienst. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 3 3 Totaal 4 3 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 R4.2.2 FB ingericht volgens BiSL 1 1 SE: Weet ik niet. R4.2.3 Systeemeigenaar onderdeel sturende laag FB Alles m.b.t. geld en grote wijzigingen naar SE, rest FB. FB: Elk besluit wordt wel op de hoogte gebracht R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 R4.2.5 Afstand functioneel beheer en systeemeigenaar Redelijk dicht, zit een afdelingshoofd tussen. FB: heel dicht, hierarchisch R4.2.6 Vervanging functioneel beheerder Geen vervaning geregeld. FB: Niet structureel geregeeld. Ad-hoc R4.2.7 Rolbelegging functioneel beheerder 4 4 Ja, uitvoerend en adviserend. R4.2.8 Geen applicatiebeheer of technisch beheer Geen applicatiebeheer en technisch beheer activiteiten. R4.2.9 Key-users benoemd Zijn benoemd, verdient wel meer aandacht. R Afstemming operationele BiSL processen met key-users 1 1 SE: Weet ik niet. R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 SE: Weet ik niet. R Overleg SE met FB'er Minstens eenmaal in de maand. FB: structureel maandelijks Totaal 12 4 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 4 4 FB: applicatiebeheer niet ingericht, doen we zelf. R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 Alleen servicemanager. R4.3.4 ICTS verantwoordelijk voor contractmanagement 4 4 Contract met SURF is onveranderlijk. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H Geen afspraken, het valt allemaal onder ICTS. FB: vastgelegd in het beheerplan. Totaal 6 4 Totaal R Alle uitgangspunten 51 3 T.M. van Bremen - University of Amsterdam

77 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS11 Name Digitale leer- en werkomgeving Name Requirements ID Description Aantal Beschikbaar Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst IV-diensten en gebruikers Nee Nee 1 1 Vragen aan FB. R3.1.2 Architectuurplaat Nee Nee 1 1 Vragen aan FB. R3.1.3 Informatie over betrokkenen Nee Nee 1 1 Vragen aan FB. DLWO heeft geen dienstencatalogus. Moet nog geschreven worden. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 3 3 Beleef de verantwoordelijkheid wel, maar kan het niet dragen voor de volledige beheerketen. Meer inzicht is nodig. R3.2.2 Belegging rollen 1 1 R3.2.3 Escalatieschema s Nee 1 1 Mee bezig. R3.2.4 Crisisplan Nee 1 1 Mee bezig. R3.2.5 Updates en upgrades Nee 2 2 Planmatig, vagen aan Edward Zijlstra. Totaal 3 1 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 4 4 Edward Zijlstra op tactisch niveau. Moeilijk te zeggen, iedereern wil aansluiten op DLWO. Goede aansluiting op werkprocessen. R3.3.2 Regie wijzigingsbeheer Nee 2 2 Gewerkt volgens BiSL, nog niet zelf bij bterokken. R3.3.3 Afspraken wijzigingsbeheer Nee 1 1 Geen afspraken. R3.3.4 Afpraken met relevante SE'en Nee 3 3 Er zijn afspraken, maar weet niet of ze vastgelegd zijn --> Edward Zijlstra R3.3.5 Afspraken met andere eenheden 3 3 Ja, bij 2AT. Maar weet niet of ze vastgelegd zijn --> Edward Zijlstra Totaal 3 3 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 1 1 Via Excel sheets, gaat verder wel gebeuren. R3.4.2 Communicatieprotocol Nee 1 1 R3.4.3 Onderhoudsplannen Nee 4 4 Denk het wel. Dus niet zeker van. Totaal 3 1 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 3 3 Kan zeker beter. R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 3 3 Kan beter. R3.5.4 Voldoende beschikbaar Budget 1 1 Geen idee. R3.5.5 Voldoende deskundig personeel 4 4 Genoeg personeel, deskundigheid weet ik niet. R3.5.6 Toegang netwerk systeemeigenaren 1 1 Bestaat volgens mij nog niet. R3.5.7 Invloed werkzaamheden 1 1 Nog niet, hoop straks wel. R3.5.8 Noodzakelijke communicatiekanalen 2 2 vermoed wel, aan Edward vragen. R3.5.9 Advies centrale informatiemanagers 1 1 Nog nooit gezien. R Geschoolde gebruikers 1 1 Geen idee. Totaal 5 2 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 2 2 Niet bij innovatie, wel bij aamelden en aansturen iv-projecten. R3.6.2 Afstemming centraal IM 2 2 Nog in de kinderschoenen. R3.6.3 Betrokkenheid contracten en SLA's 5 5 Ja. Totaal 3 2 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 4 4 R4.1.2 Invulling applicatiecoördinatie 3 3 R4.1.3 Beheerlagen als diensten 1 1 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Totaal 4 2 Applicatie-beheer en -coördinatie bij functioneel beheer. Technisch beheer en h&h 2AT. R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 R4.2.2 FB ingericht volgens BiSL 4 4 Wel ingericht, processen kunnen niet worden benoemd. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 3 3 Fb doet eigenlijk alles. R4.2.4 FB'er onderdeel uitvoerende laag FB 1 1 Nee. R4.2.5 Afstand functioneel beheer en systeemeigenaar 1 1 Edward zit er nog tussen. R4.2.6 Vervanging functioneel beheerder 1 1 Geen idee. R4.2.7 Rolbelegging functioneel beheerder 5 5 Adviserend. R4.2.8 Geen applicatiebeheer of technisch beheer 3 3 Applicatiebeheer denk ik wel, technisch beheer niet. R4.2.9 Key-users benoemd 5 5 Ja, decentraal functioneel beheerders. R Afstemming operationele BiSL processen met key-users 1 1 Bespreken met Edward Zijlstra. R Key-users/decentraal FB'er onderdeel functioneel beheer 3 3 Vragen aan Edward Zijlstra. R Overleg SE met FB'er 5 5 1x per maand. FB gaat onder mij vallen. Synergie creëren. Totaal 12 3 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 4 4 Ik denk het wel. R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 Moet aan gewerkt worden. R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 R4.3.4 ICTS verantwoordelijk voor contractmanagement 4 4 De sourcing managers die onder ICTS vallen. Interne dienstverlening geen contracten. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 4 4 Geregeld door de sourcing manager, ik moet we wel meer vanaf weten. Totaal 3 4 Totaal R Alle uitgangspunten 39 3 T.M. van Bremen - University of Amsterdam

78 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS12 Name Servicemanagementapplicatie tbv AC,FS Bol, Juridische zaken, Bureau Alumni Name Requirements ID Description Aantal Vastgelegd Gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst van IV-diensten Ja Nee 4 Lijst is aanwezig. SE geen weet van. R3.1.2 Architectuurplaat Ja Nee 4 Is aanwezig. R3.1.3 Informatie over betrokkenen Nee Nee 1 Niet vastgelegd, wel bekend. Totaal 3 4 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 5 5 R3.2.2 Belegging rollen 4 4 Geen incidentmanagement vastgelegd. Wijzigingsbeheer niet goed ingericht. Geen apart probleemmanagement. Belegging rollen wel helder. R3.2.3 Escalatieschema s Nee 1 1 Niet beschikbaar. R3.2.4 Crisisplan Nee 1 1 Niet beschikbaar. R3.2.5 Updates en upgrades 3 3 Gebeurt incidenteel. Totaal 5 3 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 4 4 Key-user-overleg + overleg op projectbasis. R3.3.2 Regie wijzigingsbeheer 2 2 Niet volgens BiSL. R3.3.3 Afspraken wijzigingsbeheer Nee 2 2 Geen afspraken. SE is verantwoordelijk. R3.3.4 Afpraken met relevante SE'en Nee 3 3 Op functioneel niveau. Niet vastgelegd, maar weten elkaar te vinden. R3.3.5 Afspraken met andere eenheden Nee 3 3 Niet vastgelegd, alleen op niveau van rollen en rechten van personen. Totaal 5 3 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 3 3 R3.4.2 Communicatieprotocol Nee 2 2 R3.4.3 Onderhoudsplannen Nee 2 2 Totaal 3 2 Call-routering is bekend. SE geen weet van. Niet structureel, vaakgebruikte methoden zijn wel bekend (nieuwsberichten/intranet). Niet bekend bij SE. Wellicht bij appl.coord. R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 3 3 Geen kennis van BiSL. Wel van IS en IM. R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar Budget 4 4 R3.5.5 Voldoende deskundig personeel 4 4 R3.5.6 Toegang netwerk systeemeigenaren 4 4 R3.5.7 Invloed werkzaamheden 5 5 Directe invloed. R3.5.8 Noodzakelijke communicatiekanalen 4 4 R3.5.9 Advies centrale informatiemanagers 2 2 Dat is minimaal. R Geschoolde gebruikers 3 3 Te groot aantal gebruikers om daar voldoende zicht op te hebben. Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 4 4 R3.6.2 Afstemming centraal IM 3 3 R3.6.3 Betrokkenheid contracten en SLA's 1 1 Totaal 3 3 Totaal R Ook betrokken bij aanmelden en aansturen IV-projecten. SE bemoeit zich niet met contracten tussen ICTS en leveranciers. SE vertelt ICTS wat hij wil en gaat ervan uit dat het voor elkaar komt. R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 4 4 Opgedeeld in elke laag. Applicatiebeheer niet zeker. R4.1.2 Invulling applicatiecoördinatie 4 4 Applicatiecoördinator benoemd. R4.1.3 Beheerlagen als diensten 3 3 Formeel niet. Niet beschreven wat er verwacht mag worden, alleen voor TB is dat wel het geval. R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Nee, dat is voor ICTS. Totaal 4 4 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 R4.2.2 FB ingericht volgens BiSL 1 1 R4.2.3 Systeemeigenaar onderdeel sturende laag FB 4 4 R4.2.4 FB'er onderdeel uitvoerende laag FB 4 4 R4.2.5 Afstand functioneel beheer en systeemeigenaar 5 5 Dichter kan niet. R4.2.6 Vervanging functioneel beheerder 4 4 FB'ers vervangen elkaar. Nog niet structureel vastgelegd. R4.2.7 Rolbelegging functioneel beheerder 4 4 R4.2.8 Geen applicatiebeheer of technisch beheer 3 3 Sommige aspecten van applicatiebeheer. In ieder geval geen technisch beheer. R4.2.9 Key-users benoemd 3 3 Niet als onderdeel FB. R Afstemming operationele BiSL processen met key-users 1 1 Geen kennis van BiSL. R Key-users/decentraal FB'er onderdeel functioneel beheer 2 2 R Overleg SE met FB'er 5 5 Wekelijks overleg. Totaal 12 4 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 5 5 R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 2 2 Nee, niet voor uitbesteedde lagen R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 2 2 Leidinggevende van de applicatiecoördinator is daar verantwoordelijk voor. R4.3.4 ICTS verantwoordelijk voor contractmanagement 1 1 Nee, afdeling Inkoop. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 Ja. Applicatiecoördinatie onvoldoende structureel ingeregeld. Totaal 6 2 Totaal R Alle uitgangspunten 51 3 T.M. van Bremen - University of Amsterdam

79 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS13 Name SAP PI broker (ESB):uitwisseling van gegevens tussen bedrijfsapplicaties Name Requirements ID Description Aantal Document beschikbaar Document gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst van IV-diensten Nee Nee 1 Verwijs ik door naar Nataša Rakic. R3.1.2 Architectuurplaat Nee Nee 1 Weet ik ook niet. R3.1.3 Informatie over betrokkenen Nee Nee 1 Er is een zelfde beeld, geen overzicht. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 1 1 "Ik ben officieel nog geen SE". Sta er wel helemaal achter. R3.2.2 Belegging rollen 2 2 Wel helder belegd, juist belegd weet ik niet. Geen weet van de diverse documenten. R3.2.3 Escalatieschema s Nee 2 2 Impliciet, explicit checken. R3.2.4 Crisisplan Nee 1 1 "Benieuwd naar". R3.2.5 Updates en upgrades 2 2 Denk het wel, checken. Totaal 5 2 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 2 2 Gokken of aan Nataša navragen. Denk wel aansluiting op werkprocessen en behoeften. Frequentie gesprekken niet duidelijk. R3.3.2 Regie wijzigingsbeheer 1 1 Niet bekend. R3.3.3 Afspraken wijzigingsbeheer Nee 2 2 Wel afspraken met gebruikersorg. Miet bekend et externe partijen. Afspraken niet bekend. R3.3.4 Afpraken met relevante SE'en Nee 3 3 "Bij mijn weten wel, geen weet van vastgelegde afspraken. Wel de indruk dat er overleg plaatsvindt." R3.3.5 Afspraken met andere eenheden 1 1 Wel uitvoering in andere eenheden, weet niet hoe goed vastgelegd. Totaal 5 2 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 1 1 Bestaat wel, niet bekend bij SE. R3.4.2 Communicatieprotocol Nee 3 3 Inzciht op afstand, verwacht dat het expliciet is afgesproken. R3.4.3 Onderhoudsplannen Nee 1 1 Checken. Totaal 3 1 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar Budget 3 3 R3.5.5 Voldoende deskundig personeel 4 4 R3.5.6 Toegang netwerk systeemeigenaren 5 5 Als dat moet lukt dat. R3.5.7 Invloed werkzaamheden 1 1 Geen zorgen over. R3.5.8 Noodzakelijke communicatiekanalen 5 5 Ja heb ik wel. R3.5.9 Advies centrale informatiemanagers 4 4 Als het nuttig advies is zal ik het zeker doen. R Geschoolde gebruikers 1 1 Niet bekend. Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 1 1 Weinig ervaring mee. R3.6.2 Afstemming centraal IM 3 3 Ja, via i-governance en gaat steeds beter. Nog niet betrokken gaat wel gebeuren. R3.6.3 Betrokkenheid contracten en SLA's 1 1 Ga ik betrokken bij zijn. Totaal 3 1 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 4 4 Applicatiecoordinatie wordt nog ingericht. R4.1.2 Invulling applicatiecoördinatie 1 1 Applicatiecoordinatie wordt nog ingericht. R4.1.3 Beheerlagen als diensten 2 2 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 5 5 Ja, want belegd binnen ICTS. Totaal 4 3 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 Intern belegd. R4.2.2 FB ingericht volgens BiSL 1 1 Niet bekend. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 1 1 Moeilijk te zeggen. R4.2.4 FB'er onderdeel uitvoerende laag FB 5 5 Ja. R4.2.5 Afstand functioneel beheer en systeemeigenaar 3 3 Organisatorisch is anders dan feitelijk. Niet hierarchisch in mijn oogpunt. R4.2.6 Vervanging functioneel beheerder 4 4 Intern gergegeld. R4.2.7 Rolbelegging functioneel beheerder 4 4 Ja en voeren het ook uit. R4.2.8 Geen applicatiebeheer of technisch beheer 3 3 Sommige rollen door dezelfde mensen uitgevoerd. Technisch beheer is beter gescheiden. Operationeel betrokken bij contractmanagement. R4.2.9 Key-users benoemd 4 4 SE: Dat verwacht ik wel. R Afstemming operationele BiSL processen met key-users 1 1 R Key-users/decentraal FB'er onderdeel functioneel beheer 1 1 R Overleg SE met FB'er 1 1 Niet bekend. Totaal 12 3 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 2 2 Verweven met team van Nataša. R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 1 1 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 5 5 Wel verantwoordelijk vanwege afnemers. R4.3.4 ICTS verantwoordelijk voor contractmanagement 1 1 Ligt bij de divisie klant. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 Zijn er niet Totaal 6 1 Niet vastgelegd. Totaal R Alle uitgangspunten 51 2 T.M. van Bremen - University of Amsterdam

80 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables IS14 Name Active Directory 2AT Extern tbv Sharepoint Name Description Aantal Document beschikbaar Document gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 Basisinformatie Systeemeigenaar Functioneel beheerder Lijst van IV-diensten Nee Nee 1 Geen weet van. Architectuurplaat Nee Nee 1 Er is ooit iets getekend. Informatie over betrokkenen Nee Nee 1 Niet bekend. Totaal 3 1 Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen 4 4 Belegging rollen 3 3 Niet geheel duidelijk Escalatieschema s Nee 1 1 Niet bekend. Crisisplan Nee 1 1 Niet bekend. Updates en upgrades 1 1 Niet bekend. Totaal 5 1 Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie 2 2 Niet veel zicht op. Regie wijzigingsbeheer 1 1 Geen zicht op. Afspraken wijzigingsbeheer Nee 1 1 Geen weet van. Afpraken met relevante SE'en Nee 1 1 Geen weet van. Afspraken met andere eenheden 1 1 Geen weet van. Totaal 5 1 Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Nee 1 1 Onbekend. Communicatieprotocol Nee 1 1 Onbekend. Onderhoudsplannen Nee 1 1 Onbekend. Totaal 3 1 Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL 4 4 Kennis architectuurprincipes 4 4 Relatie i-governance en iv-projectportfoliomaangement 4 4 Voldoende beschikbaar budget 1 1 Voldoende deskundig personeel 4 4 Toegang netwerk systeemeigenaren 5 5 Als dat moet lukt dat. Invloed werkzaamheden 1 1 Geen zorgen over. Noodzakelijke communicatiekanalen 4 4 Ja heb ik wel. Advies centrale informatiemanagers 4 4 Als het nuttig advies is zal ik het zeker doen. Geschoolde gebruikers 4 4 Totaal 10 4 Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid innovatie 4 4 Ja, maar via projecten. Afstemming centraal IM 1 1 Niet bekend. Betrokkenheid contracten en SLA's 1 1 Tot nu toe nog niet. Totaal 3 1 Totaal R Uitgangspunten bij het beheer van de informatiesystemen Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS 3 3 FB, AB, AC bij ICTS. TB en H&H bij 2AT Invulling applicatiecoördinatie Nee Nee 3 3 Beheerlagen als diensten 2 2 Verantwoordelijkheid verschillende beheerlagen 2 2 In de toekomst meer. Totaal 4 3 Uitgangspunten m.b.t. functioneel beheer FB intern belegd 3 3 FB ingericht volgens BiSL 2 2 SE: Volgens mij wel. Systeemeigenaar onderdeel sturende laag FB 1 1 Onduidelijk FB'er onderdeel uitvoerende laag FB 3 3 Afstand functioneel beheer en systeemeigenaar 2 2 Nog niet bekend. Vervanging functioneel beheerder 2 2 Geen weet van. Rolbelegging functioneel beheerder 3 3 Geen applicatiebeheer of technisch beheer 2 2 Technisch beheer in ieder geval niet. Key-users benoemd 1 1 Geen weet van. Afstemming operationele BiSL processen met key-users 1 1 Niet benoemd. Key-users/decentraal FB'er onderdeel functioneel beheer 3 3 n.v.t. Overleg SE met FB'er 1 1 Nooit overleg. Totaal 12 2 Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen 1 1 Geen weet van. SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 1 1 Geen overeenkomsten vastgelegd. ICTS verantwoordelijk voor contractmanagement 1 1 Onduidelijk. Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Niet vastgelegd. Wordt wel aan verwachtingen voldaan. Totaal 6 1 Totaal R Alle uitgangspunten 51 2 T.M. van Bremen - University of Amsterdam

81 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS15 Name Active Directory 2AT Extern tbv Sharepoint Name Requirements ID Description Aantal Document beschikbaar Document gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst van IV-diensten Nee Nee 1 Geen weet van. R3.1.2 Architectuurplaat Nee Nee 1 Er is ooit iets getekend. R3.1.3 Informatie over betrokkenen Nee Nee 1 Niet bekend. Totaal 3 1 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 4 4 R3.2.2 Belegging rollen 3 3 Niet geheel duidelijk R3.2.3 Escalatieschema s Nee 1 1 Niet bekend. R3.2.4 Crisisplan Nee 1 1 Niet bekend. R3.2.5 Updates en upgrades 1 1 Niet bekend. Totaal 5 1 R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 2 2 Niet veel zicht op. R3.3.2 Regie wijzigingsbeheer 1 1 Geen zicht op. R3.3.3 Afspraken wijzigingsbeheer Nee 1 1 Geen weet van. R3.3.4 Afpraken met relevante SE'en Nee 1 1 Geen weet van. R3.3.5 Afspraken met andere eenheden 1 1 Geen weet van. Totaal 5 1 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Nee 1 1 Onbekend. R3.4.2 Communicatieprotocol Nee 1 1 Onbekend. R3.4.3 Onderhoudsplannen Nee 1 1 Onbekend. Totaal 3 1 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 4 4 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar budget 1 1 R3.5.5 Voldoende deskundig personeel 4 4 R3.5.6 Toegang netwerk systeemeigenaren 5 5 Als dat moet lukt dat. R3.5.7 Invloed werkzaamheden 1 1 Geen zorgen over. R3.5.8 Noodzakelijke communicatiekanalen 4 4 Ja heb ik wel. R3.5.9 Advies centrale informatiemanagers 4 4 Als het nuttig advies is zal ik het zeker doen. R Geschoolde gebruikers 4 4 Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 4 4 Ja, maar via projecten. R3.6.2 Afstemming centraal IM 1 1 Niet bekend. R3.6.3 Betrokkenheid contracten en SLA's 1 1 Tot nu toe nog niet. Totaal 3 1 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 3 3 FB, AB, AC bij ICTS. TB en H&H bij 2AT R4.1.2 Invulling applicatiecoördinatie Nee Nee 3 3 R4.1.3 Beheerlagen als diensten 2 2 R4.1.4 Verantwoordelijkheid verschillende beheerlagen 2 2 In de toekomst meer. Totaal 4 3 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 3 3 R4.2.2 FB ingericht volgens BiSL 2 2 SE: Volgens mij wel. R4.2.3 Systeemeigenaar onderdeel sturende laag FB 1 1 Onduidelijk R4.2.4 FB'er onderdeel uitvoerende laag FB 3 3 R4.2.5 Afstand functioneel beheer en systeemeigenaar 2 2 Nog niet bekend. R4.2.6 Vervanging functioneel beheerder 2 2 Geen weet van. R4.2.7 Rolbelegging functioneel beheerder 3 3 R4.2.8 Geen applicatiebeheer of technisch beheer 2 2 Technisch beheer in ieder geval niet. R4.2.9 Key-users benoemd 1 1 Geen weet van. R Afstemming operationele BiSL processen met key-users 1 1 Niet benoemd. R Key-users/decentraal FB'er onderdeel functioneel beheer 3 3 n.v.t. R Overleg SE met FB'er 1 1 Nooit overleg. Totaal 12 2 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 1 1 Geen weet van. R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 1 1 Geen overeenkomsten vastgelegd. R4.3.4 ICTS verantwoordelijk voor contractmanagement 1 1 Onduidelijk. R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 3 3 Niet vastgelegd. Wordt wel aan verwachtingen voldaan. Totaal 6 1 Totaal R Alle uitgangspunten 51 2 T.M. van Bremen - University of Amsterdam

82 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS16 Name Studentinformatiesysteem (HvA) Name Requirements ID Description Aantal Document beschikbaar Document gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst van IV-diensten Ja Ja 5 R3.1.2 Architectuurplaat Ja Ja 5 R3.1.3 Informatie over betrokkenen Ja Ja 5 Totaal 3 5 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 5 5 R3.2.2 Belegging rollen 5 5 R3.2.3 Escalatieschema s Nee 4 4 R3.2.4 Crisisplan Nee 4 4 R3.2.5 Updates en upgrades 4 4 Totaal 5 4 Wel bekend, niet altijd even goed vastgelegd. Niet veel onderscheid met incidentmanagement. R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 5 5 Systeemeigenaren, verveolgens leden can het college van bestuur in het programma van eigenaren. Samen met expertisecentrum voorleggen. R3.3.2 Regie wijzigingsbeheer 5 5 Volgens BiSL en zelf bij betrokken. R3.3.3 Afspraken wijzigingsbeheer Ja 5 5 Beheerdocumenten R3.3.4 Afpraken met relevante SE'en Nee 5 5 Technische werkgroep TAO R3.3.5 Afspraken met andere eenheden 5 5 FB is mijn afdeling, Applicatiebeheer (Expertise Centrum) Utrecht, Technisch Beheer is extern (MCX). Hosting en housing is één partij. Totaal 5 5 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 5 5 R3.4.2 Communicatieprotocol Ja 4 4 Ligt bij communicatieadviseur. R3.4.3 Onderhoudsplannen Ja 5 5 Totaal 3 5 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 2 2 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar budget 5 5 Geld in FTE R3.5.5 Voldoende deskundig personeel 5 5 Zelf opleiden R3.5.6 Toegang netwerk systeemeigenaren 2 2 Nog in de kinderschoenen R3.5.7 Invloed werkzaamheden 5 5 R3.5.8 Noodzakelijke communicatiekanalen 4 4 UvA d.m.v. communities is prima. Naar de eindgebruiker Twitter en websites R3.5.9 Advies centrale informatiemanagers 2 2 Betrek ze wel bij ontwikkelingen, zij informeren mij niet. Kort lijntje R Geschoolde gebruikers 3 3 Niet op alle terreinen. Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 5 5 R3.6.2 Afstemming centraal IM 5 5 Bij werkplekken ook betrokken, maar als laatste R3.6.3 Betrokkenheid contracten en SLA's 3 3 Niet ICTS, wel campsolutions Totaal 3 5 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 4 4 Ja, behalve technisch beheer en H&H R4.1.2 Invulling applicatiecoördinatie 1 1 Geen applicatiecoordinatie R4.1.3 Beheerlagen als diensten 1 1 Nog niets aangeboden als dienst R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Totaal 4 1 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 R4.2.2 FB ingericht volgens BiSL 1 1 Geen idee, BiSL geen eerste voorkeur R4.2.3 Systeemeigenaar onderdeel sturende laag FB 3 3 Binnen eigen verantwoordelijkheden en takenpakket R4.2.4 FB'er onderdeel uitvoerende laag FB 5 5 Sturend en strategisch R4.2.5 Afstand functioneel beheer en systeemeigenaar 5 5 Zie ze elke dag, hierarchisch R4.2.6 Vervanging functioneel beheerder 5 5 Op iedere taak die er is, is er een tweede en derde. R4.2.7 Rolbelegging functioneel beheerder 5 5 Adviserend R4.2.8 Geen applicatiebeheer of technisch beheer 5 5 Wel personeel die van alles en nog wat kunnen. Af en toe gebruik van makend. R4.2.9 Key-users benoemd soorten: Inschrijf en Volg R Afstemming operationele BiSL processen met key-users 5 5 harmonisatie principes, wijzigingsbeheerzaken. Werkprocessen. Problemen richting administraties, richting andere lagen van de organisatie. R Key-users/decentraal FB'er onderdeel functioneel beheer 5 5 R Overleg SE met FB'er 5 5 1x per 14 dagen Totaal 12 5 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 4 4 Dat proberen ze wel eens, dat gebeurt wel eens. Dan gedoe over. Niet de bedoeling. R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 Wel verantwoordelijk voor beheerlagen, maar niet via ICTS R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 SLA's zijn oud. SE verantwoordelijk R4.3.4 ICTS verantwoordelijk voor contractmanagement 1 1 Niet bij ICTS R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 ICTS betrekken alleen bij technische keten overleg. Totaal 6 3 Totaal R Alle uitgangspunten 51 5 T.M. van Bremen - University of Amsterdam

83 IT Governance at Higher Education Institutes in Amsterdam Appendix E Results tables ID Name Fuction Owner IS16 Name Studentinformatiesysteem (HvA) Name Requirements ID Description Aantal Document beschikbaar Document gevalideerd Beoordeling Schaal/gradatie/kwaliteitsinschatting Toelichting Verantwoordelijkheid basisinformatie Likert 1-5 R3.1 Basisinformatie Systeemeigenaar Functioneel beheerder R3.1.1 Lijst van IV-diensten Ja Ja 5 R3.1.2 Architectuurplaat Ja Ja 5 R3.1.3 Informatie over betrokkenen Ja Ja 5 Totaal 3 5 R3.2 Verantwoordelijkheid voor het beheer van het IS R3.2.1 Volledige beheerketen 5 5 R3.2.2 Belegging rollen 5 5 R3.2.3 Escalatieschema s Nee 4 4 R3.2.4 Crisisplan Nee 4 4 R3.2.5 Updates en upgrades 4 4 Totaal 5 4 Wel bekend, niet altijd even goed vastgelegd. Niet veel onderscheid met incidentmanagement R3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen R3.3.1 Afstemming gebruikersorganisatie 5 5 Systeemeigenaren, verveolgens leden can het college van bestuur in het programma van eigenaren. Samen met expertisecentrum voorleggen. R3.3.2 Regie wijzigingsbeheer 5 5 Volgens BiSL en zelf bij betrokken. R3.3.3 Afspraken wijzigingsbeheer Ja 5 5 Beheerdocumenten. R3.3.4 Afpraken met relevante SE'en Nee 5 5 Technische werkgroep TAO R3.3.5 Afspraken met andere eenheden 5 5 FB is mijn afdeling, Applicatiebeheer (Expertise Centrum) Utrecht, Technisch Beheer is extern (MCX). Hosting en housing is één partij. Totaal 5 5 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers R3.4.1 Call-routering Ja 5 5 R3.4.2 Communicatieprotocol Ja 4 4 Ligt bij communicatieadviseur. R3.4.3 Onderhoudsplannen Ja 5 5 Totaal 3 5 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap R3.5.1 Basale kennis IS, IM, BiSL 4 4 R3.5.2 Kennis architectuurprincipes 2 2 R3.5.3 Relatie i-governance en iv-projectportfoliomaangement 4 4 R3.5.4 Voldoende beschikbaar budget 5 5 Geld in FTE R3.5.5 Voldoende deskundig personeel 5 5 Zelf opleiden R3.5.6 Toegang netwerk systeemeigenaren 2 2 Nog in de kinderschoenen R3.5.7 Invloed werkzaamheden 5 5 R3.5.8 Noodzakelijke communicatiekanalen 4 4 HvA heeft geen communities zoals de UvA. Naar de eindgebruiker Twitter en websites R3.5.9 Advies centrale informatiemanagers 2 2 Betrek ze wel bij ontwikkelingen, zij informeren mij niet. Kort lijntje R Geschoolde gebruikers 3 3 Niet op alle terreinen. Totaal 10 4 R3.6 Overige activiteiten waar de systeemeigenaar een rol bij speelt R3.6.1 Betrokkenheid innovatie 5 5 R3.6.2 Afstemming centraal IM 5 5 Bij werkplekken ook betrokken, maar als laatste R3.6.3 Betrokkenheid contracten en SLA's 3 3 Niet ICTS, wel campsolutions Totaal 3 5 Totaal R R4 Uitgangspunten bij het beheer van de informatiesystemen R4.1 Algemene uitgangspunten m.b.t. beheer R4.1.1 Opdeling beheer IS 4 4 Ja, behalve technisch beheer en H&H R4.1.2 Invulling applicatiecoördinatie 1 1 Geen applicatiecoordinatie. R4.1.3 Beheerlagen als diensten 1 1 Nog niets aangeboden als dienst R4.1.4 Verantwoordelijkheid verschillende beheerlagen 1 1 Totaal 4 1 R4.2 Uitgangspunten m.b.t. functioneel beheer R4.2.1 FB intern belegd 5 5 R4.2.2 FB ingericht volgens BiSL 1 1 Geen idee, BiSL geen eerste voorkeur R4.2.3 Systeemeigenaar onderdeel sturende laag FB 3 3 Binnen eigen verantwoordelijkheden en takenpakket R4.2.4 FB'er onderdeel uitvoerende laag FB 5 5 Sturend en strategisch R4.2.5 Afstand functioneel beheer en systeemeigenaar 5 5 Zie ze elke dag, hierarchisch R4.2.6 Vervanging functioneel beheerder 5 5 Op iedere taak die er is, is er een tweede en derde. R4.2.7 Rolbelegging functioneel beheerder 5 5 Adviserend R4.2.8 Geen applicatiebeheer of technisch beheer 5 5 Wel personeel die van alles en nog wat kunnen. Af en toe gebruik van makend. R4.2.9 Key-users benoemd soorten: Inschrijf en Volg R Afstemming operationele BiSL processen met key-users 5 5 harmonisatie principes, wijzigingsbeheerzaken. Werkprocessen. Problemen richting administraties, richting andere lagen van de organisatie. R Key-users/decentraal FB'er onderdeel functioneel beheer 5 5 R Overleg SE met FB'er 5 5 1x per 14 dagen Totaal 12 5 R4.3 Uitgangspunten m.b.t. de andere beheerlagen R4.3.1 FB stuurt overige beheerlagen 4 4 Dat proberen ze wel eens, dat gebeurt wel eens. Dan gedoe over. Niet de bedoeling. R4.3.2 SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) 3 3 Wel verantwoordelijk voor beheerlagen, maar niet via ICTS R4.3.3 SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten 3 3 SLA's zijn oud. SE verantwoordelijk R4.3.4 ICTS verantwoordelijk voor contractmanagement 1 1 Niet bij ICTS R4.3.5 Afspraken ICTS met systeemeigenaar over AB, TB H&H 1 1 ICTS betrekken alleen bij technische keten overleg. Totaal 6 3 Totaal R Alle uitgangspunten 51 5 T.M. van Bremen - University of Amsterdam

84 INTERVIEW GAP-ANALYSE Auteurs : Tim van Bremen, Bart van Eck Versie : 0.7 Datum : Version management Versie Datum Verstuurd naar Doel Kandidaten interview Kandidaten interview Ter voorbereiding interview Ter voorbereiding interview Verwerking antwoorden Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 1 of 21

85 Index Index Introductie interview Interviewvragen VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS VERANTWOORDELIJKHEID VOOR HET BEHEER VAN HET IS VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPELT ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN AFSLUITING INTERVIEW Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 2 of 21

86 1 Introductie interview Wie zijn wij? Masterstudenten UvA Afstudeeronderzoek bij HvA/UvA Wat doen we? Vastgestelde uitgangspunten vergelijken met de huidige situatie Analyse van verschillen hiertussen Academische onderbouwing door koppeling met wetenschappelijke literatuur Doel van de analyse Inzicht verschaffen huidige situatie over verschillende systemen Doel van dit interview Inzicht verkrijgen over invulling van uitgangspunten voor [Naam]. en haar informatievoorzieningen Niet te beschouwen als evaluatiegesprek Verzoeken tot opname interview Wissen na afsluiten onderzoek (oktober 2014) Samenvatting interview voorleggen aan geïnterviewde voor eventuele aanpassingen Aantal systemen hebben wel een andere impact en samenhang. [Naam]is bijvoorbeeld relatief. En er zijn nog andere koppelingen (met anderes ISsen). Bijvoorbeeld ideal waarmee kaarten eventueel gekocht kunnen worden als deze kwijt is. [Naam]wordt ook wel proceseigenaar genoemd. [Naam]is de coördinator van het team dat uitvoerende werkzaamheden doet. Die persoon weet de diepere details per systeem onder het [Naam] systeem. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 3 of 21

87 2 Interviewvragen Hieronder volgen de vragen die in het interview aan bod zullen komen. U kunt deze ter voorbereiding voor het interview doornemen. Bij sommige vragen staat een document icoon (), welke aangeeft dat er een document vereist is voor een volledige invulling van de vraag. Indien mogelijk kunt u dit document vooraf toesturen of meenemen naar het interview, anders zou dit in de nasleep van het interview gestuurd kunnen worden. 2.1 Verantwoordelijkheid voor de basisinformatie van het IS Lijst van informatiediensten die het IS levert met bijbehorende gebruikers Zijn deze gegevens voor uw systeem bekend? Ja, dienstbeschrijving, maakt helder aan de gebruiker wat de dienst inhoudt en hoe je er gebruik van kan maken, bijv. hoe vraag je een kaart aan. Deze is beschikbaar. Niet gevalideerd. Heeft u deze gegevens gevalideerd bij Soenita Sitabi? Nee, niet gevalideerd. Architectuurplaat Is er een architectuurplaat/model van interfaces en data transfer van het IS? Ja. Beschrijft dit model de huidige situatie? Ja. Up to date. Heeft u dit model gevalideerd bij Soenita Sitabi? Ja, is gevalideerd. Informatie over betrokkenen Is er een overzicht over welke rol door welke beheerder of partij wordt uitgevoerd? Ja. Leveranciers per systeem. [Naam], wordt geleverd en onderhouden door een andere leverancier dan bijv. [Naam]. Met [Naam] en [Naam] heel duidelijk een SLA gemaakt en wat er wordt verwacht van de leverancier tegen welke kosten. [Naam] is een flutcontract. Wordt dit up-to-date gehouden? Ja. Heeft u dit overzicht bij Soenita gevalideerd? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 4 of 21

88 Niet voor elk systeem. 2.2 Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen U bent nu als systeemeigenaar verantwoordelijk voor de volledige beheerketen voor het dagelijks beheer van [Naam]., van functioneel beheer tot en met hosting/housing inclusief scholing van de betrokken medewerkers (exclusief scholing van de gebruikers). Beleeft u deze verantwoordelijkheid zo? Applicatiebeheer uitbesteed aan ICTS. Dat deden we wel. Maar inderdaad ik ben proceseigenaar, systeemeigenaar, die vallen toevallig samen voor dit systeem. En ik doe inderdaad functioneel beheer, maar echt applicatie heer gaat via [Naam] en die zit bij ICTS. Kunt u op dit moment deze verantwoordelijk voor de hele beheerketen dragen? (Op een schaal van 1 tot 10) Ja zeker. 8. Zo nee, wat zou u ervoor nodig hebben? Zijn er externe partijen betrokken bij [Naam].? Ja. Zijn er contracten met die externe partijen? Ja en nee, zoals eerder gezegd dit verschilt per systeem. (De contracten worden naderhand verkregen). [Naam], [Naam], [Naam], [Naam] [Contract] [Naam]niet. Inkoop bewaart en beheert de contracten. [Naam]. Hoe is de scholing geregeld? Niet gestructureerd geregeld. Allemaal ervaring met systemen. Verschil in kennisniveau. Basiskwalificatie. Wel opleiding, geen verplichtingen als bijvoorbeeld een BiSL of ITIL opleiding. Tweedaagse cursus bij [Naam] bijv. Het zou wel gewenst zijn als je naar functioneel beheer kijkt vanuit de IT hoek, die hebben wel echt als basis kwalificatie dat ze een bepaalde level moeten hebben. Belegging rollen Zijn de verschillende rollen in de beheerorganisatie helder belegd? Ja. Splitsing tussen functioneel en applicatiebeheer expliciet. Verschilt per systeem, hier speelt ICTS een rol in. Staat dit ergens op papier? Nee, Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 5 of 21

89 Alleen mondeling. [Document] [Mondeling] Sommige wel gedocumenteerd en sommige niet, dat is niet eenduidig. Zijn er beschrijvingen van incidentmanagement? Ja, [Document]. Ook per systeem verschillen, soms we beschreven en soms niet. Zijn er beschrijvingen van wijzigingsbeheer? Ja, overleg over wijzigingen. [Document] In dit overleg worden alle grote en kleine changes besproken. Er wordt ook bepaald wat er wel of niet gebeurt of kan gebeuren. Ik beslis dat uiteindelijk. Zijn er beschrijvingen van probleemmanagement? Ja. [Document] Zijn er beschrijvingen van configuratiebeheer? Ja, generiek beschreven. Bij de één zie je dat het werkt. Autorisatiemanagement bijvoorbeeld, een leidinggevende mag beslissen op je wel of iets met je pasje mag daar ga ik niet over. Dus het ligt aan de impact van waarover een beslissing genomen moet worden. Verschilt afhankelijk van impact. [Document] Escalatieschema s Zijn er escalatieschema s binnen de beheerketen? Ja. Bij goede contracten zijn alle bovenstaande dingen beter beschreven. Staan ze op papier? Niet op papier. [Document] [Mondeling] Zijn ze in gebruik? Ja, niet voor [Naam]. [Naam] wordt uitgefaseerd. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 6 of 21

90 Crisisplan Is er een crisisplan? Ja. Beheerplannen die generiek zijn, maar ook verschillende plannen voor sommige systemen wel en sommigen niet. Verschilt weer per systeem. Bij [Naam] geen plan. Waar is die te vinden? Staat het op papier? [Document] [Mondeling] Is het crisisplan bekend in alle lagen van de beheerorganisatie? Nee. Updates en upgrades Worden er regulier, planmatig of incidenteel updates/upgrades uitgevoerd bij [Naam]. om de continuïteit van het IS en haar IV-diensten te waarborgen (t.b.v. security, compatibiliteit)? Ja. Indien nee, bij wie kunnen wij dat wel achterhalen? Staat dit ergens vastgelegd? Soms vastgelegd. Releaseplan. Maar bij sommige systemen niet nodig. [Document] 2.3 Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Wie zit er op het tactische niveau van de gebruikersorganisatie? [Naam] over het algemeen. Bij financiële consequenties of als de impact groot is systeemeigenaar zelf. Bijvoorbeeld als het direct op de klant van toepassing is of financiële gevolgen heeft. Op welke frequentie wordt er door wie met wie gesproken (+ rollen van die personen)? Één keer per kwartaal. Tussen [Naam] en de mensen van wie we de diensten afnemen. Heeft u de indruk dat er hierdoor sprake is van aansluiting op de werkprocessen en behoeften van de organisatie? (Op een schaal van 1 tot 10) 7, de kaart wordt steeds belangrijker. Betalen met kaart i.p.v. chipknip. Dit is beredeneerd vanuit het gebruikersperspectief. Klant is er wisselend tevreden over. Soms werkt de functionaliteit niet altijd. Maar over het algemeen vinden zowel medewerkers als studenten het een handig systeem. Geen zes kaarten, maar één. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 7 of 21

91 Regie wijzigingenbeheer Wordt er volgens BiSL gewerkt bij functionele wijzigingen in [Naam].? Niet altijd. BiSL is een theoretisch model en dat werkt niet altijd in praktijk. Urgentie vereist soms dat men om BiSL heen gaat. Bent u daar zelf direct bij betrokken? Ja, 9/10. Zo ja, hoe? Via overleg. Excelsheet. Wijzigingen worden besproken. Geen impact op andere systemen = doorvoeren wijzigingen. Staat dit op papier? Ja, excel. Bij Salto veel aan de hand. Tism wordt uitgefaseerd. [Document] [Mondeling] [Naam] [Naam] Soms [Naam] Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 8 of 21

92 Afspraken wijzigingsbeheer Zijn er afspraken gemaakt met de gebruikersorganisatie over de manier waarop de systeemeigenaar de regie over het wijzigingsbeheer voert? Ja, er zijn wel afspraken gemaakt en opvraagbaar dat gaat via het PDC (Product en diensten catalogus). Iedereen kan hier in zoeken op trefwoord en zien wie bijvoorbeeld het systeemeigenaar is. Is er sprake van aparte afspraken / onderscheid verschillende partijen? Ja, afhankelijk van systeem en van impact systeem of wijziging. Soms om het kwartaal een update. Hoe wordt het afgestemd in het geval van meerdere partijen? (Bijv. UvA en HvA) Hangt ook van afhankelijkheden af. Sommige changes kunnen gelijk doorgevoerd worden. IDM, SIS staat hierbuiten. Maar SIS kan wel dit IS beïnvloeden door de informatie die het systeem voedt. Het hangt af waar in de keten de change plaatsvindt. Met wie zijn welke afspraken gemaakt (+ rollen van die personen)? Hangt er weer van af. In ieder geval één regel: Systeemeigenaar gaat uiteindelijk over alle wijzigingen. Welke gebruikersgroep(en) representeert diegene? Functioneel beheergroep. Lijst besproken samen met hen, zit ook applicatiecoördinator bij. Die legt ook indien nodig contacten aan met de leverancier. Zijn die afspraken vastgelegd? Ja, [Document] Hoe vaak vinden er vergaderingen plaats? Tweewekelijks was het, maar het is iets opgerekt i.v.m. beschikbaarheid en aantal changes dus meer maandelijks overleg. Niet voor elk systeem een part overleg. Afspraken interfaces Is er sprake van afstemming met systeemeigenaren informatiesystemen waarmee interfaces bestaan? Ja. Zijn die afspraken vastgelegd? Nee, die zijn niet vastgelegd. Maar de afspraken zijn er wel, informeel en incidenteel. Namelijk bij een change doe je een korte impactanalyse. Waarin je aan kan geven wie wat wilt en daardoor de invloeden van verschillende systemen inzien. Maar het is niet gestructureerd overleg, maar incidenteel. Zo ja, hoe? [Document] Hoe vaak vindt er overleg plaats? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 9 of 21

93 Niet maandelijks/vaak. Incidenteel. ICTS doet update op vrijdagavond. Problemen op maandagochtend. Het heeft veel te maken met de inschatting van diegene die de wijzigingen beoordeelt en wie je daarbij inschakelt. Andere eenheden Wordt er een deel van het beheer in een andere eenheid uitgevoerd? Applicatiebeheer/Technisch beheer, ICTS Zo ja, zijn er vastgelegde afspraken met andere eenheden wanneer een deel van het beheer daar wordt uitgevoerd? (Noot: Bijv. SLA met ICTS voor applicatiebeheer) Ja, nog niet voor alle systemen. BiSL wil bepaalde verdeling. Capaciteitsprobleem. Belangrijkste zijn geregeld. Applicatiecoördinator [Naam] doet meer [Naam]. Tweede persoon doet meer [Naam]. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 10 of 21

94 2.4 Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Zijn die call-routeringen vastgelegd? Ja. Servicedesk -> groep [Naam] en daar wordt het opgepakt. Wat je ook wel eens ziet, dat mensen er vaak zelf naar toe gaan i.p.v. bellen. Zo ja, waar? Document Is dit bekend bij alle gebruikers? Wel bekend, maar bekender is er naartoe gaan en ze helpen je. Is dit helder voor de eindgebruiker van [Naam].? Redelijk. Is de call-routering volgens u efficiënt? (Op een schaal van 1 tot 10) Ja, 8. Communicatieprotocol Bestaat er een communicatieprotocol met de gebruikers en de overige stakeholders van [Naam].? Ja, er wordt wel gecommuniceerd. Uitrol medewerkerskaart. Wordt gecommuniceerd naar betreffende faculteit. Geen standaardplan. Per issue. Is dit vastgelegd? Nee. Via afdeling communicatie enigszins standaard. Die kijkt of aan alles is voldaan. Doelgroep analyse, medium. Onderhoudsplannen Zijn er onderhoudsplannen? Ja, maar niet voor alle systemen. Staat dit op papier? Document Zijn de onderhoudsplannen gepubliceerd? Nee, alleen inzichtelijk voor systeembeheerder en Koen. Niet voor de eindgebruiker. Zo ja, waar? Voor wie is dit toegankelijk? Systeembeheerder en Koen. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 11 of 21

95 2.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis Heeft u de indruk dat u genoeg basale kennis heeft van informatiesystemen, informatiemanagement en BiSL? 8. Kennis architectuurprincipes Heeft u de indruk voldoende kennis te hebben van architectuurprincipes? 8. Principes wel, niet precies de technische koppelingen, maar dit is ook niet noodzakelijk. Relatie i-governance en iv-projectportfoliomanagement Heeft u de indruk dat u genoeg begrip heeft van de relatie met de i-governance en ivprojectportfoliomanagement? Ja, maar redelijk nieuw. 8. Lastig is met HvA én UvA, de een zegt ja en de ander zegt nee, maar er is maar één systeem. Ik snap goed hoe het werkt en niet werkt. Voldoende beschikbaar budget Beschikt u over voldoende beschikbaar budget? Ja/nee. Gaat met klantgroepen (bedrijfsvoerders). Het is niet ongelimiteerd. Voor welke aspecten van het systeemeigenaarschap heeft u budget beschikbaar? Onderhoud en beheer. Wordt dit apart begroot? Ja, ook apart begroot. Voldoende deskundig personeel Is er u voldoende personeel beschikbaar? Nee, in eindsituatie wel. Salto, toegangsbeheersysteem. Stijging in aantal panden en gebruikers. Capaciteit groeit niet mee. Is het personeel voldoende deskundig? Nee, deels wel, maar drijft op twee mensen, de andere ondersteunen. Als eentje wegvalt dat breed is onderlegd draagt dan zal dit een probleem zijn. Met een parttimer kan ik niets. Toegang netwerk systeemeigenaren Heeft u voldoende toegang tot het netwerk van systeemeigenaren? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 12 of 21

96 Ja, CIM Centraal Informatie Managers. Belangrijkste zijn bekend. Het belangrijkste weet ik wel, maar mocht het nodig zijn kan dit geraadpleegd worden. Maakt u gebruik van dit netwerk? Ja Invloed werkzaamheden Heeft u directe invloed op de werkzaamheden van de functioneel beheerders van [Naam].? Zeker, heel direct. 10. Noodzakelijke communicatiekanalen Heeft u de noodzakelijke communicatiekanalen ter beschikking om over uw IS te communiceren met de eindgebruikers? Ja. 8. Zo nee, welke kanalen mist u? Nee, maar er zijn wel afhankelijkheden. Met studenten communiceren moet via derden (Communicatie). Advies centrale informatiemanagers Maakt u gebruik van advies van de centrale informatiemanagers over o.a. technologische ontwikkelingen in uw rol als systeemeigenaar? Ja dat zou ik wel doen, maar het is nog nooit aan de orde geweest. we hebben wel overleg met de centrale informatiemanagers, maar die hebben veel meer te maken gehad met coördinatie en samenhang van andere projecten. Ik heb een heel klein beetje technisch advies gehad. Van de meeste systemen weet ik meer dan dat zij er van weten. Dat is ook niet zo gek, omdat zij er minder mee te maken hebben. 6. Geschoolde gebruikers Vindt u dat de gebruikers van [Naam]. voldoende zijn geschoold? Kunnen ze goed overweg met het informatie systeem? Nee, niet nodig bij dit systeem. De gebruikers zijn de mensen die en kaart hebben, die hoeven niet te weten hoe dit IS werkt. Alleen weten van de functionaliteiten van de kaart. Plant u wel eens extra scholing of trainingen in voor de gebruikers? Nee. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 13 of 21

97 2.6 Overige activiteiten waar de systeemeigenaar een rol bij spelt Betrokkenheid innovatie Bent u voldoende betrokken bij de innovatie van uw IS? Ja, zeker. Bijv. vertraging van vervanging chipknip/ 9. Ik durf zeker te zeggen dat ik voldoende op de hoogte ben. Kaart krijgt straks bijv. ook concurrentie van de telefoon. Bent u betrokken bij het aanmelden en aansturen van iv-projecten van [Naam].? Ja, ook direct. 9. Er zijn geen projecten die ze kunnen doen zonder mij. Derden hebben geen capaciteit. Handen vol aan draaiend houden. Afstemming met centraal informatiemanagement Is er een goede afstemming met centraal informatiemanagement rondom het ivprojectportfolio en overige relevante zaken? Ja zeker, gisteren nog mee gesproken. (29-04) Bent u betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken? Ja, indirect wel. 8. Dat komt omdat één van die mensen die er werkt is toevallig ICT contact persoon en die heeft er direct mee te maken. Met zowel de de HvA en UvA van de uitrol van de nieuwe werkplek en de uitrol van Windows 7. Betrokkenheid contracten en SLA s Bent u zelf betrokken bij het opstellen van de contracten en SLA s tussen ICTS en externe leveranciers? Nee. Te recent. 2.7 Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS en Is het beheer van IS opgedeeld in de lagen: a. functioneel beheer b. applicatiecoo rdinatie c. applicatiebeheer d. technisch beheer e. hosting en housing? Ja, alleen applicatie en technisch beheer zijn samen in Servicekaartsystemen. Zijn deze rollen gescheiden? Ja, maar niet voor applicatiebeheer en technisch beheer. Hosting kan binnenshuis of buiten zijn en dit verschilt per systeem. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 14 of 21

98 Ja, Zijn er lagen uitbesteed? Is dit vastgelegd? Hoe afhankelijk is het IS van deze uitbestedingen? Erg, anders geen toegang meer. 1 of 2 gebouwen met Salto = alle gebouwen moeten met Salto. Hoe afhankelijk is de externe partij van UvA/HvA? Niet. 1 is redelijk afhankelijk. Andersom is sterker. KMS is Magnacarta. VRS (Verbruik registratiesysteem) Factuur controleren. Of het verbruik in totaal klopt. Kan zelfs individueel, maar mag niet i.v.m. privacy. Verbruik koffie totaal. Diefstal. Applicatiecoördinatie Is er applicatiebeheer uitbesteed aan een externe partij? Nee, ligt bij ICTS. Beheerlagen als diensten Is van applicatiecoo rdinatie, applicatiebeheer, technisch beheer, hosting en housing belegd bij ICTS? Technisch en applicatiebeheer. Soms hosting, ligt aan welk systeem. Zo nee, welke lagen niet? Verantwoordelijk lagen Bent u ook verantwoordelijk voor lagen van het beheer die bij ICTS belegd zijn? Nee, ligt bij ICTS. Zijn er lagen van het beheer die bij andere eenheden als dienst worden afgenomen? Hosting bij KMS is extern. Zo ja, in hoeverre bent u daar verantwoordelijk voor? Uitvoering van contract. De partij is verantwoordelijk. Als het niet goed gaat moet ik zorgen dat dit wel gebeurt. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 15 of 21

99 2.8 Uitgangspunten m.b.t. functioneel beheer Functioneel beheer intern belegd Is functioneel beheer voor uw IS geoutsourcet? Nee. Er is niet één functioneel beheerder, het hele team van Koen is FB. Er zijn dus vijf mensen die dat uitvoeren, ook voor alle subsystemen. Zij zijn allemaal aanspreekbaar als FB, de een weet echter wel meer dan de ander. Ingericht volgens BiSL 1 Is uitvoerend en sturend functioneel beheer ingericht volgens BiSL? Ja, inmiddels wel, maar dat is nog niet zo heel lang. Sanne heeft toen het model daar geïmplementeerd. Is dat zo voor alle processen? Ja. Theoretisch wel. Het is een theoretisch model. Je probeert er in hoofdlijnen aan vast te houden, soms moet je om praktische redenen wel langs de structuur heen. Je kan moeilijk wachten tot het volgende release-overleg. Als er een keer een brand is moet je die gewoon blussen. Systeemeigenaar onderdeel sturende laag Welke besluiten mag de functioneel beheerder zelf nemen? FB doet uitvoerend werk. Ze voeren wijzigingen door. Wijzigingen worden wel voorgelegd aan systeemeigenaar, behalve bij wijzigingen met een lage impact zoals een autorisatie. Ze doen heel veel uitvoerend werk, bijvoorbeeld bij Salto sloten koppelen. Ik vind wel dat dat stukje uitvoering naar beneden moet worden gebracht. Ze doen ook werk, en dat is uit nood geboren, waarvan ik denk dat een huismeester dat moet doen. Het wordt tijd om dat echte uitvoerende werk los te laten. Voor welke besluiten wordt de systeemeigenaar gevraagd? Wijzigingen en authenticatie issues komen naar systeemeigenaar. Functioneel beheerders zijn onderdeel van de uitvoerende laag van functioneel beheer Heeft u het idee dat u onderdeel bent van de uitvoerende laag? Beleeft u uw rol als operationeel, sturend of strategisch? Sturend en strategisch. Het is natuurlijk wel een concernapplicatie. Het raakt de hele UvA en HvA. Houdt zich verre van uitvoerend. Ik laat me wel informeren, maar dat is een hoop geneuzel. 1 Zie bijlage A. BiSL model Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 16 of 21

100 Afstand functioneel beheer en systeemeigenaar Hoe dicht staat u organisatorisch bij de functioneel beheerders van [Naam].? Er zit iemand tussen, [Naam]. Ik ben wel direct contact en formeel leidinggevende, maar er zit niet voor niets iemand tussen. Als ik me daarmee bezig zou moeten houden, heb ik daar een fulltime baan aan. Er zit een coördinator tussen. Als je kijkt naar de BiSL-procedures dan kom ik weer in zicht. Ik doe niet de dagelijkse aansturing, zo moet je het zien. Vallen zij onder dezelfde dienst? Ja, FS. Is er sprake van een hiërarchische relatie? Ja. Vervanging functioneel beheerder Hoe is vervanging geregeld voor de functioneel beheerder? Ze nemen elkaars rollen over. Het is een relatief kwetsbare groep door verschillende arbeidstijden. Ze kunnen bijna alles ongeveer hetzelfde (de één kan wat meer dan de ander), maar ze kunnen elkaar wel overnemen. Het is niet zo dat als iemand wegvalt dat er opeens een heel specialisme in elkaar stort. echter wel ongeveer hetzelfde en nemen elkaar over. Be Als er iemand langdurig uitvalt, wat wel eens is gebeurt, dan vraag ik een ander om zijn/haar uren op te schalen. En daar zijn ze ook wel toe bereid. Het wordt binnen het team opgevangen. Het moet nog wel beter wat betreft rollen. Gedocumenteerd hoeft niet. Rol functioneel beheerder Hebben de functioneel beheerders een adviserende uitvoerende rol? (Nemen ze zelf geen besluiten over de functionele inrichting en/of gebruikersautorisaties van het IS zonder uw akkoord?) Ze hebben een uitvoerende rol en adviseren soms wel, maar dit doen ze niet zo vaak. Ik heb zelden een fatsoenlijk verbeterplan gezien. Ze zouden dit wel in het kader van procesverbetering dit vaker moeten doen. Door de drukte en hectiek is dit echter moeilijk. moeilijk. Het is wel een wezenlijk onderdeel van hun functie en dit voeren ze gewoon niet uit. Ik kan het ze echter ook niet kwalijk nemen, want ze zitten ook elke dag in de hectiek van dit pasje doet het niet, enz. Terwijl het eigenlijk een soort cyclus is. Als je het proces niet verbetert heb je kans dat je dezelfde vraag een week later weer krijgt. Ik ben niet tevreden over hoe ze dat uitvoeren. Geen applicatiebeheerder of technisch beheerder Voeren de functioneel beheerders applicatiebeheer uit? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 17 of 21

101 Nee, applicatie en technisch beheer zit bij ICTS. FB is op operationeel bezig. Koen heeft een aparte positie (coördinator). Voeren de functioneel beheerders technisch beheer activiteiten uit? Key-users en decentrale functioneel beheerders Zijn er key-users benoemd als onderdeel van uitvoerend functioneel beheer? Nee. Voor bijvoorbeeld [Naam] is het heel goed geregeld met en speciale key-usergroep, maar voor deze applicaties niet. Voor deze systemen is echter geen geen gestructureerd key-user overleg van bijv. eens in de twee maanden. Het is puur individueel, de vraag is echter of je dat anders zou willen. Zijn er decentrale functioneel beheerders voor [Naam].? Nee, vroeger wel, nu is alles gecentraliseerd. Zo ja, wanneer wordt er met wie gesproken? Waar nodig wordt er gesproken. Alleen wanneer er een klanteffect is. Als er een proces verandert waar de gebruiker een rol in speelt moet dit gecommuniceerd worden. Voorbeeld toekomstige mogelijkheid betalen met pas. Als je achteraf ergens een bestand gaat opschonen, doe je dit niet. Operationele BiSL processen Welke operationele BiSL-processen worden afgestemd met de key-users? Ja, kan niet zomaar iets veranderen. Achter de schermen niet. En met decentrale functioneel beheerders? Wat wordt er afgestemd? Procesverandering. Bijv. pas kwijt, naar balie en betalen. Tegenwoordig bestellen en betalen met ideal. Direct klant effect moet gecommuniceerd worden. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 18 of 21

102 Decentraal functioneel beheerder Is er sprake van een decentraal functioneel beheerder? Nee Zo ja, hoe groot is het aantal van de operationele functioneel beheerprocessen dat volgens BiSL decentraal belegd wordt? N.v.t. Overleg Heeft u regulier overleg met functioneel beheerders? Ja. Zo ja, op wat voor frequentie? Zou maandelijks moeten zijn. Soms sla ik wel eens een maandje overslaan, ligt eraan wat voor spannende dingen er op de agenda staan. Waarom is er gekozen voor deze frequentie? Wat we bespreken zijn de voorgestelde wijzigingen. Urgentie van de punten op de agenda. Herhalende punten, maar ook grote wijzigingen. Applicatiebeheerder zit er ook bij. Ik heb bevoegdheid om ja of nee te zeggen. 2.9 Uitgangspunten m.b.t. de andere beheerlagen Sturend functioneel beheer Is functioneel beheer van [Naam]. sturend t.o.v. andere beheerlagen? Ja, eigenlijk wel. ICTS gaat naar aanleiding van wens tot wijziging of probleem (met contract) met leverancier aan tafel zitten. Dit gebeurt op initiatief van FB, FB start deze activiteiten op. Neemt applicatiebeheer onafhankelijk van functioneel beheer besluiten? Nee, niet onafhankelijk. Verantwoordelijkheid Hoe zijn de beheerlagen onder functioneel beheer geregeld? Wie is er verantwoordelijk voor? Vallen die onder de verantwoordelijkheid van ICTS? Zijn er beheerlagen geoutsourcet? Zijn ook die beheerlagen de verantwoordelijkheid van ICTS? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 19 of 21

103 Overeenkomsten Is de systeemeigenaar en de service manager(s) van ICTS verantwoordelijk voor het juiste serviceniveau van de dienstverlening overeenkomst tussen ICTS en de dienst / divisie waaronder [Naam]. valt? De servicemanager onderhoudt de contacten tussen de verschillende diensten, bijv. FS en ICTS. Dus als je bij ICTS een vraag hebt en je betaalt voor een dienstverlening, maar je weet niet precies wat het doet, dan is het aan de servicemanager om dat uit te leggen. Of iemand komt bij de servicemanager met de wens voor nieuwe functionaliteit, dan is het aan de servicemanager om dit te vertalen naar een functionele vraag en te kijken of dit mogelijk is. Contractmanagement Hoe is het management van contracten geregeld? De bedoeling is uiteindelijk applicatiecoördinator de contracten gaat beheren. Nu ligt het nog bij beide, omdat ze bij ICTS nog geen capaciteit hebben. Liggen de contracten bij ICTS? Is er verschil tussen contractmanagement voor geoutsourcete en interne dienstverlening overeenkomsten? Ja, geoutsourcet zit ook iets van een SLA onder. En soms intern niet zoals met ICTS, wat je wel zou verwachten. Met een externe partij meestal beter geregeld dan intern. Deze interne dienstverlening zou veel beter afgestemd moeten worden met interne SLA s. Betrekt ICTS u bij de beheeractiviteiten met externe leveranciers van beheeractiviteiten? Nog niet zoveel aan de hand gehad, maar in principe ben ik overal bij betrekken. Elke wijziging of issue dat speelt bij de contracten moet ik over ingelicht worden. Ik heb het gevoel dat ze dit wel doen, ook omdat ze zelf de verantwoordelijkheid hiervoor niet willen dragen. Applicatiecoördinatie Is er sprake van applicatiecoördinatie? Dit gebeurt ook bij ICTS, ze hebben een soort dubbelrol. Als er een issue is met de contracten bespreken ze dat met de leverancier, want vaak gaat het om technische dingen. En ze doen natuurlijk de coördinatie over al die applicaties. Wat betekenen bepaalde wijzigingen voor het architectuurlandschap, of andersom. Afspraken met ICTS Zijn er afspraken met ICTS over applicatie- en technisch beheer, hosting en housing? Ja, op zich zijn die er wel, maar ze zijn onvoldoende vastgelegd in contracten. Zo ja, wordt er aan die afspraken voldaan? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 20 of 21

104 Tot nu toe, in verhouding met de beschikbare capaciteit, wel tevreden. Het zou wel beter moeten. Het is nog niet zoals het zou moeten. Maar binnen de mogelijkheden doen ze wel hun best. Als je het hebt over hosting, we hebben dingen extern gehost, maar misschien zou dit in de toekomst beter intern kunnen. ICTS heeft hier wellicht een adviserende rol in. Afsluiting interview Evaluatie: Het is een soort bewustwording. Kennis is niet zo heel slecht. Details zijn lastig. Van een paar contracten weet ik zeker dat ze bestaan. Enerzijds denk ik, het valt wel mee de kennis die ik ervan heb. Anderzijds als je de details inschiet dan weet ik er weer te weinig van. Dat is goed, want dat zet mij weer aan het denken. Ik heb een beetje pech dat het zoveel subsystemen zijn, waarvan er een aantal generiek zijn. Functioneel beheerplannen zijn dan veel kleiner. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 21 of 21

105 INTERVIEW GAP-ANALYSE [Naam] [Naam] (HvA) [Naam] (UvA) [Naam] (HvA) Auteurs : Tim van Bremen, Bart van Eck Versie : 0.7 Datum : Version management Versie Datum Verstuurd naar Doel Kandidaten interview Kandidaten interview Ter voorbereiding interview Ter voorbereiding interview Verwerking antwoorden Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 1 of 18

106 Index Index Introductie interview Interviewvragen VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS VERANTWOORDELIJKHEID VOOR HET BEHEER VAN HET IS VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPELT ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER AFSLUITING INTERVIEW Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 2 of 18

107 1 Introductie interview Wie zijn wij? Masterstudenten UvA Afstudeeronderzoek bij HvA/UvA Wat doen we? Vastgestelde uitgangspunten vergelijken met de huidige situatie Analyse van verschillen hiertussen Academische onderbouwing door koppeling met wetenschappelijke literatuur Doel van de analyse Inzicht verschaffen huidige situatie over verschillende systemen Doel van dit interview Inzicht verkrijgen over invulling van uitgangspunten voor [Naam] en haar informatievoorzieningen Niet te beschouwen als evaluatiegesprek Verzoeken tot opname interview Wissen na afsluiten onderzoek (oktober 2014) Samenvatting interview voorleggen aan geïnterviewde voor eventuele aanpassingen Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 3 of 18

108 2 Interviewvragen Hieronder volgen de vragen die in het interview aan bod zullen komen. U kunt deze ter voorbereiding voor het interview doornemen. Bij sommige vragen staat een document icoon (), welke aangeeft dat er een document vereist is voor een volledige invulling van de vraag. Indien mogelijk kunt u dit document vooraf toesturen of meenemen naar het interview, anders zou dit in de nasleep van het interview gestuurd kunnen worden. 2.1 Verantwoordelijkheid voor de basisinformatie van het IS Lijst van informatiediensten die het IS levert met bijbehorende gebruikers Is er een lijst van de informatiediensten die het IS levert met bijbehorende gebruikers? Dienstbeschrijvingen, wat leveren we wanneer? Stukken zijn ondertekend. Ondertekend bij de directeuren. GBS systemen zijn geleverd en beheerd daar zijn allemaal contracten van. LWB: onbekend SP: bij mij niet bekend Wij hebben onze diensten beschreven in dienstbeschrijvingen richting de afnemers voor FNWI als je het over Science Park hebt. Die liggen vast. Dienstbeschrijvingen, productdiensten die hebben we beschreven. Wat leveren we wanneer. Heeft u deze gegevens gevalideerd bij Soenita Sitabi? Het zijn ondertekende stukken. De productdienstcatalogus (PDC), SLA s en DVO s worden ondertekend door de directeuren. Van dit IS is een intern systeem voor FS en niet voor FNWI, dus volgens de dienstverlening hebben we afspraken met de gebruikers en wij hebben verschillende contracten met betrekking met leveranciers maar ook met faciliteiten, bijvoorbeeld GBS en informatievoorzieningen die het mogelijk maken dat we die dienst invulling geven. Dus dat is een intern feestje. De GBS systemen die zijn geleverd en worden beheerd, daar zijn allemaal contracten van. Dus dat ligt vast. En dat is voor FS, daar hebben we een bepaalde procuratie voor, wie de opdracht mag aangaan en wie dat mag gaan beheren. Architectuurplaat Is er een architectuurplaat/model van interfaces en data transfer van het IS? [Document] Onbekend bij mij. Is deze up-to-date? Heeft u dit model gevalideerd bij Soenita Sitabi? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 4 of 18

109 Informatie over betrokkenen Is er een overzicht over welke rol door welke beheerder of partij wordt uitgevoerd? [Document] Bijna klaar voor de systemen, nu nog niet maar wel in de maak. Wordt dit up-to-date gehouden? Heeft u dit overzicht bij Soenita gevalideerd? 2.2 Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen U bent nu als systeemeigenaar verantwoordelijk voor de volledige beheerketen voor het dagelijks beheer van [Naam], van functioneel beheer tot en met hosting/housing inclusief scholing van de betrokken medewerkers (exclusief scholing van de gebruikers). Beleeft u deze verantwoordelijkheid zo? Ja. Kunt u op dit moment deze verantwoordelijk voor de hele beheerketen dragen? (Op een schaal van 1 tot 10) Die verantwoordelijkheid kan ik wel gewoon dragen. Ik kan wel een 10 geven, maar het is gewoon een 7 of een 8. Zo nee, wat zou u ervoor nodig hebben? Het is met name nog eventjes de onervarenheid in de zin van omdat het pas heel recent is. En wat heel expliciet is aangegeven voor deze systemen ben jij de eigenaar zeg maar. Daarmee geef ik ook gelijk aan dat het nog niet ingesleten is. Ongetwijfeld kom ik nog wel voor verassingen te staan. Dat hoort er ook nog even bij. Maar dat is dat is voor mij gewoon een kwestie van tijd. Dus met name is de afgelopen periode duidelijk geworden wat een systeemeigenaar mag, kan en moet. Dat geeft mij gewoon wel duidelijkheid waar ik aan en hoe ik moet sturen, daar ga ik invulling aan geven. Zijn er externe partijen betrokken bij [Naam]? Ja die zijn er zeker, dan zijn onze leveranciers van de systemen en diegene die ze onderhouden. Dus ja, dat is zo. Zijn er contracten met die externe partijen? [Contract] Ja wij hebben voor al onze contracten liggen vast bij inkoop en we hebben contractmanagers. Dus dat is allemaal bekend. Hoe is de scholing geregeld van de medewerkers? Opleidingsprogramma, jaarprogramma voor de ontwikkeling medewerkers. Om het werk te kunnen doen, soms is bijv. BHV of EHBO verplicht, maar dat is maar een voorbeeld. Op basis van GBS kun je niet zeggen dat er verplichte trainingen zijn. De mensen die met het GBS Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 5 of 18

110 werken hebben voldoende educatie gekregen. Twee medewerkers (Huisvesting) voor het uniform maken van de GBS systemen. Die weten alles van de functionailiteiten. Belegging rollen Zijn de verschillende rollen in de beheerorganisatie helder belegd? Ja ik denk dat die helder belegd zijn, voor Science Park en Leeuwenburg. Zijn er beschrijvingen van incidentmanagement? [Document] Ja, dat is bekend. Ook vastgelegd. Zijn er beschrijvingen van wijzigingsbeheer? [Document] Denk het niet. In het kader van mijn nieuwe rol nog niet bij de hand gehad. Per wijziging keuze maken. Komen we achter bij documentatie. Zijn er beschrijvingen van configuratiebeheer? [Document] Weet ik niet. Escalatieschema s Zijn er escalatieschema s binnen de beheerketen? Select aantal mensen mee bezig. Staan ze op papier? [Document] Select aantal mensen, weet niet of het in het schema staat. Zijn de escalatieschema s in gebruik? Denk niet dat het er is, ga er van uit van niet. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 6 of 18

111 Crisisplan Is er een crisisplan? Staan het op papier? [Document] Ook niet bekend, natrekken. Is het crisisplan bekend in alle lagen van de beheerorganisatie? Updates en upgrades Worden er regulier, planmatig of incidenteel updates/upgrades uitgevoerd bij [Naam] om de continuïteit van het IS en haar IV-diensten te waarborgen (t.b.v. security, compatibility)? Structuur is er niet, maar het is wel gewenst en gaan we aan werken in het kader van samenwerking met ICTS. Indien nee, bij wie kunnen wij dat wel achterhalen? Staat dit ergens vastgelegd? [Document] 2.3 Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Wie zit er op het tactisch niveau van de gebruikersorganisatie? Binnen het beheer Teamleider Onderhoud, Jan Griekspoor. Wie representeert de gebruikersorganisatie? In dit geval niet aan de orde, het is een interne aangelegenheid. Het gaat om de aansturing van onze dienstverlening. Clustermanagers hebben veel invloed over gebouwbeheersystemen en instellingen. In de SLA s vastgelegd wat de gebruikers willen, temperaturen, lokalen geopend etc. Deze systemen zorgen dat we dat kunnen volgen. Systemen laten zien als er iets fout gaat in de dashboard. Puur technisch Op welke frequentie wordt er door wie met wie gesproken (+ rollen van die personen)? Heeft u de indruk dat er hierdoor sprake is van aansluiting op de werkprocessen en behoeften van de organisatie? (Op een schaal van 1 tot 10) Ja, zit op een 8. Regie wijzigingenbeheer Wordt er volgens BiSL gewerkt bij functionele wijzigingen in [Naam]? Ik zou het niet weten, onbekend. Bent u daar zelf direct bij betrokken? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 7 of 18

112 Nog niet aan de orde geweest, Amstel campus wel bij betrokken. Wordt er uiteindelijk wel bij betrokken. Zo ja, hoe? Staat het wijzigingsbeheer op papier? [Document] Slecht, maar worden wel vastgelegd. Afspraken wijzigingsbeheer Zijn er afspraken gemaakt met de gebruikersorganisatie over de manier waarop de systeemeigenaar de regie over het wijzigingsbeheer voert? Nieuwe afspraken worden geregistreerd in het systeem. Is er sprake van aparte afspraken / onderscheid verschillende partijen m.b.t. het wijzigingsbeheer? Ja, dat kan. We kennen zogenaamde Basisdienstverlening en variabele dienstverlening. Basisdienstverlening is voor iedereen gelijk, maar daar kunnen gebruikers op afwijken. DVO s (dienstverlengingovereenkomsten) en SVO s (serviceverlengingsovereenkomsten). Afspraken interfaces Is er sprake van afstemming met de systeemeigenaren van de informatiesystemen waarmee interfaces bestaan met [Naam]? Ja die zijn er. Ik heb de relaties niet helemaal in mijn hoofd zitten. Maar ik denk bijvoorbeeld SALTO, voor het openen van de deuren, het toegangsbeheer is dat. Dan spreekt u ook met de systeemeigenaar? Ja. Weet u ook wie dat is? Voor toegangsbeheersystemen is dat [Naam]. Hoe vaak vindt zo n overleg plaats? Dat gebeurt incidenteel, alleen wanneer het nodig is. Andere eenheden Wordt er een deel van het beheer in een andere eenheid uitgevoerd? Nee, allemaal intern. Technisch beheer moet volgens mij ICTS doen. Zo ja, zijn er vastgelegde afspraken met andere eenheden wanneer een deel van het beheer daar wordt uitgevoerd? (Noot: Bijv. SLA met ICTS voor applicatiebeheer) Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 8 of 18

113 2.4 Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Wat is de call-routering voor elke groep gebruikers? Nee in dit geval niet. We heb de servicedesk binnen FS. Voor klachtmeldingen en storingen komen daar over het algemeen binnen, afhankelijk van welke klacht het is wordt het naar de juiste stakeholder binnen FS geleidt. Is er een call-routering vastgelegd? Afhankelijk van welke klacht het is, in het systeem staat, deze klacht moet daar naar toe en deze melding moet daar heen. En dat is vastgelegd. Zo ja, waar? [Document] Is de call-routering bekend bij alle gebruikers? Zou bekend kunnen zijn. Zou bij iedereen bekend moeten zijn. Is de call-routering volgens u efficiënt? (Op een schaal van 1 tot 10) Geen interessante vraag, het is zoals het nu is en ja het kan efficiënter. Kan anders maar zijn er mee bezig. We hebben gewoon een servicedesk, zo is het ingericht. Ik vind het geen relevante vraag eigenlijk. Communicatieprotocol Bestaat er een communicatieprotocol met de gebruikers en de overige stakeholders van [Naam]? Ja en nee, volgens die call-routering is dat gewoon zo. Daarin is vastgelegd wie praat met wie en wanneer. Onderhoudsplannen Zijn er onderhoudsplannen voor [Naam] beschreven? Ja, die zijn beschreven. Zo ja, waar? [Document] Voor wie is dit toegankelijk? 2.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap Beoordelen op een schaal van 1 tot 10 Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 9 of 18

114 Basale kennis Heeft u de indruk dat u genoeg basale kennis heeft van informatiesystemen, informatiemanagement en BiSL? Ja, 8. Kennis architectuurprincipes Heeft u de indruk voldoende kennis te hebben van architectuurprincipes? 6. Relatie i-governance en iv-projectportfoliomanagement Heeft u de indruk dat u genoeg begrip heeft van de relatie met de i-governance en ivprojectportfoliomanagement? 7. Voldoende beschikbaar budget Beschikt u over voldoende beschikbaar budget? 10. Dus voldoende beschikbaar budget? Nee, dat zeg ik niet. We hebben budget beschikbaar, alleen we zijn er zelf baas over, dus we programmeren dat meerjarig. dus ja we kunnen het altijd kwijt of schuiven. Dus met geld kom ik altijd uit. Voldoende deskundig personeel Is er u voldoende personeel beschikbaar? Is het personeel voldoende deskundig? 9. Toegang netwerk systeemeigenaren Heeft u voldoende toegang tot het netwerk van systeemeigenaren? Ik weet niet of ik toegang heb. Maakt u gebruik van dit netwerk? Maak er geen gebruik van. Invloed werkzaamheden Heeft u directe invloed op de werkzaamheden van de functioneel beheerders van [Naam]? Niet direct want daar zit mijn onderhoudsmanagement tussen. Die doet het werk voor mij met zijn mensen. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 10 of 18

115 Noodzakelijke communicatiekanalen Heeft u de noodzakelijke communicatiekanalen ter beschikking om over uw IS te communiceren met de eindgebruikers? Ja. 8 Advies centrale informatiemanagers Maakt u gebruik van advies van de centrale informatiemanagers over o.a. technologische ontwikkelingen in uw rol als systeemeigenaar? Dit is wel heel vakspecialistisch, hier komt wel uit de business zelf de ontwikkeling vandaan. 4, het is beperkt. Geschoolde gebruikers Vindt u dat de gebruikers van [Naam] voldoende zijn geschoold? Overige activiteiten waar de systeemeigenaar een rol bij spelt Betrokkenheid innovatie Bent u voldoende betrokken bij de innovatie van uw IS? 7, zit ook bij de inhoudsmensen. Bent u betrokken bij het aanmelden en aansturen van iv-projecten van [Naam]? Ja, 9. Afstemming met centraal informatiemanagement Is er een goede afstemming met centraal informatiemanagement rondom het ivprojectportfolio en overige relevante zaken? 7. Bent u betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken? 10. Betrokkenheid contracten en SLA s Bent u zelf betrokken bij het opstellen van de contracten en SLA s tussen ICTS en externe leveranciers? 10. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 11 of 18

116 2.7 Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS en Ja. Is het beheer van IS opgedeeld in de lagen: a. functioneel beheer b. applicatiecoo rdinatie Nee, dat zit bij elkaar. We hebben iemand voor het gebouwbeheersysteem, twee mensen zelfs, dat zit bij huisvesting in één eenheid. c. applicatiebeheer d. technisch beheer e. hosting en housing? Zijn deze rollen gescheiden? Zijn er lagen uitbesteed? Is dit vastgelegd? Hoe afhankelijk is het IS van deze uitbestedingen? Hoe afhankelijk is de externe partij van UvA/HvA? Afhankelijk is groot omdat het specifieke systemen zijn. Grote afhankelijkheid. Beheerlagen als diensten Worden applicatiecoo rdinatie, applicatiebeheer, technisch beheer, hosting en housing als diensten aangeboden door ICTS? In dit geval zit je hier in een transitiefase, want wij doen eigenlijk alles als je technisch beheer zegt. In het kader van de juiste rollen pakken moet ICTS zijn rol nog nemen. Zo nee, welke lagen niet? Verantwoordelijk lagen Bent u ook verantwoordelijk voor lagen van het beheer die bij ICTS belegd zijn? Zo ja, in hoeverre bent u daar verantwoordelijk voor? Volgens mij ben ik daar verantwoordelijk voor als systeemeigenaar. 2.8 Uitgangspunten m.b.t. functioneel beheer Functioneel beheer intern belegd Is functioneel beheer intern belegd? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 12 of 18

117 Ja, bij ICTS Ingericht volgens BiSL 1 Is uitvoerend en sturend functioneel beheer ingericht volgens BiSL? Weet ik niet. Kunt u de sturende processen noemen die volgens BiSL ingericht? Nee. Systeemeigenaar onderdeel sturende laag Welke besluiten mag de functioneel beheerder zelf nemen? Alles behalve functiewijzigingen volgens mij. Ik ken het protocol niet uit m n hoofd. Voor welke besluiten wordt de systeemeigenaar gevraagd? Autorisaties kunnen ze zelf regelen. Voor functiewijzigingen moeten ze mijn goedkeuring vragen. Maar misschien vat ik nu mijn rol te licht op. Functioneel beheerders zijn onderdeel van de uitvoerende laag van functioneel beheer. Heeft u het idee dat u onderdeel bent van de uitvoerende laag? Ligt eraan op welk niveau je het bekijkt. Als FS-zijnde geven wij uitvoering aan de dienstverlening. Voor gebouwbeheersystemen om gebouwen in te regelen etcetera. Wij zijn dus een en al uitvoering, dat is onderdeel van de operatie, maar draai ik zelf aan de knoppen? Nee. Beleeft u uw rol als operationeel, sturend of strategisch? Ik stuur de operatie zeker niet, dat doen de mensen die gewoon midden in die systemen zitten. Ik ben echt strategisch sturend. FS stuurt die operatie aan, vanuit het systeem gezien ben ik strategsich sturend. Afstand functioneel beheer en systeemeigenaar Hoe dicht staat u organisatorisch bij de functioneel beheerders van [Naam]? Daar zit dus één laagje tussen. Vallen zij onder dezelfde dienst? Ja. Is er sprake van een hiërarchische relatie? Ja, ik geef leiding aan mijn teamleider en mijn teamleider geeft leiding aan die mensen, dus ja. 1 Zie bijlage A. BiSL model Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 13 of 18

118 Vervanging functioneel beheerder Hoe is vervanging geregeld voor de functioneel beheerder? Die lossen elkaar af. Teamleider Onderhoudsmanager neemt het over. Rol functioneel beheerder Hebben de functioneel beheerders een adviserende uitvoerende rol? Ja, en die voeren ze ook uit. Geen applicatiebeheerder of technisch beheerder Voeren de functioneel beheerders applicatiebeheer uit? Ik denk in dit geval wel. Eventueel samen met de leverancier. Dus ja ik denk het wel. functioneel beheerders technisch beheer activiteiten uit? In dit geval wel eventueel samen met leverancier Zijn functioneel beheerders alleen op operationeel niveau betrokken bij contractmanagement? Ja, FB wel. Mijn teamleider zit daar op het tactische niveau, dus ik denk dat dat operationele en tactische activiteiten zijn. Zo nee, op welk niveau nog meer? Tactisch. Key-users en decentrale functioneel beheerders Zijn er key-users benoemd als onderdeel van uitvoerend functioneel beheer? Nee. Zijn er decentrale functioneel beheerders voor [Naam]? Nee. Zo ja, wanneer wordt er met wie gesproken? Operationele BiSL processen Welke operationele BiSL-processen worden afgestemd met de key-users? En met decentrale functioneel beheerders? Wat wordt er afgestemd? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 14 of 18

119 Decentraal functioneel beheerder Is er sprake van een decentraal functioneel beheerder? Zo ja, hoe groot is het aantal van de operationele functioneel beheerprocessen dat volgens BiSL decentraal belegd wordt? Overleg Heeft u regulier overleg met functioneel beheerders? Nooit, dat doet mijn teamleider. Ik zeg even heel zwart-wit nooit. Maar er is geen overlegstructuur. Wel eens periodiek overlegmet teamleider, als er iets buiten de kaders gebeurt. Als het binnen de kaders blijft hoor ik niks. Op ad-hoc basis overleg met FB erbij. 2.9 Uitgangspunten m.b.t. de andere beheerlagen Sturend functioneel beheer Is functioneel beheer van [Naam] sturend t.o.v. andere beheerlagen? Ja, dat is gewoon sturend. Het is zo n klein geheel. Er zijn een beperkt aantal mensen dat heel veel doet. Hoeveel mensen vallen onder dit systeem? Ja, volgens mij zijn er twee mensen en dan heb je nog mijn teamleider. Daarna heb je nog de clustermanagers etcetera en de beveiligingsmedewerkers maar die doen in principe niets met het systeem zelf, ze werken er gewoon mee. Dus er zijn twee mensen die er full-time mee bezig zijn? Nee, dat nog niet eens. Het is gewoon een taak die ze hebben naast hun andere taken. Het is heel marginaal, zeg maar. Neemt applicatiebeheer onafhankelijk van functioneel beheer besluiten? Verantwoordelijkheid Hoe zijn de beheerlagen onder functioneel beheer geregeld? Wie is er verantwoordelijk voor? Vallen die onder de verantwoordelijkheid van ICTS? Nog niet, het is wel bekend dat het gaat veranderen. Misschien is dat ondertussen ook wel in beweging gezet, dat wel. Zijn er beheerlagen geoutsourcet? Zijn ook die beheerlagen de verantwoordelijkheid van ICTS? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 15 of 18

120 Overeenkomsten Is de systeemeigenaar en de service manager(s) van ICTS verantwoordelijk voor het juiste serviceniveau van de dienstverlening overeenkomst tussen ICTS en de dienst / divisie waaronder [Naam] valt? Ik weet niet hoe dat is geborgd. Ik hoop dat wij maar één SLA krijgen met ICTS voor alle applicaties en informatievoorzieningen, want dan maken we het veel makkelijker voor onszelf. Je kunt beter zeggen van ik maak één SLA met ICTS rondom technisch beheer van applicaties en in de Appendix zeg je dan, dit geldt voor deze applicaties. Want het raamwerk staat ten aanzien van wie heeft welke rol voor informatievoorzieningen, dus je wilt niet voor elk systeem aparte afspraken maken. Dat gaan we niet volhouden. Dus ik ben voorstander van één SLA van ICTS met een appendix voor welke systemen die we als FS hebben. ICTS doet technisch beheer voor ons. Appendix kan dan gewijzigd worden. Anders blijven we handtekeningen zetten. Het moet praktisch worden, wat mij betreft. Alsjeblieft. [Gelach] Ik vind het mooi dat we die rollen hebben. Daar hebben we gewoon echt een slag mee geslagen, de afgelopen maanden. Maar laten we het niet tot een bureaucratisch geheel maken. Kijk even naar hoe je die rollen moet invullen. Mensen rond informatievoorzieningen en ICTvoorzieningen hebben nogal de neiging om alles voor elk systeem in te vullen. Dat moet op een hoger niveau kunnen in mijn ogen. Contractmanagement Hoe is het management van contracten geregeld? Contractmanagement ligt bij verschillende eenheden bij FS. Daar zijn we binnen de organisatie mee bezig om dat te veranderen. Dat zit in transitie en dat gaat een jaar duren en daar gaan we binnenkort mee beginnen. Bij wie liggen de contracten? Ik denk dat de contracten hier nog binnen de beheerorganisatie liggen en dat gaan we straks dus anders invullen. Is er verschil tussen contractmanagement voor geoutsourcete en interne dienstverlening overeenkomsten? Het zijn externe systemen, he. Als we naar een externe partij outsourcen hebben we daar gewoon een contract onder liggen. Als we intern de boel verdelen ligt dat vast in de demarcatie of de verdeling van de begroting die we daarvoor hebben. Dus we hebben dat wel geregeld, op zich. Intern zetten we geen handtekening. We hebben geen contracten met elkaar. Dat kan juridisch niet. De verdeling zit bij ons in de zogenaamde demarcatie lijst. Daarin staat wie is waar verantwoordelijk, dan wel hebben we het ingezet in begrotingen. Onderling hebben we dus geen contracten met elkaar. Maar ook niet tussen verschillende divisies? Nee, wat we dus hebben is de SLA, of de dienstverleningovereenkomst. Daar staat dus wel een handtekening onder, maar voor de rest niet. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 16 of 18

121 Maar dat is een soort SLA, toch? Maar dan intern. Dat is een soort SLA, ja. Hetzelfde principe. Applicatiecoördinatie Hoe is applicatiecoördinatie geregeld (ook/juist bij uitbesteding applicatiebeheer) Afspraken met ICTS Zijn er afspraken met ICTS over applicatie- en technisch beheer, hosting en housing? Volgens het raamwerk dus wel. Omdat dat binnen de ICT-governance nu is afgesproken, dus dat is mooi. Zijn die afspraken vastgelegd? Ik weet niet of het vastgelegd is. Wat ik wel weet is dat in het kader van gebouwbeheersystemen er wel nadrukkelijk afstemming is tussen functioneel beheer, technisch beheer. Of dat nou vastgelegde afspraken zijn dat weet ik niet. In hoeverre wordt er aan die afspraken voldaan? Daar is altijd spanning over geweest, tot het moment dat helder werd van hé hoe zit nou die structuur in elkaar en wie moet welke rol invullen? Zeker bij gebouwbeheersystemen, waarbij het een heel technisch systeem is, zie je dat FS als eigenaar van het systeem heel veel naar zichzelf toe heeft getrokken. ICTS had andere prioriteiten. Dat is onze ervaring geweest. Maar ik denk dat dit echt in een transitiefase zit, als je naar gebouwbeheersystemen kijkt. De planning is dat dit bij ICTS komt?3 Ja Afsluiting interview Kunt u aangeven waar de systemen (Science Park en Leeuwenburg) verschillen? Het zijn verschillende systemen met verschillende leveranciers. Het huis dat we hebben ingericht dat staat daar ook wel, dat maakt niet uit. En die zijn ook van hetzelfde niveau, onafhankelijk van welke leverancier? Ik denk dat dat wel gelijk is geregeld, alleen de inhoud van de contracten zal anders zijn. Als je het hebt over de aansturing etc. is dat wel gelijk. Documenten opvragen bij: - Walter de Vries - Metin Kircadag Hoe vond u het interview? Doen jullie dit bij alle informatiesystemen? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 17 of 18

122 Ja. En wat is het doel van het onderzoek? De gap-analyse, het verschil tussen huidige situatie en uitgangspunten. Ja, dan vraag ik me af: Haal je het resultaat wel? Is het een 0-situatie? Ik zit daar even over te twijfelen, of je wel het goede beeld te pakken krijgt. Het waren ook wel heel gedetailleerde vragen. Als systeemeigenaar, ik weet dat nog onvoldoende. Voor mij is dat wel weer verhelderend, maar dat is niet de bedoeling van jullie onderzoek. Maar dat is ook een resultaat. Ja klopt. We hebben ook puur de uitgangspunten genomen voor de vragen. Ja, ik denk dat je dan wel een redelijk beeld kan krijgen. Het is nog zo vers zeg maar, dus wanneer doe je zoiets? Je moet bijna een jaarcyclus hebben doorlopen. Ik weet bij wijze van spreken amper dat ik het ben (systeemeigenaar, red.). Eigenlijk zou je dit een jaar nog een keer moeten vragen. Ja, waar sta je dan, zeg maar. Maar goed, dat kan een aanbeveling van jullie kant zijn. Precies. Dus daarom denk ik dat het interview, en vooral als je andere systemen ook interviewt, een goed beeld geeft. Of er veel nieuwe inzichten uit komen, dat waag ik te betwijfelen. Maar dat komt omdat we daarvoor de jaarcyclus nog niet hebben doorlopen. Maar ik denk dat je een goed beeld zal krijgen. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 18 of 18

123 INTERVIEWS GAP-ANALYSE [Naam] Auteurs : Tim van Bremen, Bart van Eck Versie : 0.7 Datum : Version management Versie Datum Verstuurd naar Doel Kandidaten interview Kandidaten interview Ter voorbereiding interview Ter voorbereiding interview Verwerking antwoorden Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 1 of 15

124 Index Index Introductie interview Interviewvragen VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS VERANTWOORDELIJKHEID VOOR HET BEHEER VAN HET IS VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPELT ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN AFSLUITING INTERVIEW Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 2 of 15

125 1 Introductie interview Wie zijn wij? o Masterstudenten UvA o Afstudeeronderzoek bij HvA/UvA Wat doen we? o Vastgestelde uitgangspunten vergelijken met de huidige situatie o Analyse van verschillen hiertussen o Academische onderbouwing door koppeling met wetenschappelijke literatuur Doel van de analyse o Inzicht verschaffen huidige situatie over verschillende systemen Doel van dit interview o Inzicht verkrijgen over invulling van uitgangspunten voor [Naam] en haar informatievoorzieningen o Niet te beschouwen als evaluatiegesprek Verzoeken tot opname interview o Wissen na afsluiten onderzoek (oktober 2014) Samenvatting interview voorleggen aan geïnterviewde voor eventuele aanpassingen Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 3 of 15

126 2 Interviewvragen Hieronder volgen de vragen die in het interview aan bod zullen komen. U kunt deze ter voorbereiding voor het interview doornemen. Bij sommige vragen staat een document icoon (), welke aangeeft dat er een document vereist is voor een volledige invulling van de vraag. Indien mogelijk kunt u dit document vooraf toesturen of meenemen naar het interview, anders zou dit in de nasleep van het interview gestuurd kunnen worden. 2.1 Verantwoordelijkheid voor de basisinformatie van het IS Lijst van informatiediensten die het IS levert met bijbehorende gebruikers Is er een lijst van de informatiediensten die het IS levert met bijbehorende gebruikers? Ja, er is een lijst met gebruikers. Functioneel beheer zorgt dat mensen autorisaties verkrijgen. Die autorisaties zijn aan de hand van rollen. Je hebt een andere rol voor controller dan voor iemand die bij grootboek werkt. Die lijsten zijn er. Heeft u deze gegevens gevalideerd bij Soenita Sitabi? Nee. Ik weet niet of er een lijst is. Het zit natuurlijk in SAP, daar zijn die autorisaties ook toegekend. Architectuurplaat Is er een architectuurplaat/model van interfaces en data transfer van het IS? Ja, ik heb wel eens iets gezien. Ik zou dat moeten opvragen bij Jacko. Ik heb wel gezien dat er zo n hele architectuur is. [Document] Is deze up-to-date? Geen idee of dit up-to-date is. Heeft u dit model gevalideerd bij Soenita Sitabi? Informatie over betrokkenen Is er een overzicht over welke rol door welke beheerder of partij wordt uitgevoerd? Dat heeft verbanden met de lijst van users. Die zijn gekoppeld aan rollen. Ik weet niet in hoeverre je dat uit kan draaien. Dat zijn eigenlijk de autorisaties, wat ze mogen en wat ze niet mogen. Vroeger had je dat per applicatie in SAP, je mag mutaties verwerken, je mag periodes open zetten. Dat werkte niet goed, dat werd één grote spaghetti op het laatst. We moeten daar rollen voor toekennen. Je hebt een functie, en daar moet je rollen aan koppelen. Daar moet je bepaalde dingen voor kunnen of doen, en dat zijn dan die autorisaties. [Document] Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 4 of 15

127 Wordt dit up-to-date gehouden? Heeft u dit overzicht bij Soenita gevalideerd? 2.2 Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen U bent nu als systeemeigenaar verantwoordelijk voor de volledige beheerketen voor het dagelijks beheer van SAP FICO (HvA) en SAP FICO (UvA), van functioneel beheer tot en met hosting/housing inclusief scholing van de betrokken medewerkers (exclusief scholing van de gebruikers). Beleeft u deze verantwoordelijkheid zo? Nee, nog niet. Ik heb nog niet zo n beeld van wat zo n eigenaarschap inhoudt. Kunt u op dit moment deze verantwoordelijk voor de hele beheerketen dragen? (Op een schaal van 1 tot 10) Heel laag, Ik zou zeggen een 2. Zo nee, wat zou u ervoor nodig hebben? Het was helemaal niet mijn werk eigenlijk. Ik ben Hoofd Verslaggeving. Wat verwacht men nu van de systeemeigenaar? Wat moet die in feite gaan doen? Voor mijn baas is het ook belangrijk wat de belasting in tijd is. Het zou niet zo moeten zijn van Jij bent systeemeigenaar en klaar. We moeten die rollen ook serieus oppakken, anders werkt het niet. In de praktijk moet je ook die rol hebben en de taken en bevoegdheden. Nu zie ik veel dingen bij functioneel beheer, grote dingen als een freeze zou dan met de systeemeigenaar besproken moeten worden. Dat ie dan bij andere mensen een beeld kan vormen of kan bespreken van dit moeten we wel of niet doen, of dit moet een week wachten. Zijn er externe partijen betrokken bij SAP FICO (HvA) en SAP FICO (UvA)? Ja, bij HvA is het uitbesteed aan CTAC, bij UvA ligt het systeembeheer bij ICTS. Vanuit de UvA heeft men veel direct te maken met SAP. Zijn er contracten met die externe partijen? Ja, met CTAC en SAP. [Contract] Hoe is de scholing geregeld van de medewerkers? Geen idee. Wat je nu ziet is dat, wij zijn een afdeling alleen verantwoordelijk voor de planning. We zetten periodes open, balansen draaien, dat soort dingen. We gebruiken de toepassingen. Scholing is eigenlijk op het werk d.mv. nieuwe medewerkers inwerken etc. Functioneel beheer krijgt wel scholing. Bij HvA niet, want daar is FB uitbesteed. FB doet ook wel dingen voor HvA, maar als er bepaalde dingen zijn die FB niet kan of mag naar CTAC of ICTS. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 5 of 15

128 Belegging rollen Zijn de verschillende rollen in de beheerorganisatie helder belegd? Nou, ik denk dat wel duidelijk is. Het is voor mij niet helemaal helder wat de rol is van IC. Rol van FB is duidelijk, rol van ICTS niet echt. Als er een nieuw bedrijf ingericht moet worden, of een nieuw grootboekrekening aangemaakt moet worden, dan ligt dat bij FB. Maar heel helder is het onderscheid voor mij niet. Zijn er beschrijvingen van incidentmanagement? Nee, dat is mij niet bekend. [Document] Zijn er beschrijvingen van wijzigingsbeheer? [Document] Zijn er beschrijvingen van probleemmanagement? Nee. [Document] Zijn er beschrijvingen van configuratiebeheer? Wat ik weet is dat wat ICTS doet. [Document] Escalatieschema s Zijn er escalatieschema s binnen de beheerketen? Nee, is mij niet bekend. Crisisplan Is er een crisisplan? Nee. Updates en upgrades Worden er regulier, planmatig of incidenteel updates/upgrades uitgevoerd bij SAP FICO (HvA) en SAP FICO (UvA) om de continuïteit van het IS en haar IV-diensten te waarborgen (t.b.v. security, compatibility)? Nee, geen idee. 2.3 Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Wie zit er op het tactisch niveau van de gebruikersorganisatie? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 6 of 15

129 Geen idee. Heeft u de indruk dat er hierdoor sprake is van aansluiting op de werkprocessen en behoeften van de organisatie? (Op een schaal van 1 tot 10) Ik weet het echt niet. 1, mij niet bekend. Regie wijzigingenbeheer Wordt er volgens BiSL gewerkt bij functionele wijzigingen in SAP FICO (HvA) en SAP FICO (UvA)? Ik weet niet wat dat is. Bent u daar zelf direct bij betrokken? Nee. Zo ja, hoe? Staat het wijzigingsbeheer op papier? Nee, niet bij mij. Nee, jullie komen eigenlijk net iets te vroeg. Dat is ook wel goed, dat maakt meteen maar helder wat er allemaal nog onbekend is. [Document] Afspraken wijzigingsbeheer Zijn er afspraken gemaakt met de gebruikersorganisatie over de manier waarop de systeemeigenaar de regie over het wijzigingsbeheer voert? Nee, nog niet. Is er sprake van aparte afspraken / onderscheid verschillende partijen m.b.t. het wijzigingsbeheer? Nee. Afspraken interfaces Is er sprake van afstemming met de systeemeigenaren van de informatiesystemen waarmee interfaces bestaan met SAP FICO (HvA) en SAP FICO (UvA)? Nee. Andere eenheden Wordt er een deel van het beheer in een andere eenheid uitgevoerd? Volgens mij ligt helemaal bij AC. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 7 of 15

130 2.4 Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Wat is de call-routering voor elke groep gebruikers? Is er een call-routering vastgelegd? Nee. Communicatieprotocol Bestaat er een communicatieprotocol met de gebruikers en de overige stakeholders van SAP FICO (HvA) en SAP FICO (UvA)? Nee, mij niet bekend. Onderhoudsplannen Zijn er onderhoudsplannen voor SAP FICO (HvA) en SAP FICO (UvA) beschreven? Ze zijn er wel, maar ik heb ze nog niet gezien. Bij die freezes was er een onderhoudskalender, zodat men weet wat er op de planning staat. 2.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap Beoordelen op een schaal van 1 tot 10 Basale kennis Heeft u de indruk dat u genoeg basale kennis heeft van informatiesystemen, informatiemanagement en BiSL? 1. Kennis architectuurprincipes Heeft u de indruk voldoende kennis te hebben van architectuurprincipes? 1. Relatie i-governance en iv-projectportfoliomanagement Heeft u de indruk dat u genoeg begrip heeft van de relatie met de i-governance en ivprojectportfoliomanagement? 1. Voldoende beschikbaar budget Beschikt u over voldoende beschikbaar budget? 1. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 8 of 15

131 Voor welke aspecten van het systeemeigenaarschap heeft u budget beschikbaar? Wordt dit apart begroot? Voldoende deskundig personeel Is er u voldoende personeel beschikbaar? 1. Omdat dat niet bekend is of omdat er niet genoeg personeel is? Gaan we er nu vanuit dat ik dan straks systeemeigenaar ben en dat ik personeel heb om dat uit te voeren? Het enige wat ik waar met mee heb is Functioneel Beheer. Ik weet niet hoe FB straks gaat vallen onder de systeemeigenaar. Dat is ook nog maar de vraag. Ik weet niet hoe men dat ziet. Of dat gebruikelijk is. Toegang netwerk systeemeigenaren Heeft u voldoende toegang tot het netwerk van systeemeigenaren? Nog niet. 1. Maakt u gebruik van dit netwerk? Invloed werkzaamheden Heeft u directe invloed op de werkzaamheden van de functioneel beheerders van SAP FICO (HvA) en SAP FICO (UvA)? Nee, niet direct. Het is net zoals een andere gebruiker dat ik een verzoek indien.. Ik heb daar niet direct iets over te zeggen. Noodzakelijke communicatiekanalen Heeft u de noodzakelijke communicatiekanalen ter beschikking om over uw IS te communiceren met de eindgebruikers? 1. Zo nee, welke kanalen mist u? Advies centrale informatiemanagers Maakt u gebruik van advies van de centrale informatiemanagers over o.a. technologische ontwikkelingen in uw rol als systeemeigenaar? 1. Geschoolde gebruikers Vindt u dat de gebruikers van SAP FICO (HvA) en SAP FICO (UvA) voldoende zijn geschoold? Kunnen ze goed overweg met het informatie systeem? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 9 of 15

132 Ja, 8. Als mensen hun werk kunnen doen is dat dan voldoende? Je zou je kunnen afvragen om mensen Je zou misschien wel een groep mensen ergens heen moeten sturen om meer uit het systeem te kunnen halen. 2.6 Overige activiteiten waar de systeemeigenaar een rol bij spelt Betrokkenheid innovatie Bent u voldoende betrokken bij de innovatie van uw IS? Nee. Bent u betrokken bij het aanmelden en aansturen van iv-projecten van SAP FICO (HvA) en SAP FICO (UvA)? Nee. Afstemming met centraal informatiemanagement Is er een goede afstemming met centraal informatiemanagement rondom het ivprojectportfolio en overige relevante zaken? Het is er volgens mij wel, maar ik zit daar niet in. Bent u betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken? Nee. Betrokkenheid contracten en SLA s Bent u zelf betrokken bij het opstellen van de contracten en SLA s tussen ICTS en externe leveranciers? Nee. 2.7 Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS en Is het beheer van IS opgedeeld in de lagen: a. functioneel beheer b. applicatiecoo rdinatie c. applicatiebeheer d. technisch beheer e. hosting en housing? Weet ik niet Zijn deze rollen gescheiden? Zijn er lagen uitbesteed? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 10 of 15

133 FB FICO (HvA) is uitbesteed, ja ik weet niet, ik weet niet het verschil tussen functioneel en applicatiebeheer. Wij hebben dus een afdeling FB voor SAP zitten bij ons bij AC en ICTS heeft natuurlijk ook een rol. Maar wat die dan precies doen en wat nou precies het verschil is, ik weet ook niet wat CTAC en functioneel beheer dan precies doen. Is dit vastgelegd? Hoe afhankelijk is het IS van deze uitbestedingen? In belangrijke mate. Als we dat niet zouden hebben zou je dat intern moeten oppakken. Hoe afhankelijk is de externe partij van UvA/HvA? Beheerlagen als diensten Worden applicatiecoo rdinatie, applicatiebeheer, technisch beheer, hosting en housing als diensten aangeboden door ICTS? Nee. Zo nee, welke lagen niet? Verantwoordelijk lagen Bent u ook verantwoordelijk voor lagen van het beheer die bij ICTS belegd zijn? Nee. Zo ja, in hoeverre bent u daar verantwoordelijk voor? 2.8 Uitgangspunten m.b.t. functioneel beheer Functioneel beheer intern belegd Is functioneel beheer voor uw IS geoutsourcet? Nee, dat zit intern. Ingericht volgens BiSL 1 Is uitvoerend en sturend functioneel beheer ingericht volgens BiSL? Kunt u de sturende processen noemen die volgens BiSL ingericht? Nee. Systeemeigenaar onderdeel sturende laag Welke besluiten mag de functioneel beheerder zelf nemen? Weet ik niet. 1 Zie bijlage A. BiSL model Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 11 of 15

134 Voor welke besluiten wordt de systeemeigenaar gevraagd? Functioneel beheerders zijn onderdeel van de uitvoerende laag van functioneel beheer. Heeft u het idee dat u onderdeel bent van de uitvoerende laag? Nee. Beleeft u uw rol als operationeel, sturend of strategisch? Ik beleef nog helemaal geen rol. Dat blijkt ook wel uit de antwoorden. Het is slechts een aankondiging geweest. Afstand functioneel beheer en systeemeigenaar Hoe dicht staat u organisatorisch bij de functioneel beheerders van SAP FICO (HvA) en SAP FICO (UvA)? Nog niet. Vallen zij onder dezelfde dienst? Is er sprake van een hiërarchische relatie? Nee. Vervanging functioneel beheerder Hoe is vervanging geregeld voor de functioneel beheerder? Nee, het is een afdeling. De vervanging is intern geregeld. Zo ja, wie vervangt de functioneel beheerder? Rol functioneel beheerder Hebben de functioneel beheerders een adviserende uitvoerende rol? Nee, volgens mij zijn zij ook nog niet op de hoogte van mijn rol. o (Nemen ze zelf geen besluiten over de functionele inrichting en/of gebruikersautorisaties van het IS zonder uw akkoord?) Geen applicatiebeheerder of technisch beheerder Voeren de functioneel beheerders applicatiebeheer uit? Geen idee. Voeren de functioneel beheerders technisch beheer activiteiten uit? Zijn functioneel beheerders alleen op operationeel niveau betrokken bij contractmanagement? Zo nee, op welk niveau nog meer? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 12 of 15

135 Key-users en decentrale functioneel beheerders Zijn er key-users benoemd als onderdeel van uitvoerend functioneel beheer? Nee. Zijn er decentrale functioneel beheerders voor SAP FICO (HvA) en SAP FICO (UvA)? Zo ja, wanneer wordt er met wie gesproken? Operationele BiSL processen Welke operationele BiSL-processen worden afgestemd met de key-users? Geen idee. Het hele BiSL zegt mij niets. En met decentrale functioneel beheerders? Nee, denk het niet, heb het nooit gehoord dat daar sprake van is. Wat wordt er afgestemd? Decentraal functioneel beheerder Is er sprake van een decentraal functioneel beheerder? Nee, dat SAP FICO is echt centraal beheerd. Zo ja, hoe groot is het aantal van de operationele functioneel beheerprocessen dat volgens BiSL decentraal belegd wordt? Overleg Heeft u regulier overleg met functioneel beheerders? Nee. Zo ja, op wat voor frequentie? Waarom is er gekozen voor deze frequentie? 2.9 Uitgangspunten m.b.t. de andere beheerlagen Sturend functioneel beheer Is functioneel beheer van SAP FICO (HvA) en SAP FICO (UvA) sturend t.o.v. andere beheerlagen? Neemt applicatiebeheer onafhankelijk van functioneel beheer besluiten? Weet ik niet. Verantwoordelijkheid Hoe zijn de beheerlagen onder functioneel beheer geregeld? Geen idee. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 13 of 15

136 Wie is er verantwoordelijk voor? Weet ik ook niet. Vallen die onder de verantwoordelijkheid van ICTS? Weet ik niet. Zijn er beheerlagen geoutsourcet? Zijn ook die beheerlagen de verantwoordelijkheid van ICTS? Overeenkomsten Is de systeemeigenaar en de service manager(s) van ICTS verantwoordelijk voor het juiste serviceniveau van de dienstverlening overeenkomst tussen ICTS en de dienst / divisie waaronder SAP FICO (HvA) en SAP FICO (UvA) valt? Ik weet het niet. Hoe blijkt dit in de praktijk? Contractmanagement Hoe is het management van contracten geregeld? Volgens mij loopt dat nu allemaal via ICTS voor SAP. Liggen de contracten bij ICTS? Is er verschil tussen contractmanagement voor geoutsourcete en interne dienstverlening overeenkomsten? Dat weet ik niet. In sommige gevallen is het misschien wel duidelijker dat het bij de externe partij er een wat zakelijkere opstelling is. Het zit in een contract en er wordt voor betaald. Intern wordt er ook wel betaalt, maar ik denk dat de beleving anders is. Betrekt ICTS u bij de beheeractiviteiten met externe leveranciers van beheeractiviteiten? Applicatiecoördinatie Is er sprake van applicatiecoördinatie? Ja, dat is er wel. Hoe dat precies zit dat weet ik niet, dat zou Jacco moeten weten. Het is inherent aan zo n ERP systeem. We hebben te maken met SAP HR, SAP FICO, iets voor inkoop. Alles vertaalt zich financiëel, dus naar FICO. Wat ik begrepen heb is dat daar wel overleg over is, daar zijn wel afspraken over. Is een deel van het applicatiebeheer uitbesteed? Zo nee, waarom is er toch gekozen voor applicatiecoördinatie? Afspraken met ICTS Zijn er afspraken met ICTS over applicatie- en technisch beheer, hosting en housing? Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 14 of 15

137 Weet ik niet. Zo ja, wordt er aan die afspraken voldaan? Afsluiting interview Ik weet niet hoe je ervaring is met andere systeemeigenaren? Misschien waren dat mensen die al systeemeigenaar waren. Volgens mij was onze directeur het voor mij. Die deed er volgens mij niet zoveel mee en legde alles bij Jacco neer. Er zal aan gewerkt moeten worden. Er komt wel wat op me af geloof ik. Alle uitgangspunten zijn net aan bod gekomen. Je hebt best kans dat er al dingen geregeld zijn. Wat ik uit de mail van Sanne begreep is dat ze de systeemeigenaren begeleiden. Dat missen we een beetje. Ja, ik heb een mail gehad en heb dat stuk gelezen. Maar, en dan? Hoe ga je dat dan aanvliegen? Dan moet je op een gegeven moment ook een duidelijk beeld hebben van de systeemeigenaar van dit is die persoon en dit is zijn rol. Anders denkt iedereen maar ja, wat heb ik daarmee te maken? en gaan ze op de oude voet door. Het is niet 1,2,3 geregeld. Wat vond u van het interview? Nou, de aanpak die jullie doen vind ik allemaal heel helder. Maar wat ik zeg: het is jammer dat ik op 99% moest antwoorden van ik weet het niet. Daar zit in ieder geval een duidelijke boodschap in. Ja, ik kan wel gissen van hoe het zou moeten zijn. Wij vinden straks een mooie gap en dan kunnen we misschien zeggen van hoe het beter kan. Dus misschien gaan ze dit over een jaar nog een keer vragen. Er zou begeleiding moeten zijn. Ik wil heel duidelijk hebben wat er wordt verwacht. Wat is mijn relatie dan t.o.v. van functioneel beheer, ICTS, wat is mijn zeggenschap, wie moet ik erbij halen als er vraagstukken komen, gremia, procedureel. Het moet gewoon heel duidelijk zijn en afgebakend. En ik wil weten hoeveel tijd het kost. Mijn baas doet er nogal soepel over en zegt van ja, dat zien we wel maar dat wil ik wel weten. Als ik er een dagtaak aan heb is het voor mij belangrijk om te weten. Ik kan zeggen ik ben hoofd Verslaggeving, ik heb een afdeling met zes man en ga over de jaarrekening, afsluitprocedures en administratieve organisatie en dan dit erbij. Als ik het moet doen, dan wil ik ook dat het serieus wordt aangepakt. Als het gewoon heel veel tijd kost dan of moet je er iemand anders voor nemen of kijken hoe je dat gaat doen met het andere werk. En je moet kijken hoe je dat doet met de cultuur van de HvA en UvA. Je moet ook de bestaande structuur af- en doorbreken. Mensen hebben de neiging om te denken het zal allemaal wel wat ze ergens beslissen. Het gaat al jaren goed zo, en ik blijf dit gewoon doen. Dat is ook een taak voor [Naam], om op een gegeven moment ook over te brengen van: het is nu echt fundamenteel anders en zo gaan we verder. Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA Page. 15 of 15

138 Appendix F Presentation Slides IT Governance at Higher Education Institutes in Amsterdam Evaluating Business Process Requirements for Large-Scale Education Sector IT Governance and Change: A Case Study Student T.M. van Bremen University of Amsterdam bremen@uva.nl University Supervisor Dhr. drs. A.W. Abcouwer University of Amsterdam Case Supervisor Mw. S.W. Nolst Trenité University of Amsterdam T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Content Case study introduction Problem statement Research question Theoretical background Method Results Change management Discussion Case study introduction Internship Universiteit van Amsterdam Hogeschool van Amsterdam April-July 2014 Together with Bart van Eck There and back again Summer 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Case study introduction Three shared service departments Administrative services Facility services ICT services Case study introduction But both business and IT governance are poorly understood. IT governance just happens in many enterprises. IT governance is not actively designed to achieve business objectives and desirable behaviors. Effective IT governance arrangements thoughtfully and purposefully combine decision making about major IT domains, by the right group of people, using appropriate mechanisms. Verbetertraject ( ) T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

139 Appendix F Presentation Slides Case study introduction Problem statement Assigning system owners to each information system Responsible for the availability and quality of the information provision services that one information system should deliver Requirements List of requirements that should be fulfilled for an optimal level of performance Responsibilities Skills Management layers T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Problem statement A lot of information systems Management is poorly done 1. Implement requirements 2. Fulfill requirements 3. Profit. Problem statement A lot of information systems Management is poorly done 1. Implement requirements 2. Fulfill requirements 3. Profit T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Research question To what extent do the information provision services at the collaborating services of the two institutes fit the newly stated requirements? (Compare the current situation with the optimal situation where all requirements are met) Theoretical background IT Governance is the strategic alignment of IT with the business such that maximum business value is achieved through the development and maintenance of effective IT control and accountability, performance management and risk management (Webb, Pollard, & Ridley, 2006, p. 2) Effective IT governance arrangements thoughtfully and purposefully combine decision making about major IT domains, by the right group of people, using appropriate mechanisms. (Broadbent, 2002) By clarifying who is able to make critical decisions and who is accountable for them, organizations are better able to deal with complexity. Broadbent further states that IT governance specifies the decision rights and accountability framework to encourage desirable behavior in the use of IT (Broadbent, 2002, p. 1) T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

140 Appendix F Presentation Slides Theoretical background Centralization of decision rights May lead to increased organization efficiency (Bester, 2009) May jeopardize communication by making the agent concerned about being overruled Although it can also favor communication when the agent trusts his superior (Aghion and Tirole, 1997) Robinson and Stocken (2013) suggest that the costs of inappropriately centralizing decision rights are lower than the costs of inappropriately decentralizing decision rights Method Fit-gap analysis Evaluate business processes achieving a specific goal Steps: 1. Identifying current performance 2. Identifying desired performance and gap 3. Addressing the gap T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Method Investigated 17 information systems 15 Interviews 7 System owners Method Discuss every requirement with system owners Translate requirements to interview questions: 4 Business process managers 1 Team coordinator T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Method Discuss every requirement with system owners Translate requirements to interview questions: Method Quality assessment of every requirement for every system Required documents (proof) Self-assessment General consensus of knowledge derived from answer T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

141 Appendix F Presentation Slides Method Results Documenting results T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Results Research question To what degree do the requirements improve change management? T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Theoretical background The process of continually renewing an organization s direction, structure, and capabilities to serve the ever-changing needs of external and internal customers (Moran & Brightman, 2000) For this study change management applied to the information systems, its employees, (at the shared services as well as scattered over the different faculties and departments), IT contractors and all the students. Theoretical background Finding some common ground on competences: Rank Skill Description Asking the right questions in order to obtain the information 1 Interviewing needed. Giving instructions and communicating user requirements to 2 Directing programming and support staff. 3 Managing Planning, organizing and controlling projects. 4 Speaking Presenting your ideas in a manner easily understood by your audience, both in group meetings and person to person. 5 Listening Paying attention to and concentrating on what is being said, and asking questions that refine points about which one is uncertain. (Jiang et al., 1998) T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

142 Appendix F Presentation Slides Theoretical background Taxonomy of assessment scales for technochange managers (Harison & Boonstra, 2009) Competence Information technology and information systems (IS/IT) know-how Organizational Change Technochange Risk and success factors Communication Process management Leadership Consequences of change Description Actual knowledge of the IS/IT field and experience in IS/IT projects in leading and responsible positions Knowledge of the field of organizational change and organizational development and experience in OC/OD projects in leading and responsible positions. Understanding of organizations in their context Knowledge of the process of IT-related organizational change and insight into the implications of such change for organizations. Experience in technochange projects in leading and responsible positions. Insight into essential risks and success factors of technochange. Experienced in using these factors during technochange projects. Able and experienced in conducting interviews, writing reports, present findings, listening, motivate and convince people Capable of and experienced in planning, managing and evaluation the process of IT-related organizational change Experience in directing and leading IT and organizational change projects. Able to provide direction, to facilitate and to advise managements, project employees and others with regard to the project. Empathic, diplomatic and skillful in organizational politics Able to recognize and anticipate consequences of technochange programmes Conclusion The current situation do not fulfill the requirements very well Possible reasons: Recency of the implementation Lack of guidance The system owner s intrinsic set of competences was assessed rather well It might make the fulfillment of the other requirements easier to achieve It all hints toward a request for more time, guidance and counsel T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Conclusion Aided in raising awareness of the implementations I1: It was like an awakening. My knowledge was not that bad at all. The details proved to be hard to think of. [ ] On the one hand I think: I know quite a bit about it, at other times I think I don t know enough on this subject. Which is a good thing, because it makes me think about those things. Conclusion Change management The requirements did not overlap much with the behavioral competence taxonomy derived from the literature study. Behavioral traits are evaluated at the time of the hiring of an employee and should therefore not have to be included in requirements for a new role inside the organization. Including these competences in the requirements might aid in selecting the right people for the ownership, when existing ones have to be replaced T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Conclusion When compared with the technochange competences taxonomy derived from the literature study, more correspondence was discovered. Both sets required knowledge of the process of IT-related changes and its implications. Communication and leadership competences were represented by requirements stating meetings, close collaboration with business process management, other departments, suppliers and users. Questions T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

143 Appendix F Presentation Slides Extra: Validity Limitations of this study: Doubts about the nature of numerical measurements The self-assessment methods used for some requirements Extra: HvA The reliability of this study was estimated as relatively high, mainly due to a strict approach towards the interview procedure. T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Extra: UvA Extra: Results T.M. van Bremen IT Governance at Higher Education Institutes August 2014 T.M. van Bremen IT Governance at Higher Education Institutes August 2014 Extra: Coding Extra: Requirements T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

144 Appendix F Presentation Slides Extra: Requirements Extra: Requirements Extra: Requirements T.M. van Bremen, 2014 IT Governance at Higher Education Institutes