IT Governance at Higher Education Institutes in Amsterdam

Master Thesis - Information Studies

IT Governance at Higher Education Institutes in Amsterdam T.M. van Bremen Student no.: 6304257 Supervisor: drs. A.W. Abcouwer Case supervisor: Mw. S.W. Nolst Trenité Second reader: dr. T.M. van Engers

14th August, 2014

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 [email protected] 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.



1. Introduction The collaborating services of UvA and HvA1 - 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 organized2. 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



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


3



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.


4



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

http://www.isaca.org


5


• • •


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

7

Cooperation

8

Patience

9

Leadership

10

Sensitivity

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. Working with others productively 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. Being aware of implications to the community

Table 1. Behavioral skills (Jiang, James J., Klein, Gary, Margulis, 1998)


6



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

Description

Information technology and information systems (IS/IT) know-how Organizational Change

Actual knowledge of the IS/IT field and experience in IS/IT projects in leading and responsible positions

Technochange

Risk and success factors Communication Process management Leadership

Consequences of change

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.


7



A theoretical framework on which the requirements are partly based is represented by the use of the Business Information Services Library, or BiSL5. 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 management6

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 follows7: 1. 2. 3.

Identifying Current Performance Identifying Desired Performance and Gap 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.

5

www.aslbislfoundation.org

6

Functioneel beheer in Dutch , according to Outvorst & van der Pols (2005)

7

http://www.ehow.com/way_5263188_gap-analysis-technique.html


8



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 manager8. 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

I1

30-04-14

10:00-11:00

SE

FS

01:00:34

I1(cont.)

06-05-14

13:30-14:00

SE

FS

00:27:34

I2

09-05-14

13:00-14:00

SE

FS

00:43:14

I3

12-05-14

13:00-14:00

SE

AC

00:43:22

I4

14-05-14

13:00-14:00

SE

ICTS

00:45:52

I5

16-05-14

10:00-10:30

FB

FS

00:26:50

I6

16-05-14

14:30-15:00

FB

ICTS

00:20:37

I7

19-05-14

11:00-12:00

SE

AC

00:48:37

I8

21-05-14

08:30-09:30

SE

ICTS

00:35:16

I9

21-05-14

11:00-12:00

SE

ICTS

00:45:22

I10

22-05-14

15:00-16:00

SE

AC

00:56:36

I11

26-05-14

10:00-10:30

TC

FS

00:41:05

I12

26-05-14

11:00-11:30

FB

ICTS

00:14:37

I13

27-05-14

10:00-11:00

FB

FS

00:23:50

I14

27-05-14

11:00-12:00

SE

ICTS

00:15:59

I15

28-05-14

10: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)


9



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.


10



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.


11


ID Name Fucti on Owner Requirements ID


IS1 Name Kaartmanagementsysteem Name

De scription Verantwoordelijkheid basisinformatie

R3.1 R3.1.1 R3.1.2

Basisinformatie Lijst IV-dienste n en gebruike rs Architectuurplaat

R3.1.3

Inf ormatie over be trokkene n Totaal

R3.2

Verantwoordelijkheid voor het beheer van het IS

Aantal

Beschikbaar

Geval ideerd

Schaal/gradatie/kwali teitsinschatting Likert 1-5

Toeli chting

Nee Ja

Nee Ja

Beoordeli ng

1 5

Toegezegd. Niet gevalideerd.

Nee

Nee

1 1

Systeemei genaar

Functioneel beheerder

3

R3.2.1

Volledige be heerketen

3

3

R3.2.2

Belegging roll en

4

4

R3.2.3

Escalatieschema’s

Nee

2

R3.2.4

Cri sisplan

Nee

2

R3.2.5

Updates en upgrade s Totaal

Nee

2

2 3

R3.3

Verantwoordelijk voor afstemming en afspraken met andere partijen

R3.3.1

Afstemmi ng gebruike rsorganisatie

2

2

R3.3.2

Regie w ijzi gingsbeheer

3

3

R3.3.3

Afspraken wij zigingsbeheer

R3.3.4

Afpraken met relevante SE'en

R3.3.5

Afspraken met andere e enheden Totaal

2

3

5

Nee

3

Nee

3

3

Nee

3

3

2

2 3

Ja

4

4

5

R3.4

Verantwoordelijk voor de communicatie met ( eind)ge bruikers

R3.4.1

Call -routering

R3.4.2

Communicatieprotocol

Nee

3

3

R3.4.3

Onderhoudsplannen Totaal

Nee

3

3 3

3

R3.5 R3.5.1 R3.5.2 R3.5.3

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Ke nnis architectuurprinci pes Relati e i-gove rnance en iv-proj ectportfoliomaangement

4 4 4

4 4 4

R3.5.4

Voldoende beschikbaar Budget

2

2

R3.5.5 R3.5.6

Voldoende deskundig pe rsoneel Toe gang netwerk syste emei genaren

2 4

2 4

R3.5.7

Invl oed werkzaamhe den

5

R3.5.8

Noodzakel ij ke com municati ekanale n

4

4

R3.5.9

Advies centrale informatiemanagers

3

3

R3.5.10

Geschoolde gebrui kers Totaal

4

4 4

R3.6

Overige activiteiten waar de systeemeigenaar een rol bij speelt

R3.6.1

Betrokkenheid i nnovatie

3

3

R3.6.2 R3.6.3

Afstemmi ng centraal IM Betrokkenheid contracten en SLA's Totaal

4 3 3

4 3 3

29

3

Totaal R3

4

10

5

R4

Uitgangspunten bij het beheer van de informatiesystemen

R4.1

Alge mene uitgangspunten m.b.t. beheer

R4.1.1

Opdeli ng beheer IS

3

3

R4.1.2

Invull ing applicatiecoördinatie

4

4

R4.1.3

Beheerlagen als dienste n

3

3

R4.1.4

Verantwoordeli jkheid ve rschill ende behe erlagen Totaal

2

2 3

4

Beschikbaar. Gevalideerd. Leveranciers per s ysteem. Niet voor elk subsyst eem gevalideerd.

Applicatiebeheer uitbesteed aan ICTS. De rest van de verant woordelijkheid goed te dragen. Ex terne partijen zijn erbij betrokk en. Per systeem vers chilt het of er contracten zijn of niet. Scholing is niet gestruct ureerd geregeld. Verschil in kennisniveau. Basiskwalificatie. Wel opleiding, geen verplichtingen. Rollen zijn helder belegd. Splitsing t ussen funct ioneel en applicatiebeheer expliciet. Niet vast gelegd. Wel voor incident- en probleemmanagement, wijzigingen configurati ebeheer. Er zijn esc alat ieschem a's bekend, m aar ni et vast gelegd, wel in gebruik. Crisisplannen zi jn er en gedocumenteerd. Echt er i s dit niet bekend in alle lagen van de beheerorganisat ie. FB: Crises deels binnen het sy steem afgevangen. Regulier worden er updates en upgrades gedaan. Som s is dit vastgelegd in een releaseplan, maar dit is bij sommige systemen niet nodig.

Éénm aal per kwart aal overleg tussen FB 'er en leveranci ers diensten. Niet door SE'er. Zo veel mogelijk volgens B iSL. S E direct betrokk en. Wi jzigingen worden overlegd. SE gaat uit eindelijk over al le wijz igingen. Overleg met FB-groep, applicatiecoördinator en evt. leveranci ers. Afsprak en best aan informeel en gebeuren incidenteel, maar ze zijn er wel. Niet voor alle systemen. Capaci teit sprobleem.

Call-routering is vastgel egd, ook i n een document. Deze is bekend bij gebruikers, echter gaan sommigen direct naar de afdeling i.p. v. Servicedesk . Qua efficient ie krijgt de call-routering een 8. Geen st andaardplan. Er wordt wel gecommuniceerd, maar per i ssue. Niets i s vastgelegd. Het meeste gaat via afdeling communicat ie. Er zijn onderhoudsplannen, maar niet voor alle systemen. Deze z ijn gedocumenteerd en alleen in te zien door syst eem beheerder en Koen (coördinatie funct ioneel beheer)

Ja en nee. Budget voor onderhoud en beheer. Apart begroot . Nee. Aantal panden en gebruikers stijgt. Capaciteit ni et. Ja, CIM. Wordt gebruik van gemaakt . Zeker. Heel direct. FB: Heel veel gaat via mij, maar als het belangrijker is -> SE. Heeft noodzak elijke communicatiekanalen. Soms afhankel ijkheden, bijv. voor c omm. m et studenten. Nog niet aan de orde geweest . SE z ou er wel gebruik van maken. Niet veel scholing vereist bij dit s ysteem, betreft het gebruik van een pas.

Direct bet rokk en en voldoende op de hoogte van alle nieuwe ontwikkelingen. Zeer goede afstemming en indirect bet rokk en bij de relatie tuss en het IS en de HvA/UvA werkplekken. Nee, is nog t e recent.

Rollen zijn gescheiden, alleen applicat ie en technisc h beheer zijn samen. Host ing kan binnenshuis of erbuiten zijn, dit vers chilt per systeem. Erg afhankelijk van ext erne part ij wanneer een laag is uitbest eed. Applicatiebeheer is niet uitbesteed, coördinatie ligt bij ICTS. Technisc h en applicatiebeheer is belegd bij ICTS. Soms ook hosti ng, dit l igt er aan om welk systeem het gaat. Nee, ligt bij ICTS. Hosting en KMS i s extern. Verantwoordelijk voor uitvoering van contract.

R4.2 R4.2.1 R4.2.2 R4.2.3

Uitgangspunten m.b.t. functionee l beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onde rdeel sturende l aag FB

5 5 4

5 5 4

R4.2.4

FB'er onde rdeel uitvoe rende l aag FB

4

4

R4.2.5

Afstand functioneel be heer en systeeme igenaar

4

4

Ja. Mag wel minder uitvoerend (-> huism eest ertak en). Zit een coördinator tussen. Wel direct cont act en leidinggevende.

R4.2.6

Vervangi ng functionee l beheerde r

5

5

Int ern 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

Rolbeleggi ng functioneel beheerder

2

2

Rol te uitvoerend. Zouden ook moeten adviseren over proc essen, maar dit gebeurt te weinig.

R4.2.8

Geen appli catiebehe er of technisch beheer

5

2

4

R4.2.9

Ke y-users benoe md

2

4

3

R4.2.10 R4.2.11

Afstemmi ng operati one le BiSL processen met key-users Ke y-users/decentraal FB'er onderdeel functi one el be heer

R4.2.12

Overleg SE met FB'e r Totaal

R4.3

3 3 4

3 3 4

12

4 4

Ja. Meerdere mensen die FB uit voeren. Ja, dest ijds geïmplem ent eerd door Sanne.

Belegd bij ICTS. FB: Ook applicatiebeheer. Soms t echnisch beheer. Niet benoemd. Input users puur via event uele individuele calls. Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. Geen decentrale belegging. Ja, maandelijks. Ook met applicatiebeheerder.

Uitgangspunten m.b.t. de ande re beheerlagen

R4.3.1

FB stuurt overige be heerlagen

5

5

Ja, is sturend. ICTS naar aanleiding van wens, wijziging of probleem aan tafel met leveranci er. Dit gaat op initiat ief van FB . Applicat iebeheer neem niet onafhankelijk van FB besluiten. FB : M eest al wel, maar technisc h beheer heeft ook z ijn eigen agenda.

R4.3.2

SE ei ndverantwoordeli jk voor beheerl agen onder FB (vi a ICTS)

3

3

Niet verantwoordelijk voor di enst en belegd bij ICTS.

R4.3.3

SE en servicemanager ve rantwoordel ijk voor servicenive au ove ree nkomsten

2

2

R4.3.4

ICTS verantw oorde lij k voor contractmanagement

3

3

R4.3.5

Afspraken ICTS met systeemeigenaar over AB, TB H&H Totaal

3 6

3 3

22 51

3 3

Totaal R4 All e uitgangspunten

4

Wel verantwoordelijk. Overeenkom sten niet vastgelegd. Contracten liggen bij beide (FS en ICTS). Capacit eitsprobleem ICTS. Afspraken zi jn 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.


12



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

Poor

No knowledge

Available

Not validated

Poor knowledge

Unavailable

Not validated

Poor Knowledge

Available

Validated

No knowledge

Available

Not validated

2 Adequately 3 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 Verantwoordelijk heid basisinformatie

Beschikbaar

Gevalideerd

Schaal/grada tie/kwaliteits inschatting

Beoordeling

Toelichting

Likert 1-5 System owner

BPM

R3.1 R3.1. 1

Basisinformatie Lijst IV-diensten en gebruikers

Nee

Nee

1

R3.1. 2

Architectuurplaat

Ja

Ja

5

Beschikbaar. Gevalideerd.

R3.1. 3

Informatie over betrokkenen

1

Leveranciers per systeem. Niet voor elk subsysteem gevalideerd.

Totaal

Nee

Nee

Toegezegd. Niet gevalideerd.

1 Table 7. Method of documenting results fit-gap analysis.


13



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. 4.1.1. 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]. 4.1.2. 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]. 4.1.3. 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]. 4.1.4. 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]. 4.1.5. Conditions for quality fulfilment of system ownership Basic knowledge of information management, systems and architecture [R3.5.1-2]. 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].


14



4.1.6. Other activities Involvement in innovation of information system Involvement with contracts and SLAs [R3.6.3].

[R3.6.1].

Alignment central information management

[R3.6.2].

Requirements for management of information systems 4.1.7. 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]. 4.1.8. 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]. 4.1.9. 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].


15

1 1

Verantwoordelijkheidbasisinformatie

Responsibilityfor basicinformation

Listof informationprovisionservicesanditsusers

Architectural model

Informationoninvolvedparties

Total

R3

R3.1

R3.1.1

R3.1.2

R3.1.3

2 2,5

Roleallocation

Escalationscenarios

Crisisplans

Updateandupgrademanagement

Total

R3.2.2

R3.2.3

R3.2.4

R3.2.5

University of Amsterdam 3

Total

R3.3.4

R3.3.5

3 3

Communicationprotocol forthecommunicationwithendusers

Maintenance plans

Total

R3.4.3

Relationwiththehigherlevel i-governance andinformationprovisionproject portfolioman 4agement

4 4

Basicknowledgeof architecture

Budget control

Skill employees

Accessto the networkof systemowners

Influence ondailyworkof management layers

Availablecommunicationchannels

Advicefromcentral informationmanagers

Educationof endusers

Total

R3.5.2

R3.5.3

R3.5.4

R3.5.5

R3.5.6

R3.5.7

R3.5.8

R3.5.9

R3.5.10

3 3 3

Alignmentcentral informationmanagement

InvolvementwithcontractsandSLAs

Total

Total R3

R3.6.2

R3.6.3

2 3

Systemownerresponsiblefor all layers

Total

3 3

3

3 3

3 3

2

2,5

3

2

3

Alleuitgangspunten

3

3

R4

3

3

3

3

R3

2

3

2

3

2,5

2

1

1

1

1

5

4

3

3

2

3

2

3

2

2

1

1

1

1

5

3

3

3

3

2

3

5

3

3

3

4

2

4

4

4

3

1

5

3

3

2

3

5

4

3

3

3

4

2

4

4

5

3

1

3

2

3

2

Total

R4.3.5

3

2

3

5

4

3

3

3

4

2

5

4

4

4

2

3

2

ICTServicestakes careinprovidingsufficient availableandqualifiedapplicationmanagemen 3 t, technical manageme 3ntandhostingandhou3 singtofulfil demandso3 f the systemowner

ICTServiceshandlesallcontractsandinvolvesall relevantsystemowners

R4.3.4

Total

The systemownerisresponsiblefortheservicelevel contractsandSLAs

Regular meetingswithbusinessprocessmanagementwithafrequency that correspondsw4 iththedynamicity of the 4IS

R4.2.12

The other layersaremanagedbyICTServices

Key-userspartof businessprocessmanagement

R4.2.11

R4.3.3

Alignmentof operational processeswithkey-users

R4.2.10

R4.3.2

Appointmentof key-usersdependingontheneedforkey-usersof theIS

R4.2.9

Businessprocessmanagementcontrolstheotherlayers

Businessprocessmanagersdonot performapplicationortechnical management

R4.2.8

Requirementsregardingothermanagementlayers

Businessinformationmanagershaveanadvising role

R4.2.7

R4.3.1

4

Replacementof business informationmanager(s)

R4.2.6

R4.3

4

Businessprocessmanagersareplacedas closetothesystemowner aspossible

4

4

5

R4.2.5

4

4

5

Businessprocessmanagersareworkingonanoperational level

R4.2.4

5

Systemownerispartof thecontrollingpartof businessinformationmanagementlayer

R4.2.3

5

BusinessprocessmanagementdesignedaccordingtoBiSL

R4.2.2

5

Businessprocessmanagementisdone internally

R4.2.1

5

Businessprocessmanagementrequirements

3

2

R4.2

3

2

3

2

R4.1.4

3

2

Different layersareofferedtothe systemownersasservicesby thedifferent relevant depa 3rtments

4

Applicationcoordination

4

Divisionof management of informationsysteminpredefinedlayersof functional managem 3ent, applicationcoordina 3 tion, applicationmana 3gement, technical man2 agementandhostingan 2dhousing

R4.1.3

4

General requirements

3

4

5

4

4

4

4

2

4

2

1

5

5

4

3

4

2

2

1

4

2

1

3

2

2

4

4

1

1

4

4

4

1

1

1

1

R4.1.2

4

4

5

4

4

4

4

2

4

2

1

5

5

4

3

4

3,5

4

1

4

4

1

4

4

4

4

2,5

1

1

3

4

4

1

1

1

1

Name

IS5

Uitgangspuntenbij het beheervande informatiesystemen

3

3

3

4

3

4

4

3

4

5

4

2

2

4

4

4

3

3

3

4

3

2

3

4

3

2

2,5

2

3

2

4

3

1

1

5

1

GBS-LWB(HvA)

IS4

R4.1.1

3

3

3

4

3

4

4

3

4

5

4

2

2

4

4

4

3

3

3

4

3

2

3

3

3

2

2

2

2

2

4

3

1

1

5

1

Name

IS3

R4.1

Name

IS2

R4

4

Involvementininnovationof informationsystem

R3.6.1

3

Otheractivities

R3.6

3

4

5

4

2

2

4

Basicknowledgeof informationmanagementandsystems

R3.5.1

4

Conditionsforqualityfulfilment of systemownership

R3.5

3

Call-routingschematics

R3.4.2

4

3

R3.4.1

Responsibilityfor the communicationwithendusers

Writtenagreementswithotherunitswhenthe managementisdistributed

R3.3.3

R3.4

Agreementswithuserorganizationoncontrol over changemanagement

Alignmentwithsystemownersof otherinformationsystemswhichhave interfaceswiththe 3IS 2

Control overchange management

R3.3.2

3

Alignmentwithuserorganisation

R3.3.1

2

Responsibilityfor alignmentandagreementswithotherparties

R3.3

3

2

4

Responsibilityfor the completechainof management

R3.2.1

3

Responsibilityfor management of IS

R3.2

5

Name

Description

ID

1

IS1

Requirements

3

2

2,5

3

3

2

3

2

3

2

2

1

1

1

1

5

3

3

5

3

1

3

2

3

2

2

2

4

4

5

4

4

4

4

2

4

2

1

5

5

4

3

4

2

2

1

4

4

1

4

4

4

4

3,5

1

1

4

4

4

1

1

1

1

GBS-KMH(HvA)

IS6 Name

IS7

1

1

1

1

1

5

1

1

1

1

1

1

1

1

1

1

3

1

1

1

1

5

1

1

1

1

2

1

1

1

1

1

1

4

1

1

1

1

1

1

1

1

1

2,5

3

1

3

1

3

1

1

1

1

1

1

1

1

3

1

1

1

3

1

Name

IS8

1

1

1

1

1

5

1

1

2

1

1

1

1

1

1

1

3

1

2

2

1

5

1

1

1

1

2

1

1

1

1

1

1

4

1

1

1

1

1

1

1

1

1

1,5

3

1

2

1

3

1

1

1

1

1

1

2

1

3

1

1

1

3

1

Name

IS9

1

2

1

1

1

1

1

2

1

2

2

5

1

4

2

1

1

2

4

4

1

5

2

1

4

1

3

1

1

1

3

1

2

3

1

2

1

1

2

1

3

4

4

3

3

1

3

1

2

1

1

1

2

2

3

2

1

2

1

1

1

1

1

Name

IS10

3

3,5

4

4

4

4

3

4

4

3,75

4

1

1

2

4

4

1

4

4

4

1

5

2,5

3

2

1

4

3

4

4

4

4

2,5

3

1

2

1

1

2

4

3

4

4

3

3

3

4

3

3

3

3

3

3

4

4

3

4

4

1

2

2

4

1

Name

IS11

3

3

4

4

4

4

3

3

4

3

5

3

1

5

3

5

1

1

1

3

4

5

2

1

1

3

4

2

2

5

2

2

1,5

1

1

2

1

1

4

1

3

3

4

1

4

1

1

3

3

3

1

2

4

1

2

1

1

1

3

1

1

1

1

Name

IS12

3

3

2

2

1

1

2

2

5

4

5

2

1

3

3

4

4

5

4

4

1

5

3,5

1

3

4

4

3

3

1

3

4

4

3

2

4

5

4

4

4

4

4

3

2

2

2

3

3

3

3

2

2

4

3

3

1

1

4

5

4

1

4

4

Name

IS13

2

2

1

1

1

1

5

1

2

3

1

1

1

4

3

4

4

3

5

1

1

5

3

5

2

1

4

2

1

1

3

1

4

1

4

5

1

5

4

3

4

4

4

1

1

3

1

2

1

3

2

1

2

2

2

1

2

2

1

1

1

1

1

Name

IS14

2

2

1

1

3

1

1

3

1

2

1

3

1

1

2

3

2

2

3

1

2

3

2,5

2

2

3

3

1

1

1

1

4

4

4

4

4

1

5

4

1

4

4

4

1

1

1

1

1

1

1

1

1

2

1

1

1

1

3

4

1

1

1

1

Name

IS15

2

2

1

1

3

1

1

3

1

2

1

3

1

1

2

3

2

2

3

1

2

3

2,5

2

2

3

3

1

1

1

1

4

4

4

4

4

1

5

4

1

4

4

4

1

1

1

1

1

1

1

1

1

2

1

1

1

1

3

4

1

1

1

1

Name

IS16

5

4

3

3

1

1

3

3

4

5

5

5

5

5

5

5

5

5

5

3

1

5

1

1

1

1

4

5

5

3

5

5

4

3

2

4

5

2

5

5

4

2

4

5

5

4

5

5

5

5

5

5

5

4

4

4

4

5

5

5

5

5

5

Name

IS16

5

4

3

3

1

1

3

3

4

5

5

5

5

5

5

5

5

5

5

3

1

5

1

1

1

1

4

5

5

3

5

5

4

3

2

4

5

2

5

5

4

2

4

5

5

4

5

5

5

5

5

5

5

4

4

4

4

5

5

5

5

5

5

Totalen

2,7

2,5

2,3

2,5

2,3

2,3

2,3

2,4

3,0

3,0

2,8

2,5

1,8

2,6

2,6

3,4

3,2

3,0

3,6

2,8

2,0

4,5

2,2

2,0

2,1

2,2

3,1

2,6

2,7

2,7

3,1

3,1

3,3

3,4

2,2

3,4

2,5

2,5

3,4

2,8

3,5

3,2

3,6

2,5

2,8

2,0

3,0

2,6

2,3

2,8

2,5

2,5

2,9

2,4

2,1

1,8

2,2

3,5

3,1

1,7

1,5

2,8

1,6

Gemiddelde

3

2

2,5

2,3

3

1,5

2

3

3

3

2

3

1

3

3

4

3

3

4

3

1

5

2

2

2

1,5

3

3

3

3

4

4

4

4

2

4

2

2

4

2

4

4

4

2,5

3

1

3,5

3

2

3

2

2

2

2,5

2

1

2

4

3

1

1

3

1

Mediaan

2

2

1

1

1

1

1

2

1,5

2

1

1

1

1

1

2

2

2

3

1,5

1

5

2

1

1

1

2

1

1

1

2

2

2,5

3

1

2

1

1

2

1

3

3

4

1,5

2

1

1,5

1

1

1

1

1

2

1

1

1

1

3

1

1

1

1

1

0,25

1

3

3

3

3

3

3,25

3

3

4

4

4,25

3

1,5

4

3,5

5

4

4

4,5

3,75

2

5

2,75

3

2,25

3

4

3,25

4

4,25

4

4

4

4

3

4

4,5

4

5

5

4

4

4

3

3,25

3

4

3,25

3

3,25

4

3,25

4

3,75

3

2,25

3,75

4

4

1,25

1

4,25

0,75

T.M. van Bremen, 2014 IT Governance at Higher Education Institutes

5. Results

Figure 4. Result table - All investigated systems

16



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 1st and 3rd 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 # 1

2

3

4

Total 5

6

7

Median (IQR)

Requirements 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)

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)

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

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)

Requirements regarding other management layers

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)

Other activities Management General requirements

Table 8. Results of requirements for each interviewed system owner


17



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 F1F15, 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 – external10] 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 = 2.25-3.75). 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 = 1-4.75). 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)


18



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 = 2.5-3.75). All underlying requirements were assessed with a median of 3, however with much variation. Control over change management had an IQR of 1.5-3.75, Agreements with user organization on control over change management 2-3.75, alignment with system owners 3-3.75 and written agreements with other units when management was 1.5-3. 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 = 2.75-4), 3 (IQR = 1.5-3) and 3 (IQR = 2.5-3.74). 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).


19



Control over and sufficient budget resulted in a median of 4 with an IQR of 2.5-4.75. 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 = 2-4.75). The access to the network of all system owners was assessed with a median of 2 with an IQR of 1-3.5. 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 = 1-4.25). 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 = 33.75). 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).


20



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 2.5-4. 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 = 2.75-4.75). 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 = 3 - 4.75). Whether business process managers do not perform application or technical management was rated with a median of 3 (IQR = 2-3.75). Appointment of key-users depending on the need for key-users of the IS was rated with a 3 (IQR = 1.25-3.75). 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 = 1-1.75). Regular meetings with business process management with a frequency that corresponds with the dynamicity of the IS 4 (IQR = 1.25-4.75). 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 = 2.25-4). The other layers are managed by ICT Services 2 (IQR = 1.5-2.75). 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


21



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.

6. Discussion Research questions 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


22



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 R4.2.12

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.


23



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. 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.” Limitations 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.


24



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.


25



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.


26



9. References Aghion, P., & Tirole, J. (1997). Formal and Real Authority in Organizations, 105(1), 1–29. Allan, G. (2003). A critique of using grounded theory as a research method. Electronic Journal of Business Research Methods, 2(1), 1–10. Bester, H. (2009). Externalities, communication and the allocation of decision rights. Economic Theory, 41, 269–296. doi:10.1007/s00199-008-0395-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, 3–21. doi:10.1007/BF00988593 Glaser, B. G., & Strauss, A. L. (1967). The discovery of grounded theory. International Journal of Qualitative Methods (Vol. 5, pp. 1–10). doi:10.2307/588533 Green, G. I. (1989). Perceived Importance of Systems Analysts’ Job Skills, Roles, and Non-Salary Incentives. MIS Quarterly, 13, 115–133. doi:10.2307/248918 Guldentops, E. (2004). Governing Information Technology through COBIT. In Strategies for Information Technology Governance (pp. 269–309). Harison, E., & Boonstra, A. (2009). Essential competencies for technochange management: Towards an assessment model. International Journal of Information Management, 29, 283–294. doi:10.1016/j.ijinfomgt.2008.11.003 Horne, J. A., & Ostberg, O. (1976). A self-assessment questionnaire to determine morningness-eveningness in human circadian rhythms. International Journal of Chronobiology, 4(2), 97–110. Retrieved from http://europepmc.org/abstract/MED/1027738 Introna, L. (2007). Strategy-as-Identity: An autopoietic contribution to the IS/IT strategy debate. Retrieved from http://scholar.google.nl/scholar?q=introna+strategy+as+identity&btnG=&hl=nl&as_sdt=0,5#2 Jamieson, S. (2004). Likert scales: How to (ab)use them. Medical Education. doi:10.1111/j.13652929.2004.02012.x Jennings, M. (2000). Gap analysis: concepts, methods, and recent results*. Landscape Ecology, 15, 5–20. Retrieved from http://link.springer.com/article/10.1023/A:1008184408300 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, 30–45. doi:10.1016/S1090-9516(03)00007-5 Meredith, J. R., Mantel, S. J., & Jr. (2011). Project Management: A Managerial Approach. Retrieved from http://books.google.com/books?hl=nl&lr=&id=xGRtQetWjNsC&pgis=1 Moran, J. W., & Brightman, B. K. (2000). Leading organizational change. Journal of Workplace Learning. doi:10.1108/13665620010316226


27



Norman, D. (1993). Things that make us smart. 1993. Addison-Wesley, 43–76. 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, 653–677. Retrieved from http://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=16744514&lang=fr&site=ehost-live Robinson, L., & Stocken, P. (2013). Location of Decision-rights within Multinational Firms. Journal of Accounting and Economics, 1–57. doi:10.1111/1475-679X.12021.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), 88–94. doi:10.1046/j.1365-3016.2001.00317.x Todnem By, R. (2005). Organisational change management: A critical review. Journal of Change Management. doi:10.1080/14697010500359250 Tulder, R. J. M. (2012). Skill Sheets. Retrieved from http://books.google.com/books?hl=nl&lr=&id=uibwTe6zYb8C&pgis=1 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:10.1109/HICSS.2006.68 Weill, P., & Ross, J. (2004). IT governance: How top performers manage IT decision rights for superior results (Vol. 1). Retrieved from http://books.google.com/books?hl=en&lr=&id=xI5KdR21QTAC&oi=fnd&pg=PR7&dq=IT+Governanc 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 http://books.google.com/books?hl=nl&lr=&id=AjV1AwAAQBAJ&pgis=1


28



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


29

IT Governance at Higher Education Institutes in Amsterdam Appendix A – Requirements List (Short) R3 R3.1 R3.1.1 R3.1.2 R3.1.3

Responsibilities of the system owner Responsibility for basic information List of information provision services and its users Architectural model Information on involved parties

R3.2 R3.2.1 R3.2.2 R3.2.3 R3.2.4 R3.2.5

Responsibility for management of IS Responsibility for the complete chain of management Role allocation Escalation scenarios Crisis plans Update and upgrade management

R3.3 R3.3.1 R3.3.2 R3.3.3 R3.3.4 R3.3.5

Responsibility for alignment and agreements with other parties 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 Written agreements with other units when the management is distributed

R3.4 R3.4.1 R3.4.2 R3.4.3

Responsibility for the communication with end users Call-routing schematics Communication protocol for the communication with end users Maintenance plans

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7 R3.5.8 R3.5.9 R3.5.10

Conditions for quality fulfilment of system ownership Basic knowledge of information management and systems Basic knowledge of architecture Relation with the higher level i-governance and information provision project portfolio management Budget control Skill employees Access to the network of system owners Influence on daily work of management layers Available communication channels Advice from central information managers Education of end users

R3.6 R3.6.1 R3.6.2 R3.6.3

Other activities Involvement in innovation of information system Alignment central information management Involvement with contracts and SLAs

R4 R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4

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 Application coordination Different layers are offered to the system owners as services by the different relevant departments System owner responsible for all layers

R4.2 R4.2.1 R4.2.2 R4.2.3 R4.2.4 R4.2.5 R4.2.6 R4.2.7 R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12

Business process management requirements Business process management is done internally Business process management designed according to BiSL System owner is part of the controlling part of business information management layer Business process managers are working on an operational level Business process managers are placed as close to the system owner as possible Replacement of business information manager(s) Business information managers have an advising role Business process managers do not perform application or technical management Appointment of key-users depending on the need for key-users of the IS Alignment of operational processes with key-users Key-users part of business process management Regular meetings with business process management with a frequency that corresponds with the dynamicity of the IS

R4.3 R4.3.1 R4.3.2 R4.3.3 R4.3.4 R4.3.5

Requirements regarding other management layers Business process management controls the other layers The other layers are managed by ICT Services) The system owner is responsible for the service level contracts and SLAs ICT Services handles all contracts and involves all relevant system owners 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

UITGANGSPUNTEN BEHEER INFORMATIESYSTEMEN SAMENWERKENDE DIENSTEN Onderdeel van Verbetertraject beheer informatiesystemen samenwerkende diensten (winter 2013/2014) Auteur

:

Sanne Nolst Trenité

Versie

:

1.0

Datum

:

28-03-2014

Status

:

Definitieve versie

Versiebeheer

Versie 0.1 0.2 0.3

Datum Verstuurd naar 8-12-2013 Systeemeigenaren AC/FS; andere geïnteresseerden 12-1-2014 n.v.t. 28-02-2014 MT FS

Doel Feedback/input; ter informatie Tussenversie Discussie

0.4 1.0

7-03-2014 Directeuren AC, FS, ICTS 28-03-2014

Uitgangspunten beheer IS samenwerkende diensten

Ter vaststelling Definitief

Page. 2 of 15

Index Index .............................................................................................................................................................................................................3 1 Inleiding .............................................................................................................................................................................................4 2 Beleggen van het systeemeigenaarschap .........................................................................................................................5 3 Verantwoordelijkheden van de systeemeigenaar........................................................................................................7 3.1 VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS ..........................................................................7 3.2 VERANTWOORDELIJKHEID HET BEHEER VAN HET IS.......................................................................................................7 3.3 VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN ................................................8 3.4 VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS ................................................................8 3.5 RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP.............................................8 3.6 OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPEELT .............................................................9 4 Uitgangspunten bij het beheer van de informatiesystemen ................................................................................ 10 4.1 ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER ............................................................................................................... 10 4.2 UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER ......................................................................................................... 10 4.3 UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN .................................................................................................. 11 Bijlage A. BiSL model ........................................................................................................................................................................ 13 Bijlage B. kwaliteitskenmerken van software (ISO 25010-norm) ............................................................................ 15


Page. 3 of 15

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 informatiesysteem1. 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.


Page. 4 of 15

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-governance3 ingericht. De systeemeigenaar zal hierbij wel betrokken worden. Zie voor actueel overzicht systemen, verantwoordelijke diensten en systeemeigenaren: “03.1 rationalisatie systeemeigenaarschap (uit betrokkenen 1.33).pdf” 2 2

3

Zie CvB besluit 15-10-2012


Page. 5 of 15

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.


Page. 6 of 15

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 dragen4. 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 worden5



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

Zie ook: 03.4 Faciliteren van de systeemeigenaren 131004 v1.0.pdf voor een verslag van gesprekken met systeemeigenaren 4

5

Zie als voorbeeld “10.1 Eerste aanzet IVdienstenportfolio Gevalideerd 140203 v0.4.pdf”


Page. 7 of 15



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




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 BiSL6)



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 architectuurprincipes7



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)


Page. 8 of 15



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




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


Page. 9 of 15

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.8 4.1

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”


Page. 10 of 15



Uitvoerend en sturend functioneel beheer wordt in hoofdlijnen ingericht volgens BiSL9 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


Page. 11 of 15



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.


Page. 12 of 15

Bijlage A. BiSL model


Page. 13 of 15


Page. 14 of 15

Bijlage B. kwaliteitskenmerken van software (ISO 25010-norm)


Page. 15 of 15

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

:

23-04-2014

Status

:

First draft

Version management

Version 0.1

Date 14-04-2014

0.2

23-04-2014

Master Thesis Beheer IS UvA-HvA

Sent to Mw. S.W. Nolst Trenité, Information Manager FS UvA

Goal Feedback/input

Interview Protocol

Page. 1 of 18

Index Index .............................................................................................................................................................................................................2 1

Te onderzoeken systemen .....................................................................................................................................................3 1.1

AC ...............................................................................................................................................................................................3

1.2

ICTS ...........................................................................................................................................................................................3

1.3

FS ................................................................................................................................................................................................3

2

Introductie interview ...............................................................................................................................................................5

3

R3 Verantwoordelijkheid voor de basisinformatie van het IS ............................................................................6 3.1

VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS .................................................................6

3.2

R3.2 VERANTWOORDELIJKHEID VOOR HET BEHEER VAN HET IS .............................................................................7

3.3

VERANTWOORDELIJK VOOR AFSTEMMING EN AFSPRAKEN MET ANDERE PARTIJEN .............................................8

3.4

R3.4 VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS ............................................... 10

3.5

R3.5 RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP ............................ 11

3.6

R3.6 OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPELT ............................................... 12

4

R4 Uitgangspunten bij het beheer van de informatiesystemen ...................................................................... 13 4.1

R 4.1 ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER ................................................................................................. 13

4.2

R4.2 UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER ............................................................................................ 14

4.3

R4.3 UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN .................................................................................... 17

AFSLUITING INTERVIEW .................................................................................................................................................................... 18


Interview Protocol

Page. 2 of 18

1 Te onderzoeken systemen 1.1 AC     

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

1.2 ICTS      

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

1.3 FS  

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)


Interview Protocol

Page. 3 of 18

1.4 Systeemeigenaren fase 1      

Aaron Meyer Gerben Smit Gimène Spaans Jan Moorman Lex Welman Paul Franssen


Interview Protocol

Page. 4 of 18

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





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



Inzicht huidige situatie over verschillende

Wissen na afsluiten onderzoek (juli 2014)

Samenvatting interview voorleggen aan geïnterviewde voor eventuele aanpassingen


Interview Protocol

Page. 5 of 18

3 R3 Verantwoordelijkheid voor de basisinformatie van het IS Onderstaande vragen alleen voor SE.

3.1 Verantwoordelijkheid voor de basisinformatie van het IS 3.1.1

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? 

3.1.2

[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 

3.1.3

[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


Interview Protocol

Page. 6 of 18

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) 3.2.1

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?

3.2.2

R3.2.2 Belegging rollen



Zijn de verschillende rollen in de beheerorganisatie helder belegd?



Staat dit ergens op papier? 



Zijn er beschrijvingen van incidentmanagement? 



[Document]

Zijn er beschrijvingen van configuratiebeheer? 

3.2.3

[Document]

Zijn er beschrijvingen van probleemmanagement? 



[Document]

Zijn er beschrijvingen van wijzigingsbeheer? 



[Document] [Mondeling]

[Document]

R3.2.3 Escalatieschema’s



Zijn er escalatieschema’s binnen de beheerketen?



Staan ze op papier? 




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.


Interview Protocol

Page. 7 of 18

3.2.4

R3.2.4 Crisisplan



Is er een crisisplan?



Waar is die te vinden?






Is het crisisplan bekend in alle lagen van de beheerorganisatie? 

3.2.5

[Document] [Mondeling] 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}? 


3.3 Verantwoordelijk voor afstemming en afspraken met andere partijen 3.3.1

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?

3.3.2

R3.3.2 De regie op het wijzigingenbeheer (functionele wijzigingen, volgens BiSL1)



Wordt er volgens BiSL gewerkt bij functionele wijzigingen in {IS}?



Bent u daar zelf direct bij betrokken?



Zo ja, hoe?



Staat dit op papier? 


1

Zie Bijlage A BiSL model


Interview Protocol

Page. 8 of 18

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? 

 3.3.4

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? 

 3.3.5

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


Interview Protocol

Page. 9 of 18

3.4 R3.4 Verantwoordelijk voor de communicatie met (eind)gebruikers 3.4.1

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_20130712.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? 

3.4.2

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?

3.4.3



[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?




Document



Zijn de onderhoudsplannen gepubliceerd?



Zo ja, waar? En voor wie is dit toegankelijk?


Interview Protocol

Page. 10 of 18

3.5 R3.5 Randvoorwaarden voor een goede invulling van systeemeigenaarschap 3.5.1 

3.5.2  3.5.3

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.3.5.2 Kennis van architectuurprincipes Heeft u de indruk voldoende kennis te hebben van architectuurprincipes? R.3.5.3 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?

3.5.4

R.3.5.4 Voldoende beschikbaar budget



Beschikt u over voldoende beschikbaar budget?



Voor welke aspecten van het systeemeigenaarsschap heeft u budget beschikbaar?



Wordt dit apart begroot?

3.5.5

R.3.5.5 Voldoende deskundig personeel beschikbaar



Is er u voldoende personeel beschikbaar?



Is het personeel voldoende deskundig?

3.5.6

R.3.5.6 Toegang tot het netwerk van systeemeigenaren



Heeft u voldoende toegang tot het netwerk van systeemeigenaren?



Maakt u gebruik van dit netwerk?

3.5.7

 3.5.8

R.3.5.7 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.3.5.8 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?


Interview Protocol

Page. 11 of 18

3.5.9 

R.3.5.9 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?

3.5.10 R.3.5.10 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 3.6.1

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?

3.6.2

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?

3.6.3 

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?


Interview Protocol

Page. 12 of 18

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.2

4.1 R 4.1 Algemene uitgangspunten m.b.t. beheer 4.1.1

R4.1.1 Het beheer van ieder IS is opgedeeld in de volgende lagen: functioneel beheer, applicatiecoördinatie, applicatiebeheer, technisch beheer, hosting, housing. 

     4.1.2

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? 

4.1.3

[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”


Interview Protocol

Page. 13 of 18

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 4.2.1

 4.2.2

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 BiSL3 waarbij in elk geval de hoofdprocessen belegd zijn.



Is uitvoerend en sturend functioneel beheer ingericht volgens BiSL?



Welke processen zijn volgens BiSL ingericht? 

4.2.3

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?*

4.2.4 

4.2.5

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



Interview Protocol

Page. 14 of 18

 4.2.6

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?

4.2.7



4.2.8

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?

4.2.9

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?

4.2.10 R4.2.10 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?


Interview Protocol

Page. 15 of 18

4.2.11 R4.2.11 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?

4.2.12 R4.2.12 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?


Interview Protocol

Page. 16 of 18

4.3 R4.3 Uitgangspunten m.b.t. de andere beheerlagen 4.3.1

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?

4.3.2

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?

4.3.3

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?

4.3.4

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?

4.3.5

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?


Interview Protocol

Page. 17 of 18

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


Interview Protocol

Page. 18 of 18

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.

Invulling uitgangspunten

Algemene Conclusies 















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

Beoordeling op Likert schaal 1 Zeer slecht

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

3

2

Zeer goed 5

1,7 2,4

2,6

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

4

2,5 3,3

2,7

2,2

3,0

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

2,5

Onderzochte Informatiesystemen

Vervolg van het onderzoek 2. Hoe kunnen de uitgangspunten helpen bij de uitvoering van wijzigingsbeheer?

1. Hoe kunnen de uitgangspunten het beste geïmplementeerd worden, met betrekking tot risico’s en weerstand bij verandering?

Uitgevoerd door:

Supervisors:

Tim van Bremen ([email protected])

UvA/HvA: S.W. Nolst Trenité

Bart van Eck ([email protected])

UvA: dhr. drs. A.W. Abcouwer

Zomer 2014



General requirements and hosting and2 housing 2 technical management 3 application management, 3 3 application coordination, Division of management of information system in predefined layers of functional management, 2 2 4 4 4 Application coordination 2 2 3 3 3 Different layers are offered to the system owners as services by the different relevant departments 3 3 2 2 2 System owner responsible for all layers 2 2 3 3 3 Total

Business process management requirements 5 5 Business process management is done internally 5 5 Business process management designed according to BiSL 4 System owner is part of the controlling part of business information management layer 4 4 4 Business process managers are working on an operational level 4 4 Business process managers are placed as close to the system owner as possible 4 5 Replacement of business information manager(s) 2 2 Business information managers have an advising role 4 4 Business process managers do not perform application or technical management 3 3 Appointment of key-users depending on the need for key-users of the IS 3 3 Alignment of operational processes with key-users 3 3 Key-users part of business process management 4 the dynamicity of the4 IS Regular meetings with business process management with a frequency that corresponds with 4 4 Total

Requirements regarding other management layers 3 5 5 5 Business process management controls the other layers 2 3 3 3 The other layers are managed by ICT Services 3 2 2 2 The system owner is responsible for the service level contracts and SLAs 2 3 3 3 ICT Services handles all contracts and involves all relevant system owners 3 to fulfil demands of3 the system owner 3 and hosting and housing 3 technical management ICT Services takes care in providing sufficient available and qualified application management, 3 3 3 3 Total

R4

R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4

R4.2 R4.2.1 R4.2.2 R4.2.3 R4.2.4 R4.2.5 R4.2.6 R4.2.7 R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12

R4.3 R4.3.1 R4.3.2 R4.3.3 R4.3.4 R4.3.5

3 3 3

3 4 3 3 3

3 3 3

3 1 3 5 3 3 5 1 1 1 1 2 2

3 4 3 3 3

Other activities Involvement in innovation of information system Alignment central information management Involvement with contracts and SLAs Total Total R3

R3.6 R3.6.1 R3.6.2 R3.6.3

R3 R4 Alle uitgangspunten

2 2 2 3 2

4 4 4 2 2 4 5 4 3 4 4

Conditions for quality fulfilment of system ownership 4 Basic knowledge of information management and systems 4 Basic knowledge of architecture 4 Relation with the higher level i-governance and information provision project portfolio management 2 Budget control 2 Skill employees 4 Access to the network of system owners 5 Influence on daily work of management layers 4 Available communication channels 3 Advice from central information managers 4 Education of end users 4 Total

3 3 3

5 5 4 4 4 4 2 4 3 3 3 4 4

3 4 3 3 3

4 4 4 2 2 4 5 4 3 4 4

2,5 2 3

3 1 3 5 3 3 5 1 1 1 1 2 2

4 4 5 4 4

4 3 4 5 5 1 2 4 2 4 4

4 1 4 3,5

4 3 3 3,25 3 3 3 3 3 1 2 2 2,5 2 3 2,3 2,5 2,7 3 4 5 3 4 5 1 2 2 1 2 2 1 2 2 2 3 3 4 3 3 4 3,5 3 1 2 1 1 1 1 1 1 1 2,5 2 3 3 2 3

5 2 3,75 4,5 4 4 5 3,5 4 1,5 3 4,25 4

4 3 2,25 3 2,75

4 4 4,25 4 3,25

4 4 4 5 5 4 4,5 4 3 4 4

4 3 3,25 3

4 3,25 4 3,25 3 3,25

4 4 3,75 2,25 3 3,75

1 4,25 1 1,25

1,5 2 1 1 1 1

5 1 1,5 3 2 2 2 1 1 1 1 1 2

2 1 1 1 2

2 2 1 1 1

4 3 3 1 2 1 1 2 1 3 2,5

1,5 1 2 1,5

2 1 1 1 1 1

1 3 1 1 1 1

1 1 1 1

3 3 2 1,5 3 2,3

5 1 3 4 3 3 4 3 3 1 3 2 3

3 1,5 2 2 2

4 4 3 3 3

4 4 4 2 4 2 2 4 2 4 4

3,5 1 3 2,5

2 2 2 3 2 3

3 4 2 1 2 2,5

1 3 1 1

0,25

3,0 2,4 2,3 2,3 2,3 2,5

4,5 2,0 2,8 3,6 3,0 3,2 3,4 2,6 2,6 1,8 2,5 2,8 3,0

3,1 2,2 2,1 2,0 2,2

3,1 3,1 2,7 2,7 2,6

3,6 3,2 3,5 2,8 3,4 2,5 2,5 3,4 2,2 3,4 3,3

3,0 2,0 2,8 2,5

2,9 2,5 2,5 2,8 2,3 2,6

3,1 3,5 2,2 1,8 2,1 2,4

1,6 2,8 1,5 1,7

Mediaan

4 3 3 1 1 3

5 1 3 5 5 5 5 5 5 5 5 5 5

4 1 1 1 1

5 5 3 5 5

4 2 4 5 5 2 5 4 2 3 4

5 4 5 5

5 5 5 5 5 5

5 5 4 4 4 4

5 5 5 5

Totalen Gemiddelde

4 3 3 1 1 3

5 1 3 5 5 5 5 5 5 5 5 5 5

4 1 1 1 1

5 5 3 5 5

4 2 4 5 5 2 5 4 2 3 4

5 4 5 5

5 5 5 5 5 5

5 5 4 4 4 4

5 5 5 5

IS16 Name

1 3 1 1 3 1

3 2 1 3 2 2 3 2 1 1 3 1 2

3 3 2 2 2,5

4 1 1 1 1

4 4 4 1 4 5 1 4 4 4 4

1 1 1 1

2 1 1 1 1 1

4 3 1 1 1 1

1 1 1 1

IS16 Name

1 3 1 1 3 1

3 2 1 3 2 2 3 2 1 1 3 1 2

3 3 2 2 2,5

4 1 1 1 1

4 4 4 1 4 5 1 4 4 4 4

1 1 1 1

2 1 1 1 1 1

4 3 1 1 1 1

1 1 1 1

IS15 Name

2 1 5 1 1 1

5 1 1 5 3 4 4 3 4 1 1 1 3

4 1 2 5 3

1 3 1 1 2

4 4 4 3 4 5 1 5 4 1 4

1 3 1 1

2 1 2 3 1 2

1 2 2 1 2 2

1 1 1 1

IS14 Name

5 2 2 1 1 2

5 1 4 4 5 4 4 3 3 1 2 5 4

4 4 3 1 3,5

4 3 1 3 3

3 4 4 4 4 4 5 4 2 3 4

3 2 2 2

4 2 2 3 3 3

5 4 1 1 3 3

4 4 1 4

IS13 Name

4 3 3 4 4 4

5 4 3 1 1 1 5 3 5 1 3 5 3

4 3 1 1 2

2 2 5 2 2

4 3 3 1 4 1 1 2 1 1 1,5

1 1 4 1

4 2 1 3 3 3

3 1 1 1 2 1

1 1 1 1

IS12 Name

4 4 3 4 4 4

5 1 4 4 4 1 4 4 2 1 1 4 3,75

4 1 2 3 2,5

4 4 4 4 3

4 4 3 4 2 1 1 2 1 3 2,5

4 3 3 3

3 3 3 3 3 3

1 4 4 3 4 4

1 4 2 2

IS11 Name

1 2 1 1 1 1

5 1 4 4 2 1 1 2 4 1 5 2 2

3 1 4 1 2

1 3 1 1 1

4 4 3 1 2 1 1 2 1 3 2

3 1 3 3

2 1 1 1 2 1

1 2 1 2 3 2

1 1 1 1

IS10 Name

2 1 1 5 1 1

5 1 2 2 1 3 1 1 1 1 1 1 1

2 1 1 1 1

1 1 1 1 1

1 1 1 1 1 1 1 1 1 4 1

2 1 3 1,5

1 1 1 1 3 1

1 3 1 2 1 1

1 3 1 1

IS9 Name

1 1 1 5 1 1

5 1 1 1 1 3 1 1 1 1 1 1 1

2 1 1 1 1

1 1 1 1 1

1 1 1 1 1 1 1 1 1 4 1

3 1 3 2,5

1 1 1 1 3 1

1 3 1 1 1 1

1 3 1 1

IS8 Name

3 2 3 2 3 3

4 4 5 4 4

4 3 4 5 5 1 2 4 2 4 4

4 1 2 2

IS7 Name

3 2 3 2 3 3

5 1 3 4 3 4 5 1 1 1 1 2 2,5

4 4 5 4 3

4 3 4 5 5 1 2 4 2 4 4

4 1 2 2

4 4 4 4 1 4

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7 R3.5.8 R3.5.9 R3.5.10

4 3 3 3

4 2 2 3 1 2

4 3 3 3

4 3 3 3

4 4 4 4 1 4

Responsibility for the communication with end users Call-routing schematics Communication protocol for the communication with end users Maintenance plans Total

2 3 4 3 2 3

R3.4 R3.4.1 R3.4.2 R3.4.3

4 4 4 1 1 3,5

1 1 1 1

2 3 3 3 2 3

4 4 4 1 1 4

1 1 1 1

IS6 GBS-KMH (HvA)

Responsibility for alignment and agreements with other parties 2 Alignment with user organisation 3 Control over change management 3 Agreements with user organization on control over change management Alignment with system owners of other information systems which have interfaces with the3 IS 2 Written agreements with other units when the management is distributed 3 Total

4 4 3 1 1 2,5

1 1 1 1

IS5 Name

R3.3 R3.3.1 R3.3.2 R3.3.3 R3.3.4 R3.3.5

3 4 2 3 2 2,5

1 5 1 1

IS4 GBS-LWB (HvA)

3 4 2 2 2 2

1 5 1 1

IS3 Name

3 4 2 3 2 2,5

1 5 1 1

IS2 Name

Responsibility for management of IS Responsibility for the complete chain of management Role allocation Escalation scenarios Crisis plans Update and upgrade management Total

Responsibility for basic information List of information provision services and its users Architectural model Information on involved parties Total

IS1 Name

R3.2 R3.2.1 R3.2.2 R3.2.3 R3.2.4 R3.2.5

R3.1 R3.1.1 R3.1.2 R3.1.3

Requirements Description ID Verantwoordelijkheid basisinformatie R3 0,75

IT Governance at Higher Education Institutes in Amsterdam Appendix E – Results tables

IT Governance at Higher Education Institutes in Amsterdam Appendix E – Results tables ID Name Fuction Owner

IS1 Name Kaartmanagementsysteem Name

Requirements ID R3

Description Verantwoordelijkheid basisinformatie

R3.1 R3.1.1 R3.1.2

Responsibility for basic information List of information provision services and its users Architectural model

R3.1.3

Information on involved parties Total

R3.2

Aantal

Beschikbaar

Gevalideerd

Beoordeling

Nee Ja

Nee Ja

1 5

Nee

Nee

1 1

Systeemeigenaar

Schaal/gradatie/kwaliteitsinschatting Likert 1-5

Toelichting


3

Toegezegd. Niet gevalideerd. Beschikbaar. Gevalideerd. Leveranciers per systeem. Niet voor elk subsysteem gevalideerd.

Responsibility for management of IS

R3.2.1

Responsibility for the complete chain of management

3

3

R3.2.2

Role allocation

R3.2.3

Escalation scenarios

Nee

4

4

2

2

R3.2.4

Crisis plans

Nee

2

R3.2.5

Update and upgrade management Total

Nee

2

2 3

3

5

3

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 interfaces with the ISNee

3

3

R3.3.5

Written agreements with other units when the management is distributed Total 5

2

2 3

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 Total

Nee

3

3 3

R3.5 R3.5.1 R3.5.2 R3.5.3

Conditions for quality fulfilment of system ownership Basic knowledge of information management and systems Basic knowledge of architecture Relation with the higher level i-governance and information provision project portfolio management

4 4 4

4 4 4

R3.5.4

Budget control

2

2

R3.5.5 R3.5.6

Skill employees Access to the network of system owners

2 4

2 4

R3.5.7

Influence on daily work of management layers

5

R3.5.8

Available communication channels

4

4

R3.5.9

Advice from central information managers

3

3

R3.5.10

Education of end users Total

4

4 4

3

3

4 3

4 3 3 3

R3.6

Other activities

R3.6.1

Involvement in innovation of information system

R3.6.2 R3.6.3

Alignment central information management Involvement with contracts and SLAs Total Total R3

R4


R4.1

General requirements

3

4

10

3 29

5

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 Total

2

2 3

4

R4.2 R4.2.1 R4.2.2 R4.2.3

Business process management requirements Business process management is done internally Business process management designed according to BiSL System owner is part of the controlling part of business information management layer

5 5 4

5 5 4

R4.2.4

Business process managers are working on an operational level

4

4

R4.2.5

Business process managers are placed as close to the system owner as possible

4

4

R4.2.6

Replacement of business information manager(s)

5

5

R4.2.7

Business information managers have an advising role

2

R4.2.8

Business process managers do not perform application or technical management

5

2

4

R4.2.9

Appointment of key-users depending on the need for key-users of the IS

2

4

3

R4.2.10 R4.2.11

Alignment of operational processes with key-users Key-users part of business process management

3 3

R4.2.12

Regular meetings with business process management with a frequency that corresponds with the dynamicity of the IS Total 12

4

R4.3

Requirements regarding other management layers

2

3 3 4

R4.3.1

Business process management controls the other layers

5

R4.3.2

The other layers are managed by ICT Services

3

3

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 Total 6 22 R3 51 R4


4

4 4

5

3 3 3 3

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, wijzigingen 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.

Éé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.

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)

Ja en nee. Budget voor onderhoud en beheer. Apart begroot. Nee. Aantal panden en gebruikers stijgt. Capaciteit niet. Ja, CIM. Wordt gebruik van gemaakt. Zeker. Heel direct. FB: Heel veel gaat via mij, maar als het belangrijker is -> SE. Heeft noodzakelijke communicatiekanalen. Soms afhankelijkheden, bijv. voor comm. met studenten. Nog niet aan de orde geweest. SE zou er wel gebruik van maken. Niet veel scholing vereist bij dit systeem, betreft het gebruik van een pas.

Direct betrokken en voldoende op de hoogte van alle nieuwe ontwikkelingen. Zeer goede afstemming en indirect betrokken bij de relatie tussen het IS en de HvA/UvA werkplekken. Nee, is nog te recent.

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.

Ja. Meerdere mensen die FB uitvoeren. Ja, destijds geïmplementeerd door Sanne. Ja. Mag wel minder uitvoerend (-> huismeestertaken). Zit een coördinator tussen. Wel direct contact en leidinggevende. 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. Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt te weinig. Belegd bij ICTS. FB: Ook applicatiebeheer. Soms technisch beheer. Niet benoemd. Input users puur via eventuele individuele calls. Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. Geen decentrale belegging. Ja, maandelijks. Ook met applicatiebeheerder.

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.

IT Governance at Higher Education Institutes in Amsterdam Appendix E – Results tables ID Name Fuction Owner Requirements ID

IS2 Name Toegangsbeheersysteem Name


R3.1 R3.1.1 R3.1.2

Basisinformatie Lijst IV-diensten en gebruikers Architectuurplaat

R3.1.3

Informatie over betrokkenen Totaal

R3.2

Aantal

Beschikbaar

Gevalideerd

Beoordeling

Nee Ja

Nee Ja

1 5

Nee

Nee

1 1

Systeemeigenaar

Schaal/gradatie/kwaliteitsinschatting Likert 1-5 Functioneel beheerder

3

Volledige beheerketen

R3.2.2

Belegging rollen

R3.2.3

Escalatieschema’s

Nee

R3.2.4

Crisisplan

Nee

2

R3.2.5

Updates en upgrades Totaal

Nee

2

2 2

3

3

4

4

2

2

2

5

2

R3.3


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


Nee

3

3

R3.3.5

Afspraken met andere eenheden Totaal

2

2 3

5




R3.4.1

Call-routering

R3.4.2


R3.4.3


Ja

4

4

Nee

3

3

Nee

3

3 3

3

R3.5 R3.5.1 R3.5.2 R3.5.3

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement

4 4 4

4 4 4

R3.5.4


2

2

R3.5.5 R3.5.6

Voldoende deskundig personeel Toegang netwerk systeemeigenaren

2 4

2 4

R3.5.7

Invloed werkzaamheden

5

R3.5.8

Noodzakelijke communicatiekanalen

4

4

R3.5.9


3

3

R3.5.10

Geschoolde gebruikers Totaal

4

4 4

3

3

4 3

4 3 3 3

R3.6


R3.6.1

Betrokkenheid innovatie

R3.6.2 R3.6.3

Afstemming centraal IM Betrokkenheid contracten en SLA's Totaal Totaal R3

R4


R4.1


4

10

3 29

5

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 Totaal

2

2 3

4

R4.2 R4.2.1 R4.2.2 R4.2.3

Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB

5 5 4

5 5 4

R4.2.4

FB'er onderdeel uitvoerende laag FB

4

4

R4.2.5

Afstand functioneel beheer en systeemeigenaar

4

4

R4.2.6

Vervanging functioneel beheerder

4

4

R4.2.7

Rolbelegging functioneel beheerder

2

R4.2.8

Geen applicatiebeheer of technisch beheer

5

2

4

R4.2.9

Key-users benoemd

2

4

3

R4.2.10 R4.2.11

Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer

3 3

R4.2.12

Overleg SE met FB'er Totaal

4

R4.3



R3.2.1

R3.4

Toelichting

12

2

3 3 4

4 4

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)




Ja. Meerdere mensen die FB uitvoeren. Ja, destijds geïmplementeerd door Sanne. Ja. Mag wel minder uitvoerend (-> huismeestertaken). Zit een coördinator tussen. Wel direct contact en leidinggevende. 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. Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt te weinig. Belegd bij ICTS. FB: Ook applicatiebeheer. Soms technisch beheer. Niet benoemd. Input users puur via eventuele individuele calls. Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. Geen decentrale belegging. Ja, maandelijks. Ook met applicatiebeheerder.


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 Totaal Totaal R4 Alle uitgangspunten

3

3 3 3 3

T.M. van Bremen - University of Amsterdam 6 22 51



IS3 Name Uploaden pasfoto's medewerkers en studenten Name


R3.1 R3.1.1 R3.1.2


R3.1.3


R3.2


Aantal

Beschikbaar

Gevalideerd

Beoordeling

Nee Ja

Nee Ja

1 5

Nee

Nee

1 1

Systeemeigenaar


3

R3.2.1


R3.2.2

Belegging rollen

R3.2.3

Escalatieschema’s

Nee

R3.2.4

Crisisplan

Nee

2

R3.2.5


Nee

2

2 3

3

3

4

4

2

2

3

5

3

R3.3


R3.3.1


2

2

R3.3.2


Nee

3

3

R3.3.3


Nee

4

4

R3.3.4


Nee

3

3

R3.3.5


2

2 3

R3.4

Toelichting

5





R3.4.1

Call-routering

Ja

4

4

R3.4.2


Nee

3

3

R3.4.3


R3.5 R3.5.1 R3.5.2 R3.5.3


Nee

3

3 3

4 4 4

4 4 4

R3.5.4 R3.5.5 R3.5.6


2

2

Voldoende deskundig personeel Toegang netwerk systeemeigenaren

2 4

2 4

R3.5.7


5

R3.5.8


4

4

R3.5.9


3

3

R3.5.10


4

4 4

3

3

4 3

4 3 3 3

R3.6


R3.6.1


R3.6.2 R3.6.3


R4


R4.1


3

4

10

3 29

5

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 Totaal

2

2 3

4

R4.2 R4.2.1 R4.2.2 R4.2.3

Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB

5 5 4

5 5 4

R4.2.4


4

4

R4.2.5


4

4

R4.2.6


4

4

R4.2.7


2

R4.2.8


5

2

4

R4.2.9

Key-users benoemd

2

4

3

R4.2.10 R4.2.11

Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer

3 3

R4.2.12


4

R4.3


12

2

3 3 4

4 4

R4.3.1


5

5

R4.3.2


3

3

R4.3.3


2

2

R4.3.4


3

3

R4.3.5


3

3 3 3 3

6 22 51


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)




Ja. Meerdere mensen die FB uitvoeren. Ja, destijds geïmplementeerd door Sanne. Ja. Mag wel minder uitvoerend (-> huismeestertaken). Zit een coördinator tussen. Wel direct contact en leidinggevende. Intern belegd. Kunnen elkaars rollen overnemen. Rol te uitvoerend. Zouden ook moeten adviseren over processen, maar dit gebeurt te weinig. Belegd bij ICTS. FB: Ook applicatiebeheer. Soms technisch beheer. Niet benoemd. Input users puur via eventuele individuele calls. Key-users niet benoemd. Wijzigingen met impact voor eindgebruikers worden wel gecommuniceerd met die gebruikers. Geen decentrale belegging. Ja, maandelijks. Ook met applicatiebeheerder.



IS4 GBS-LWB (HvA) Gebouwbeheersysteem Leeuwenburg Gerben Smit


Aantal

Beschikbaar

Gevalideerd

Nee Nee Nee

Nee Nee Nee

Beoordeling


R3.1

Basisinformatie

R3.1.1 R3.1.2 R3.1.3

Lijst IV-diensten en gebruikers Architectuurplaat Informatie over betrokkenen Totaal

R3.2


R3.2.1 R3.2.2

Volledige beheerketen Belegging rollen

R3.2.3 R3.2.4

Escalatieschema’s Crisisplan

Nee Nee

2 1

3

3 1

R3.2.5


Nee

1

1

1 3

R3.3 R3.3.1

Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie

4

4

R3.3.2 R3.3.3 R3.3.4

Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en

4 4 4

4 4 4

R3.3.5


1

1 4

R3.4


R3.4.1 R3.4.2 R3.4.3

Call-routering Communicatieprotocol Onderhoudsplannen Totaal

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5

Systeemeigenaar


1 1 1

1

3

4 4

4 4

5

5

Ja Ja

4 1 4

3 4

3

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar Budget Voldoende deskundig personeel

1 1 1 1

4 3 4 5 5

4 1 4 4

4 3 4 5 5

R3.5.6

Toegang netwerk systeemeigenaren

1

R3.5.7 R3.5.8

Invloed werkzaamheden Noodzakelijke communicatiekanalen

2 4

R3.5.9 R3.5.10

Advies centrale informatiemanagers Geschoolde gebruikers Totaal

2 4

2 4 4

R3.6 R3.6.1 R3.6.2 R3.6.3

Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid innovatie Afstemming centraal IM Betrokkenheid contracten en SLA's Totaal Totaal R3

4 4 5

4 4 5 4 4

R4


R4.1 R4.1.1 R4.1.2

Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS Invulling applicatiecoördinatie

R4.1.3 R4.1.4

Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal

1 2

10

3 29

2 2

1

2 3

Uitgangspunten m.b.t. functioneel beheer FB intern belegd

5

R4.2.2

FB ingericht volgens BiSL

1

R4.2.3 R4.2.4

Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB

3 4

2 2 2 3 2

4

R4.2 R4.2.1

2 4

1

3 1

3 5

3 5

R4.2.5


3

2

3

R4.2.6


4

2

3

R4.2.7


5

5

5

R4.2.8 R4.2.9 R4.2.10 R4.2.11

Geen applicatiebeheer of technisch beheer Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer

1 1 1 1

1 1 1

1 1 1 1

R4.2.12


2

1

2 2

2

3

12

R4.3


R4.3.1


3

R4.3.2


2

2

R4.3.3


3

3

R4.3.4


2

R4.3.5


3 6 22 51


1

2

3 3 2 3

Toelichting

Staat in PDC. (*is dat het juiste overzicht?*) Onbekend bij SE. Overzicht is in de maak.

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

Juiste temperatuur van zalen etc. Wel bij betrokken. Nog niet veel aan de orde geweest. Wijzigingen worden vastgelegd. Ja. Bijvoorbeeld met Salto. Technisch beheer zou ICTS moeten (gaan) doen.

Is er. Zou bekend moeten zijn bij alle gebruikers. FB: Is er wel maar niet bekend bij alle gebruikers Verward met call-routering. Ja, zijn beschreven.

Controle over budget (meerjarig). SE weet niet of er toegang is, maakt er geen gebruik van. Teamleider zit ertussen. FB: Niet direct, teamleider zit er tussen Te vakspecialistisch. Ontwikkeling komt uit de business zelf.

Niet echt opgedeeld. FB: regelen via main-contractor Zit nog in de transitiefase, juiste rollen moeten aangenomen worden. Als SE daar verantwoordelijk voor

Ja, bij FS. FB: Ligt bij main-contractors Nee, kan ook geen sturende processen noemen die ingericht zijn volgens BiSL. Alleen voor functiewijzigingen. FB: Alles zelf behalve wanneer er hoge kosten mee gemoeid zijn. Zit één laagje tussen. Vallen wel onder dezelfde dienst en er is een hierarchische realtie. FB: Niet heel dicht bij. Veel delegeren aan Teamleider. Lossen elkaar af. FB: Geen vervaning, wel waarnemer of iemand die handeld zoals FB. Ja en wordt ook uitgevoerd. FB: een adviserende rol, soms ook bijsturen Voeren wel technisch en applicatiebeheer uit. FB: main contractor en de subcontractors Niet benoemd.

Bijna nooit, dat doet de teamleider. FB: via teamleider

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.


IS5 Name Gebouwbeheersysteem Science Park Name


R3.1

Basisinformatie

R3.1.1 R3.1.2 R3.1.3


R3.2


R3.2.1 R3.2.2


R3.2.3 R3.2.4


R3.2.5


Aantal

Beschikbaar

Gevalideerd

Nee Nee Nee

Nee Nee Nee

Beoordeling

Systeemeigenaar

R3.3 R3.3.1


R3.3.2 R3.3.3 R3.3.4


R3.3.5


R3.4


R3.4.1 R3.4.2 R3.4.3


R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5



1 1 1

1 1 1 1

4 4

4 4

Nee Nee

4 1

4 1

Nee

1

1 4

4

4

2 2 3

2 2 3

1

1 2

4 1 2

4 1 2 2

4 3 4 5 5

4 3 4 5 5

3

5

Nee Nee Nee

5

Ja Nee Nee 3

R3.5.6 R3.5.7 R3.5.8

Toegang netwerk systeemeigenaren Invloed werkzaamheden Noodzakelijke communicatiekanalen

1 2 4

1 2 4

R3.5.9 R3.5.10


2 4

2 4 4

R3.6 R3.6.1 R3.6.2 R3.6.3


4 4 5

4 4 5 4 3

2 2

2 2

R4


R4.1 R4.1.1 R4.1.2


R4.1.3 R4.1.4


10

3 29

2 3

2 3 2

4

R4.2 R4.2.1


5

5

R4.2.2 R4.2.3 R4.2.4

FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB

1 3 4

1 3 4

R4.2.5 R4.2.6 R4.2.7

Afstand functioneel beheer en systeemeigenaar Vervanging functioneel beheerder Rolbelegging functioneel beheerder

3 4 5

3 4 5

R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12

Geen applicatiebeheer of technisch beheer Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

1 1 1 1 2

1 1 1 1 2 3

12

R4.3 R4.3.1

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen

3

3

R4.3.2


2

2

R4.3.3


3

3

R4.3.4


2

2

R4.3.5


3

3 3 2 3

6 22 51


Toelichting


Onervaren door recentheid aanstelling. Nu wel duidelijk wat de SE mag, kan en moet. Select aantal mensen mee bezig.' Niet op papier. Onbekend bij SE. Structuur is er nog niet, maar wel gewenst.


Is er. Zou bekend moeten zijn bij alle gebruikers. Verward met call-routering. Ja, zijn beschreven. Niet ontvangen.

Controle over budget (meerjarig). SE weet niet of er toegang is, maakt er geen gebruik van. Teamleider zit ertussen. Te vakspecialistisch. Ontwikkeling komt uit de business zelf.

Niet echt opgedeeld. Zit nog in de transitiefase, juiste rollen moeten aangenomen worden. Als SE daar verantwoordelijk voor

Ja, bij FS. Nee, kan ook geen sturende processen noemen die ingericht zijn volgens BiSL. Alleen voor functiewijzigingen. Zit één laagje tussen. Vallen wel onder dezelfde dienst en er is een hierarchische realtie. Lossen elkaar af. Ja en wordt ook uitgevoerd. Voeren wel technisch en applicatiebeheer uit. Niet benoemd.

Bijna nooit, dat doet de teamleider.

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.


IS6 GBS-KMH (HvA) Gebouwbeheersysteem Koetsier-Mantaignehuis Name


Aantal

Beschikbaar

Gevalideerd

Nee Nee Nee

Nee Nee Nee

Beoordeling


R3.1

Basisinformatie

R3.1.1 R3.1.2 R3.1.3


R3.2


R3.2.1 R3.2.2


R3.2.3 R3.2.4


Nee Nee

4 1

3

4 1

R3.2.5


Nee

1

1

1 4

R3.3 R3.3.1


R3.3.2 R3.3.3 R3.3.4


R3.3.5


R3.4


R3.4.1 R3.4.2 R3.4.3


R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5

Systeemeigenaar


1 1 1

1

3

4 4

4 4

5

Nee Nee Nee

4

4

4 4 4

4 4 4

1

1 4

5

Ja Nee Ja

4 1 4

3 4

3


1 1 1 1

4 3 4 5 5

4 1 2 2

4 3 4 5 5

R3.5.6


1

R3.5.7 R3.5.8

Invloed werkzaamheden Noodzakelijke communicatiekanalen

2 4

R3.5.9 R3.5.10


2 4

2 4 4

R3.6 R3.6.1 R3.6.2 R3.6.3


4 4 5

4 4 5 4 4

R4


R4.1 R4.1.1 R4.1.2


R4.1.3 R4.1.4


1 2

10

3 29

2 2

1

2 3


5

R4.2.2


1

R4.2.3 R4.2.4


3 4

2 2 2 3 2

4

R4.2 R4.2.1

2 4

1

3 1

3 5

3 5

R4.2.5


3

2

3

R4.2.6


4

2

3

R4.2.7


5

5

5

R4.2.8 R4.2.9 R4.2.10 R4.2.11


1 1 1 1

1 1 1

1 1 1 1

R4.2.12


2

1

2 2

2

3

12

R4.3


R4.3.1


3

R4.3.2


2

2

R4.3.3


3

3

R4.3.4


2

R4.3.5


3 6 22 51


1

2

3 3 2 3

Toelichting


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


Is er. Zou bekend moeten zijn bij alle gebruikers. FB: Is er wel maar niet bekend bij alle gebruikers Verward met call-routering. Ja, zijn beschreven. Niet ontvangen.

Controle over budget (meerjarig). SE weet niet of er toegang is, maakt er geen gebruik van. Teamleider zit ertussen. FB: Niet direct, teamleider zit er tussen Te vakspecialistisch. Ontwikkeling komt uit de business zelf.

Niet echt opgedeeld. FB: regelen via main-contractor Zit nog in de transitiefase, juiste rollen moeten aangenomen worden. Als SE daar verantwoordelijk voor

Ja, bij FS. FB: Ligt bij main-contractors Nee, kan ook geen sturende processen noemen die ingericht zijn volgens BiSL. Alleen voor functiewijzigingen. FB: Alles zelf behalve wanneer er hoge kosten mee gemoeid zijn. Zit één laagje tussen. Vallen wel onder dezelfde dienst en er is een hierarchische realtie. FB: Niet heel dicht bij. Veel delegeren aan Teamleider. Lossen elkaar af. FB: Geen vervaning, wel waarnemer of iemand die handeld zoals FB. Ja en wordt ook uitgevoerd. FB: een adviserende rol, soms ook bijsturen Voeren wel technisch en applicatiebeheer uit. FB: main contractor en de subcontractors Niet benoemd.

Bijna nooit, dat doet de teamleider. FB: via teamleider

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.


R3.1 R3.1.1 R3.1.2 R3.1.3

IS7 Name SAP Finance and Control Name

Description Verantwoordelijkheid basisinformatie Basisinformatie Lijst IV-diensten en gebruikers Architectuurplaat Informatie over betrokkenen Totaal

R3.2 R3.2.1 R3.2.2 R3.2.3 R3.2.4 R3.2.5

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen Belegging rollen Escalatieschema’s Crisisplan Updates en upgrades Totaal

R3.3 R3.3.1 R3.3.2 R3.3.3 R3.3.4 R3.3.5

Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en Afspraken met andere eenheden Totaal

R3.4 R3.4.1 R3.4.2 R3.4.3

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6

R3.5.7 R3.5.8 R3.5.9

R3.5.10

R3.6 R3.6.1 R3.6.2 R3.6.3

Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Communicatieprotocol Onderhoudsplannen Totaal

Gevalideerd

Nee Ja Nee

Nee Nee Nee

Geschoolde gebruikers Totaal Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid innovatie Afstemming centraal IM Betrokkenheid contracten en SLA's Totaal Totaal R3 Uitgangspunten bij het beheer van de informatiesystemen Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS Invulling applicatiecoördinatie Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal

Beoordeling

Systeemeigenaar

Nee. Nee. Nee.

3 2

1 1 1 1 3 1

1 1 3

1 1 1 1 1 1

1 1 1

1 1 1

1 1 1 1 1

2 1 1 1

2 1 1 1 1

5 1

5 1

1 1

1 1

R4.2.5


1

1

R4.2.6 R4.2.7 R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12

Vervanging functioneel beheerder Rolbelegging functioneel beheerder Geen applicatiebeheer of technisch beheer Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

3 1 1 1 1 1 1

3 1 1 1 1 1 1 1

R4.3 R4.3.1 R4.3.2 R4.3.3 R4.3.4 R4.3.5

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement Afspraken ICTS met systeemeigenaar over AB, TB H&H Totaal 6 Totaal R4 22 Alle uitgangspunten 51

1 1 1 5 1

1 1 1 5 1 1 1 1

12


Rol van ICTS niet duidelijk.

Binnen AC.

Geen idee. FB: Dat gaat via Topdesk. Er is een onderhoudskalender.

1 1 1 1 1 1

1 1 1

4


3 1 3 3

4 1

3 29

Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL

4

4 10

Nee

Lijst met gebruikers (=autorisaties) Wel eens gezien. Rollen gekoppeld aan functies.

1 1 1 1 3

3

Nee

1 3 1 1

1 3 1 1 1 1

5

Ja Nee Nee

Toelichting

1 3 1 1 1

5

Nee Nee Nee


3

Invloed werkzaamheden Noodzakelijke communicatiekanalen Advies centrale informatiemanagers

R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4

R4.2.3 R4.2.4

Beschikbaar

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar Budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren

R4

R4.2 R4.2.1 R4.2.2

Aantal

Ø 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.

In ieder gevan FB van TB gescheiden.

Binnen dezelfde afdeling. Weet ik niet. FB: Grote lijnen bepalen we het zelf en dat is niet goed. Ø Ik beleef nog helemaal geen rol. Dat blijkt ook wel uit de antwoorden. Het is slechts een aankondiging geweest. Intern geregeld binnen FB-afdeling. Geen gedetailleerde kennis.

Contracten lopen via ICTS.


IS8 Name SAP Finance and Control Name


R3.1 R3.1.1 R3.1.2 R3.1.3

Basisinformatie Lijst IV-diensten en gebruikers Architectuurplaat Informatie over betrokkenen Totaal

R3.2 R3.2.1 R3.2.2 R3.2.3

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen Belegging rollen Escalatieschema’s

R3.2.4 R3.2.5

R3.3 R3.3.1 R3.3.2 R3.3.3 R3.3.4 R3.3.5

R3.4 R3.4.1 R3.4.2

R3.4.3

Crisisplan Updates en upgrades Totaal Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en Afspraken met andere eenheden Totaal

Aantal

Gevalideerd

Nee Ja Nee

Nee Nee Nee

Beoordeling


Toelichting

3 2

1 3 1 1

Lijst met gebruikers (=autorisaties) Wel eens gezien. Rollen gekoppeld aan functies.

1 3 1

1 3 1

Systeemeigenaar


3

Nee. Nee Nee

1 1

Nee Nee Nee

1 1 1 1 3

2

5

Ja Nee

1 1

Nee

2 1 1

1 1 1 1 3 1

5

Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Communicatieprotocol


Beschikbaar

2

2 1

3

3 2

3

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar Budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren

1 1 1 1 1 1

1 1 1 1 1 1

R3.5.7 R3.5.8 R3.5.9

Invloed werkzaamheden Noodzakelijke communicatiekanalen Advies centrale informatiemanagers

1 1 1

1 1 1

R3.5.10

R3.6 R3.6.1 R3.6.2 R3.6.3

Geschoolde gebruikers Totaal Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid innovatie Afstemming centraal IM Betrokkenheid contracten en SLA's Totaal Totaal R3

Er is een onderhoudskalender. FB: Onderhoudsplannen noemen we upgrades en die gebeuren periodiek. Daar is een lijst van.

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.

1 1 1

1 1 1 1 1

2 1 1 1

2 1 1 1 1

In ieder gevan FB van TB gescheiden.

5 1

Binnen dezelfde afdeling.

R4


R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4

Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS Invulling applicatiecoördinatie Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal

R4.2 R4.2.1 R4.2.2


5 1

R4.2.3 R4.2.4


1 1

R4.2.5


1

1

R4.2.6 R4.2.7 R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12

Vervanging functioneel beheerder Rolbelegging functioneel beheerder Geen applicatiebeheer of technisch beheer Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

3 1 1 1 1 1 1

3 1 1 1 1 1 1 1

R4.3


R4.3.1 R4.3.2 R4.3.3 R4.3.4 R4.3.5

FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement Afspraken ICTS met systeemeigenaar over AB, TB H&H Totaal 6 Totaal R4 22 Alle uitgangspunten 51

4

2 3

12


Geen idee. FB: Dat gaat via Topdesk.

4 1

3 29

Nee

Binnen AC.

4 10

Nee

Rol van ICTS niet duidelijk. FB: Wij bellen 2200. ICTS moet het oplossen.

1 1 1 5 1

2

5

2 2

2 1 1 5 1 1 1 1

Weet ik niet. FB: Grote lijnen bepalen we het zelf en dat is niet goed. FB: Wij zitten in de uitvoering. Ik beleef nog helemaal geen rol. Dat blijkt ook wel uit de antwoorden. Het is slechts een aankondiging geweest. Intern geregeld binnen FB-afdeling. Geen gedetailleerde kennis.

FB: Zou wel moeten, maar is niet altijd het geval. Soms stuurt techniek.

Contracten lopen via ICTS. Geen interne contracten.


IS9 Name Elektronische leeromgeving Name


Aantal

Document beschikbaar

Gevalideerd

Nee Nee Nee

Nee Nee Nee

Beoordeling

Systeemeigenaar


Toelichting

1 1 1 1

Niet bekend -> FB Niet bekend -> FB Niet bekend -> FB

Nee, nog niet officiëel overgedragen. Functioneel beheerder neemt meeste rollen op zich. Nog geen applicatiecoördinatie. Onbekend bij SE. Meeste controle bij functioneel beheerder. Vastgelegd, ook t.a.v. bijhorende communicatie.

R3.1 R3.1.1 R3.1.2 R3.1.3

Basisinformatie Lijst IV-diensten en gebruikers Architectuurplaat Informatie over betrokkenen Totaal

R3.2 R3.2.1

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen

1

1

R3.2.2 R3.2.3

Belegging rollen Escalatieschema’s

2 1

2 1

R3.2.4

Crisisplan

2

2

R3.2.5


3

3 2

2

2

FB. Eenzijdig gevoel aansluiting werkprocessen. Niet bekend -> FB. Niet bij betrokken, diensteigenaar in combinatie met FB wel.

3

5


R3.3


R3.3.1


R3.3.2


Nee

1

1

R3.3.3


Nee

1

1

R3.3.4 R3.3.5

Afpraken met relevante SE'en Afspraken met andere eenheden Totaal

Nee

1 2

1 2 1

R3.4


R3.4.1 R3.4.2 R3.4.3


Ja Nee Nee

3 1 3

3 1 3 3

R3.5 R3.5.1 R3.5.2 R3.5.3


4 4 3

4 4 3

R3.5.4 R3.5.5

Voldoende beschikbaar Budget Voldoende deskundig personeel

1 2

1 2

R3.5.6 R3.5.7

Toegang netwerk systeemeigenaren Invloed werkzaamheden

1 1

1 1

R3.5.8 R3.5.9

Noodzakelijke communicatiekanalen Advies centrale informatiemanagers

2 1

2 1

R3.5.10


3

3 2

5

3

10

R3.6 R3.6.1

Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid innovatie

1

1

R3.6.2

Afstemming centraal IM

3

3

R3.6.3

Betrokkenheid contracten en SLA's Totaal Totaal R3

1

1 1 1

3

3

1 4 1

1 4 1 2

3 29

R4


R4.1 R4.1.1

Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS

R4.1.2 R4.1.3 R4.1.4

Invulling applicatiecoördinatie Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal

R4.2 R4.2.1


5

5

R4.2.2


1

1

R4.2.3

Systeemeigenaar onderdeel sturende laag FB

4

4

R4.2.4


4

4

R4.2.5 R4.2.6 R4.2.7


2 1 1

2 1 1

R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12


2 4 1 3 2

2 4 1 5 2 2

Nee

Nee

4

12

R4.3


R4.3.1 R4.3.2

FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS)

1 2

1 2

R4.3.3


1

1

R4.3.4


1

1

R4.3.5


1

1 1 2 1

6 22 51


FB voor nodig. Geen idee over afspraken. Ja, maar met diensteigenaren. Is wel de bedoeling

Hetzelfde als incidentmanagement. Is wel iets van een proces. Niet bekend. Leverancier geeft dit aan.

Praktijk anders dan theorie. Gaat afdelingshoofd (diensteigenaar) over. Te weinig inzicht over. Maak er geen gebruik van. Niet het gevoel dat ik er iets mee moet. Nu niet. Moeilijk communiceren met eindgebruiker, moet via communicatie. Kan er geen antwoord op geven. T.a.v. systeem wel. Wel wat te verbeteren t.a.v. werken in een grote organisatie. Oude manier van werken . Andere mindset nodig.

Nu niet. Geen idee over afstemming CIM, wel betrokken bij werkplekken. Niet met BlackBoard i.v.m. scheiding van afdelingen.

Volgens mij gescheiden. Applicatiecoordinatie moet nog ingericht worden. Ja, behalve applicatiecoordinatie. Nee

Intern belegd Geen idee. Vermoed dat er key-users zijn of decentrale FB. Volgens mij doet FB praktisch alles, behalve grote wijzigingen of wanneer er geld mee gemoeid gaat. FB is operationeel, maar door sommige zaken ook tactisch i.v.m. groot aantal studenten als gebruiker. Niet genoeg i.v.m. transitie. Afdelingshoofd zit ertussen. Niet bekend. Niet bekend. Applicatiebeheer niet bekend, vernoed van wel. Technisch bejeer niet. FB alleen op operationeel betrokken bij contractmanagement zou wel moeten. Is nu niet het geval Ja, maar kan alleen FB benoemen Niet bekend. Frequentie niet bekend.

Geen idee hoe dit in de praktijk is, zou wel zo moeten zijn Heel ruim Zou zo moeten zijn. Er is alleen maar een diensteigenaar. via de sourcingmanager, onder klantmanagement een andere afdeling Nog in transitie, nu op een andere manier geregeld.


IS10 Name Mail, agenda en online notities medewerkers UvA /HvA Name


R3.1 R3.1.1

Basisinformatie Lijst IV-diensten en gebruikers

R3.1.2

Architectuurplaat

R3.1.3


R3.2 R3.2.1


R3.2.2 R3.2.3

Belegging rollen Escalatieschema’s

R3.2.4

Aantal

Beschikbaar

Gevalideerd

Nee

Beoordeling


Toelichting

Nee

1

Ja

Nee

4

Nee

Nee

2 2

Alleen in dienstencatalogus. Beschikbaar. SE geen weet van. FB: Ja, permanent wijzigingen. Gebruiken methode van microsoft, erg uitgebreid. FB: alle beheertaken zijn belegd. Wel gedocumenteerd, beheer het niet zelf.

Systeemeigenaar


3

1

1

Ja

4 4

4 4

Crisisplan

Ja

2

3

3

R3.2.5


Ja

4

4

4 4

R3.3


R3.3.1


R3.3.2


R3.3.3 R3.3.4 R3.3.5

5

3

3

Nee

3

3


Nee

3

3

Afpraken met relevante SE'en Afspraken met andere eenheden Totaal

Nee

3 3

3 3 3

Ja

4

4

Nee Nee

3 3

3 3 3

5

R3.4 R3.4.1

Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering

R3.4.2 R3.4.3

Communicatieprotocol Onderhoudsplannen Totaal

R3.5 R3.5.1 R3.5.2 R3.5.3


4 4 3

4 4 3

R3.5.4

Voldoende beschikbaar budget

4

4

R3.5.5

Voldoende deskundig personeel

2

2

R3.5.6


1

R3.5.7


1

R3.5.8 R3.5.9 R3.5.10

Noodzakelijke communicatiekanalen Advies centrale informatiemanagers Geschoolde gebruikers Totaal

2 1 3

2 1 3 3

R3.6 R3.6.1 R3.6.2 R3.6.3


4 4 4

4 4 4 4 3

4 1

4 1

2 3

2 3 3

5 1

R4


R4.1


R4.1.1 R4.1.2

Opdeling beheer IS Invulling applicatiecoördinatie

R4.1.3 R4.1.4


3

1 1

10

3 29

4

1

R4.2 R4.2.1 R4.2.2


5 1

R4.2.3 R4.2.4


4 4

3

4 4

R4.2.5


4

4

4

R4.2.6 R4.2.7

Vervanging functioneel beheerder Rolbelegging functioneel beheerder

1 4

1

1 4

R4.2.8


4

4

4

R4.2.9 R4.2.10 R4.2.11

Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer

2 1 1

1

2 1 1

R4.2.12


4

4

4 4

4

4

12

R4.3 R4.3.1

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen

4

R4.3.2 R4.3.3 R4.3.4

SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement

4 3 4

R4.3.5


3 6 22 51


4 3 4 4

4 4 4 3

Nog niet. Incidentmanagement, wijzigingsbeheer, configuratiebeheer. Geen probleemmanagement. Ja, valt onder Code Rood-procedure. Alleen globaal voor UvA. FB: Staat in het beheerplan. Wordt 'Fire-drill'genoemd. Als die is geregeld heb je ook een crisisplan. 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. SE alleen betrokken bij major wijzigingen of als er echt escalaties plaatsvinden. Geen afspraken met gebruikersorganisatie. Wel overleg. Geen afspraken met andere SE'en, wel met FB'ers. Geen afspraken. Speelt binnen ICTS.

FB: Sjabloon in Topdesk Geen vastgelegd protocol. Wel een vaste manier van werken. Ligt bij Microsoft.

Praktijk anders dan theorie. Inzicht bij controller. Voor alles wat nodig is is er budget beschikbaar. Voldoende bechikbaar. Deskundigheid minder geworden door integratie met HvA. Maak er geen gebruik van. Niet het gevoel dat ik er iets mee moet. Nu niet. FB: eigenlijk niet, formeel wel. Doe niets zonder akkoord van de SE Moeilijk communiceren met eindgebruiker, moet via communicatie. Nog niet eerder meegemaakt. Nee, daar is dan geen budget voor.

Is opgedeeld, er is alleen geen applicatiecoördinatie ingericht. Niet ingevuld. Niet als diensten maar als onderdeel van een IV-dienst.

SE: Weet ik niet. Alles m.b.t. geld en grote wijzigingen naar SE, rest FB. FB: Elk besluit wordt wel op de hoogte gebracht Redelijk dicht, zit een afdelingshoofd tussen. FB: heel dicht, hierarchisch Geen vervaning geregeld. FB: Niet structureel geregeeld. Ad-hoc Ja, uitvoerend en adviserend. Geen applicatiebeheer en technisch beheer activiteiten. Zijn benoemd, verdient wel meer aandacht. SE: Weet ik niet. SE: Weet ik niet. Minstens eenmaal in de maand. FB: structureel maandelijks

FB: applicatiebeheer niet ingericht, doen we zelf. Alleen servicemanager. Contract met SURF is onveranderlijk. Geen afspraken, het valt allemaal onder ICTS. FB: vastgelegd in het beheerplan.


IS11 Name Digitale leer- en werkomgeving Name


R3.1 R3.1.1 R3.1.2


R3.1.3


R3.2

Aantal

Beschikbaar

Gevalideerd

Beoordeling

Nee Nee

Nee Nee

Systeemeigenaar 1 1

Nee

Nee

1

3


Toelichting

1 1

Vragen aan FB. Vragen aan FB. Vragen aan FB. DLWO heeft geen dienstencatalogus. Moet nog geschreven worden.


1 1


R3.2.1 R3.2.2 R3.2.3 R3.2.4 R3.2.5

Volledige beheerketen Belegging rollen Escalatieschema’s Crisisplan Updates en upgrades Totaal

R3.3


Nee Nee Nee

3 1 1 1 2

3

3 1 1 1 2 1

R3.3.1


4

4

R3.3.2 R3.3.3

Regie wijzigingsbeheer Afspraken wijzigingsbeheer

Nee Nee

2 1

2 1

R3.3.4


Nee

3

3

R3.3.5


3

3 3

1 1 4

1 1 4 1

4 3 3 1

4 3 3 1

4 1 1 2 1 1

4 1 1 2 1 1 2

2 2 5

2 2 5 2 2

4 3 1 1

4 3 1 1 2

R3.4


R3.4.1 R3.4.2 R3.4.3


R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar Budget

R3.5.5 R3.5.6 R3.5.7 R3.5.8 R3.5.9 R3.5.10

Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden Noodzakelijke communicatiekanalen Advies centrale informatiemanagers Geschoolde gebruikers Totaal

R3.6


R3.6.1 R3.6.2 R3.6.3

Betrokkenheid innovatie Afstemming centraal IM Betrokkenheid contracten en SLA's Totaal Totaal R3

R4


R4.1


R4.1.1 R4.1.2 R4.1.3 R4.1.4

Opdeling beheer IS Invulling applicatiecoördinatie Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal

3

Ja Nee Nee 3

5

3 20

4

R4.2 R4.2.1


5

5

R4.2.2 R4.2.3 R4.2.4 R4.2.5 R4.2.6 R4.2.7

FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB Afstand functioneel beheer en systeemeigenaar Vervanging functioneel beheerder Rolbelegging functioneel beheerder

4 3 1 1 1 5

4 3 1 1 1 5

R4.2.8 R4.2.9 R4.2.10 R4.2.11


3 5 1 3

3 5 1 3

R4.2.12


5

5 3

4 3 3

4 3 3

R4.3 R4.3.1 R4.3.2 R4.3.3

12

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten

R4.3.4


4

4

R4.3.5


4

4 4 3 3

3 19 39


Beleef de verantwoordelijkheid wel, maar kan het niet dragen voor de volledige beheerketen. Meer inzicht is nodig. Mee bezig. Mee bezig. Planmatig, vagen aan Edward Zijlstra.

Edward Zijlstra op tactisch niveau. Moeilijk te zeggen, iedereern wil aansluiten op DLWO. Goede aansluiting op werkprocessen. Gewerkt volgens BiSL, nog niet zelf bij bterokken. Geen afspraken. Er zijn afspraken, maar weet niet of ze vastgelegd zijn --> Edward Zijlstra Ja, bij 2AT. Maar weet niet of ze vastgelegd zijn --> Edward Zijlstra

Via Excel sheets, gaat verder wel gebeuren. Denk het wel. Dus niet zeker van.

Kan zeker beter. Kan beter. Geen idee. Genoeg personeel, deskundigheid weet ik niet. Bestaat volgens mij nog niet. Nog niet, hoop straks wel. vermoed wel, aan Edward vragen. Nog nooit gezien. Geen idee.

Niet bij innovatie, wel bij aamelden en aansturen iv-projecten. Nog in de kinderschoenen. Ja.

Applicatie-beheer en -coördinatie bij functioneel beheer. Technisch beheer en h&h 2AT.

Wel ingericht, processen kunnen niet worden benoemd. Fb doet eigenlijk alles. Nee. Edward zit er nog tussen. Geen idee. Adviserend. Applicatiebeheer denk ik wel, technisch beheer niet. Ja, decentraal functioneel beheerders. Bespreken met Edward Zijlstra. Vragen aan Edward Zijlstra. 1x per maand. FB gaat onder mij vallen. Synergie creëren.

Ik denk het wel. Moet aan gewerkt worden. De sourcing managers die onder ICTS vallen. Interne dienstverlening geen contracten. Geregeld door de sourcing manager, ik moet we wel meer vanaf weten.


IS12 Name Servicemanagementapplicatie tbv AC,FS Bol, Juridische zaken, Bureau Alumni Name


R3.1 R3.1.1 R3.1.2 R3.1.3

Basisinformatie Lijst van IV-diensten Architectuurplaat Informatie over betrokkenen Totaal

R3.2 R3.2.1


R3.2.2 R3.2.3 R3.2.4 R3.2.5

Belegging rollen Escalatieschema’s Crisisplan Updates en upgrades Totaal

R3.3


R3.3.1 R3.3.2 R3.3.3

Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer

R3.3.4


R3.3.5


Aantal

Vastgelegd

Gevalideerd

Ja Ja Nee

Nee Nee Nee

Beoordeling

Systeemeigenaar

3

5


Toelichting

4 4 1 4

Lijst is aanwezig. SE geen weet van. Is aanwezig. Niet vastgelegd, wel bekend.


5

4 1 1 3

4 1 1 3 3

Nee

4 2 2

4 2 2

Nee

3

3

Nee

3

3 3

Ja

3

3

Nee Nee 5

5

R3.4


R3.4.1

Call-routering

R3.4.2


Nee

2

2

R3.4.3


Nee

2

2 2

3 4 4 4 4 4 5 4 2

3 4 4 4 4 4 5 4 2

3

3 4

4 3

4 3

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7 R3.5.8 R3.5.9

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar Budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden Noodzakelijke communicatiekanalen Advies centrale informatiemanagers

R3.5.10


R3.6


R3.6.1 R3.6.2

Betrokkenheid innovatie Afstemming centraal IM

R3.6.3

Betrokkenheid contracten en SLA's Totaal Totaal R3

R4


R4.1


R4.1.1 R4.1.2

Opdeling beheer IS Invulling applicatiecoördinatie

R4.1.3 R4.1.4


3

10

1

1 3 3

4 4

4 4

3 1

3 1 4

3 29

4

R4.2 R4.2.1 R4.2.2 R4.2.3 R4.2.4 R4.2.5

Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB Afstand functioneel beheer en systeemeigenaar

5 1 4 4 5

5 1 4 4 5

R4.2.6 R4.2.7


4 4

4 4

R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12


3 3 1 2 5

3 3 1 2 5 4

12

R4.3 R4.3.1 R4.3.2

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS)

5 2

5 2

R4.3.3 R4.3.4

SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement

2 1

2 1

R4.3.5


1

1 2 3 3

6 22 51


Geen incidentmanagement vastgelegd. Wijzigingsbeheer niet goed ingericht. Geen apart probleemmanagement. Belegging rollen wel helder. Niet beschikbaar. Niet beschikbaar. Gebeurt incidenteel.

Key-user-overleg + overleg op projectbasis. Niet volgens BiSL. Geen afspraken. SE is verantwoordelijk. Op functioneel niveau. Niet vastgelegd, maar weten elkaar te vinden. Niet vastgelegd, alleen op niveau van rollen en rechten van personen.

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.

Geen kennis van BiSL. Wel van IS en IM.

Directe invloed. Dat is minimaal. Te groot aantal gebruikers om daar voldoende zicht op te hebben.

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.

Opgedeeld in elke laag. Applicatiebeheer niet zeker. Applicatiecoördinator benoemd. Formeel niet. Niet beschreven wat er verwacht mag worden, alleen voor TB is dat wel het geval. Nee, dat is voor ICTS.

Dichter kan niet. FB'ers vervangen elkaar. Nog niet structureel vastgelegd.

Sommige aspecten van applicatiebeheer. In ieder geval geen technisch beheer. Niet als onderdeel FB. Geen kennis van BiSL. Wekelijks overleg.

Nee, niet voor uitbesteedde lagen Leidinggevende van de applicatiecoördinator is daar verantwoordelijk voor. Nee, afdeling Inkoop. Ja. Applicatiecoördinatie onvoldoende structureel ingeregeld.


R3.1 R3.1.1 R3.1.2 R3.1.3

IS13 Name SAP PI broker (ESB):uitwisseling van gegevens tussen bedrijfsapplicaties Name

Description Verantwoordelijkheid basisinformatie Basisinformatie Lijst van IV-diensten Architectuurplaat Informatie over betrokkenen Totaal

R3.2


R3.2.1


R3.2.2 R3.2.3 R3.2.4 R3.2.5

Belegging rollen Escalatieschema’s Crisisplan Updates en upgrades Totaal

R3.3


R3.3.1 R3.3.2

Afstemming gebruikersorganisatie Regie wijzigingsbeheer

R3.3.3


R3.3.4


R3.3.5


R3.4 R3.4.1

Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering

R3.4.2 R3.4.3

Communicatieprotocol Onderhoudsplannen Totaal

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7 R3.5.8

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar Budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden Noodzakelijke communicatiekanalen

R3.5.9 R3.5.10


R3.6 R3.6.1


R3.6.2 R3.6.3


Aantal


Document gevalideerd

Nee Nee Nee

Nee Nee Nee

Beoordeling

Systeemeigenaar

3

Nee Nee


Toelichting

1 1 1 1

Verwijs ik door naar Nataša Rakic. Weet ik ook niet. Er is een zelfde beeld, geen overzicht.


1

1

2 2 1 2

2 2 1 2 2

5

2 1

2 1

Nee

2

2

Nee

3

3

1

1 2

Ja

1

1

Nee Nee

3 1

3 1 1

4 4 4 3 4 5 1 5

4 4 4 3 4 5 1 5

4 1

4 1 4

1

1

3 1

3 1 1 2

5

3

10

3 29

R4


R4.1


R4.1.1

Opdeling beheer IS

4

4

R4.1.2 R4.1.3 R4.1.4

Invulling applicatiecoördinatie Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal

1 2 5

1 2 5 3

4

R4.2 R4.2.1 R4.2.2 R4.2.3 R4.2.4

Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB

5 1 1 5

5 1 1 5

R4.2.5 R4.2.6 R4.2.7


3 4 4

3 4 4

R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12


3 4 1 1 1

3 4 1 1 1 3

2 1 5 1 1

2 1 5 1 1 1 2 2

R4.3 R4.3.1 R4.3.2 R4.3.3 R4.3.4 R4.3.5

12

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement Afspraken ICTS met systeemeigenaar over AB, TB H&H Totaal 6 Totaal R4 22 Alle uitgangspunten 51


"Ik ben officieel nog geen SE". Sta er wel helemaal achter. Wel helder belegd, juist belegd weet ik niet. Geen weet van de diverse documenten. Impliciet, explicit checken. "Benieuwd naar". Denk het wel, checken.

Gokken of aan Nataša navragen. Denk wel aansluiting op werkprocessen en behoeften. Frequentie gesprekken niet duidelijk. Niet bekend. Wel afspraken met gebruikersorg. Miet bekend et externe partijen. Afspraken niet bekend. "Bij mijn weten wel, geen weet van vastgelegde afspraken. Wel de indruk dat er overleg plaatsvindt." Wel uitvoering in andere eenheden, weet niet hoe goed vastgelegd.

Bestaat wel, niet bekend bij SE. Inzciht op afstand, verwacht dat het expliciet is afgesproken. Checken.

Als dat moet lukt dat. Geen zorgen over. Ja heb ik wel. Als het nuttig advies is zal ik het zeker doen. Niet bekend.

Weinig ervaring mee. Ja, via i-governance en gaat steeds beter. Nog niet betrokken gaat wel gebeuren. Ga ik betrokken bij zijn.

Applicatiecoordinatie wordt nog ingericht. Applicatiecoordinatie wordt nog ingericht. Ja, want belegd binnen ICTS.

Intern belegd. Niet bekend. Moeilijk te zeggen. Ja. Organisatorisch is anders dan feitelijk. Niet hierarchisch in mijn oogpunt. Intern gergegeld. Ja en voeren het ook uit. Sommige rollen door dezelfde mensen uitgevoerd. Technisch beheer is beter gescheiden. Operationeel betrokken bij contractmanagement. SE: Dat verwacht ik wel.

Niet bekend.

Verweven met team van Nataša. Wel verantwoordelijk vanwege afnemers. Ligt bij de divisie klant. Zijn er niet Niet vastgelegd.

IT Governance at Higher Education Institutes in Amsterdam Appendix E – Results tables IS14 Name Active Directory 2AT Extern tbv Sharepoint Name


Aantal



Nee Nee Nee

Nee Nee Nee

Beoordeling

Systeemeigenaar

3

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen Belegging rollen Escalatieschema’s Crisisplan Updates en upgrades Totaal Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en Afspraken met andere eenheden Totaal Verantwoordelijk voor de communicatie met (eind)gebruikers Call-routering Communicatieprotocol Onderhoudsplannen Totaal

Nee Nee

Advies centrale informatiemanagers Geschoolde gebruikers Totaal Overige activiteiten waar de systeemeigenaar een rol bij speelt Betrokkenheid innovatie Afstemming centraal IM Betrokkenheid contracten en SLA's Totaal Totaal R3

Geen weet van. Er is ooit iets getekend. Niet bekend.

2 1 1 1 1

2 1 1 1 1 1

Niet veel zicht op. Geen zicht op. Geen weet van. Geen weet van. Geen weet van.

1 1 1

1 1 1 1

Onbekend. Onbekend. Onbekend.

4 4 4 1 4 5 1 4

4 4 4 1 4 5 1 4

4 4

4 4 4

4 1 1

4 1 1 1 1

Ja, maar via projecten. Niet bekend. Tot nu toe nog niet.

3 3 2 2

3 3 2 2 3

FB, AB, AC bij ICTS. TB en H&H bij 2AT

3 2 1 3 2 2 3 2 1 1 3 1

3 2 1 3 2 2 3 2 1 1 3 1 2

1 3 1 1

1 3 1 1

3

3 1 2 2

3

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden Noodzakelijke communicatiekanalen

1 1 1 1


4 3 1 1 1 1

5

Nee Nee Nee

Toelichting

4 3 1 1 1

5

Nee Nee


10

3 29

Niet geheel duidelijk Niet bekend. Niet bekend. Niet bekend.

Als dat moet lukt dat. Geen zorgen over. Ja heb ik wel. Als het nuttig advies is zal ik het zeker doen.

Uitgangspunten bij het beheer van de informatiesystemen Algemene uitgangspunten m.b.t. beheer Opdeling beheer IS Invulling applicatiecoördinatie Beheerlagen als diensten Verantwoordelijkheid verschillende beheerlagen Totaal Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB Afstand functioneel beheer en systeemeigenaar Vervanging functioneel beheerder Rolbelegging functioneel beheerder Geen applicatiebeheer of technisch beheer Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

Nee

4

12

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement Afspraken ICTS met systeemeigenaar over AB, TB H&H Totaal Totaal R4 Alle uitgangspunten

Nee

6 22 51


In de toekomst meer.

SE: Volgens mij wel. Onduidelijk Nog niet bekend. Geen weet van. Technisch beheer in ieder geval niet. Geen weet van. Niet benoemd. n.v.t. Nooit overleg.

Geen weet van. Geen overeenkomsten vastgelegd. Onduidelijk. Niet vastgelegd. Wordt wel aan verwachtingen voldaan.


R3.1 R3.1.1 R3.1.2 R3.1.3

IS15 Name Active Directory 2AT Extern tbv Sharepoint Name


R3.2 R3.2.1 R3.2.2 R3.2.3 R3.2.4 R3.2.5

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen Belegging rollen Escalatieschema’s Crisisplan Updates en upgrades Totaal

R3.3 R3.3.1 R3.3.2 R3.3.3 R3.3.4 R3.3.5

Verantwoordelijk voor afstemming en afspraken met andere partijen Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en Afspraken met andere eenheden Totaal

R3.4 R3.4.1 R3.4.2 R3.4.3


R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7 R3.5.8

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden Noodzakelijke communicatiekanalen

R3.5.9 R3.5.10


R3.6 R3.6.1 R3.6.2 R3.6.3


R4


R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4


R4.2 R4.2.1 R4.2.2 R4.2.3 R4.2.4 R4.2.5 R4.2.6 R4.2.7 R4.2.8 R4.2.9 R4.2.10 R4.2.11 R4.2.12

Uitgangspunten m.b.t. functioneel beheer FB intern belegd FB ingericht volgens BiSL Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB Afstand functioneel beheer en systeemeigenaar Vervanging functioneel beheerder Rolbelegging functioneel beheerder Geen applicatiebeheer of technisch beheer Key-users benoemd Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

Aantal



Nee Nee Nee

Nee Nee Nee

Beoordeling

Systeemeigenaar

3

Nee Nee

2 1 1 1 1 1

Niet veel zicht op. Geen zicht op. Geen weet van. Geen weet van. Geen weet van.

1 1 1

1 1 1 1

Onbekend. Onbekend. Onbekend.

4 4 4 1 4 5 1 4

4 4 4 1 4 5 1 4

4 4

4 4 4

4 1 1

4 1 1 1 1

Ja, maar via projecten. Niet bekend. Tot nu toe nog niet.

3 3 2 2

3 3 2 2 3

FB, AB, AC bij ICTS. TB en H&H bij 2AT

3 2 1 3 2 2 3 2 1 1 3 1

3 2 1 3 2 2 3 2 1 1 3 1 2

1 3 1 1

1 3 1 1

3

3 1 2 2

10

3 29

Nee

4

12

R4.3 R4.3.1 R4.3.2 R4.3.3 R4.3.4

Uitgangspunten m.b.t. de andere beheerlagen FB stuurt overige beheerlagen SE eindverantwoordelijk voor beheerlagen onder FB (via ICTS) SE en servicemanager verantwoordelijk voor serviceniveau overeenkomsten ICTS verantwoordelijk voor contractmanagement

R4.3.5


6 22 51


Geen weet van. Er is ooit iets getekend. Niet bekend.

2 1 1 1 1

3

Nee

1 1 1 1


4 3 1 1 1 1

5

Nee Nee Nee

Toelichting

4 3 1 1 1

5

Nee Nee


Niet geheel duidelijk Niet bekend. Niet bekend. Niet bekend.

Als dat moet lukt dat. Geen zorgen over. Ja heb ik wel. Als het nuttig advies is zal ik het zeker doen.

In de toekomst meer.

SE: Volgens mij wel. Onduidelijk Nog niet bekend. Geen weet van. Technisch beheer in ieder geval niet. Geen weet van. Niet benoemd. n.v.t. Nooit overleg.

Geen weet van. Geen overeenkomsten vastgelegd. Onduidelijk. Niet vastgelegd. Wordt wel aan verwachtingen voldaan.


IS16 Name Studentinformatiesysteem (HvA) Name


R3.1 R3.1.1 R3.1.2 R3.1.3


R3.2 R3.2.1 R3.2.2

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen Belegging rollen

R3.2.3

Escalatieschema’s

R3.2.4 R3.2.5

Crisisplan Updates en upgrades Totaal

R3.3



Ja Ja Ja

Ja Ja Ja

Beoordeling

Systeemeigenaar


Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en

R3.3.5


Functioneel beheerder 5 5 5 5

3

5 5

5 5

Nee

4

4

Nee

4 4

4 4 4

5


Ja Nee

5 5 5 5

5 5 5 5

5

5 5

5 4 5

5 4 5 5

5

Ja Ja Ja 3

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden

4 2 4 5 5 2 5

4 2 4 5 5 2 5

R3.5.8


4

4

R3.5.9 R3.5.10


2 3

2 3 4

5

5

5 3

5 3 5 5

4 1 1 1

4 1 1 1 1

R3.6 R3.6.1


R3.6.2 R3.6.3


10

3 29

R4


R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4


R4.2 R4.2.1 R4.2.2


5 1

5 1

R4.2.3 R4.2.4 R4.2.5

Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB Afstand functioneel beheer en systeemeigenaar

3 5 5

3 5 5

R4.2.6 R4.2.7


5 5

5 5

R4.2.8 R4.2.9

Geen applicatiebeheer of technisch beheer Key-users benoemd

5 5

5 5

R4.2.10 R4.2.11 R4.2.12

Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

5 5 5

5 5 5 5

R4.3

Toelichting

Wel bekend, niet altijd even goed vastgelegd. Niet veel onderscheid met incidentmanagement.


R3.3.1 R3.3.2 R3.3.3 R3.3.4

R3.4 R3.4.1 R3.4.2 R3.4.3

Aantal

4

12

Systeemeigenaren, verveolgens leden can het college van bestuur in het programma van eigenaren. Samen met expertisecentrum voorleggen. Volgens BiSL en zelf bij betrokken. Beheerdocumenten Technische werkgroep TAO FB is mijn afdeling, Applicatiebeheer (Expertise Centrum) Utrecht, Technisch Beheer is extern (MCX). Hosting en housing is één partij.

Ligt bij communicatieadviseur.

Geld in FTE Zelf opleiden Nog in de kinderschoenen UvA d.m.v. communities is prima. Naar de eindgebruiker Twitter en websites Betrek ze wel bij ontwikkelingen, zij informeren mij niet. Kort lijntje Niet op alle terreinen.

Bij werkplekken ook betrokken, maar als laatste Niet ICTS, wel campsolutions

Ja, behalve technisch beheer en H&H Geen applicatiecoordinatie Nog niets aangeboden als dienst

Geen idee, BiSL geen eerste voorkeur Binnen eigen verantwoordelijkheden en takenpakket Sturend en strategisch Zie ze elke dag, hierarchisch Op iedere taak die er is, is er een tweede en derde. Adviserend Wel personeel die van alles en nog wat kunnen. Af en toe gebruik van makend. 2 soorten: Inschrijf en Volg harmonisatie principes, wijzigingsbeheerzaken. Werkprocessen. Problemen richting administraties, richting andere lagen van de organisatie. 1x per 14 dagen


R4.3.1


4

4

R4.3.2 R4.3.3 R4.3.4


3 3 1

3 3 1

R4.3.5


1

1 3 4 5

6 22 51


Dat proberen ze wel eens, dat gebeurt wel eens. Dan gedoe over. Niet de bedoeling. Wel verantwoordelijk voor beheerlagen, maar niet via ICTS SLA's zijn oud. SE verantwoordelijk Niet bij ICTS ICTS betrekken alleen bij technische keten overleg.


IS16 Name Studentinformatiesysteem (HvA) Name


R3.1 R3.1.1 R3.1.2 R3.1.3


R3.2 R3.2.1 R3.2.2

Verantwoordelijkheid voor het beheer van het IS Volledige beheerketen Belegging rollen

R3.2.3

Escalatieschema’s

R3.2.4 R3.2.5

Crisisplan Updates en upgrades Totaal

R3.3



Ja Ja Ja

Ja Ja Ja

Beoordeling

Systeemeigenaar


Toelichting

Functioneel beheerder 5 5 5 5

3

5 5

5 5

Nee

4

4

Nee

4 4

4 4 4

5

Wel bekend, niet altijd even goed vastgelegd. Niet veel onderscheid met incidentmanagement


R3.3.1 R3.3.2 R3.3.3 R3.3.4

Afstemming gebruikersorganisatie Regie wijzigingsbeheer Afspraken wijzigingsbeheer Afpraken met relevante SE'en

R3.3.5


R3.4 R3.4.1 R3.4.2 R3.4.3

Aantal


Ja Nee

5 5 5 5

5 5 5 5

5

5 5

5 4 5

5 4 5 5

5

Ja Ja Ja 3

R3.5 R3.5.1 R3.5.2 R3.5.3 R3.5.4 R3.5.5 R3.5.6 R3.5.7

Randvoorwaarden voor een goede invulling van systeemeigenaarschap Basale kennis IS, IM, BiSL Kennis architectuurprincipes Relatie i-governance en iv-projectportfoliomaangement Voldoende beschikbaar budget Voldoende deskundig personeel Toegang netwerk systeemeigenaren Invloed werkzaamheden

4 2 4 5 5 2 5

4 2 4 5 5 2 5

R3.5.8


4

4

R3.5.9 R3.5.10


2 3

2 3 4

R3.6 R3.6.1


5

5

R3.6.2 R3.6.3


5 3

5 3 5 5

4 1 1 1

4 1 1 1 1

10

3 29

R4


R4.1 R4.1.1 R4.1.2 R4.1.3 R4.1.4


R4.2 R4.2.1 R4.2.2


5 1

5 1

R4.2.3 R4.2.4 R4.2.5

Systeemeigenaar onderdeel sturende laag FB FB'er onderdeel uitvoerende laag FB Afstand functioneel beheer en systeemeigenaar

3 5 5

3 5 5

R4.2.6 R4.2.7


5 5

5 5

R4.2.8 R4.2.9

Geen applicatiebeheer of technisch beheer Key-users benoemd

5 5

5 5

R4.2.10 R4.2.11 R4.2.12

Afstemming operationele BiSL processen met key-users Key-users/decentraal FB'er onderdeel functioneel beheer Overleg SE met FB'er Totaal

5 5 5

5 5 5 5

4

12

R4.3


R4.3.1


4

4

R4.3.2 R4.3.3 R4.3.4


3 3 1

3 3 1

R4.3.5


1

1 3 4 5

6 22 51


Systeemeigenaren, verveolgens leden can het college van bestuur in het programma van eigenaren. Samen met expertisecentrum voorleggen. Volgens BiSL en zelf bij betrokken. Beheerdocumenten. Technische werkgroep TAO FB is mijn afdeling, Applicatiebeheer (Expertise Centrum) Utrecht, Technisch Beheer is extern (MCX). Hosting en housing is één partij.

Ligt bij communicatieadviseur.

Geld in FTE Zelf opleiden Nog in de kinderschoenen HvA heeft geen communities zoals de UvA. Naar de eindgebruiker Twitter en websites Betrek ze wel bij ontwikkelingen, zij informeren mij niet. Kort lijntje Niet op alle terreinen.

Bij werkplekken ook betrokken, maar als laatste Niet ICTS, wel campsolutions

Ja, behalve technisch beheer en H&H Geen applicatiecoordinatie. Nog niets aangeboden als dienst

Geen idee, BiSL geen eerste voorkeur Binnen eigen verantwoordelijkheden en takenpakket Sturend en strategisch Zie ze elke dag, hierarchisch Op iedere taak die er is, is er een tweede en derde. Adviserend Wel personeel die van alles en nog wat kunnen. Af en toe gebruik van makend. 2 soorten: Inschrijf en Volg harmonisatie principes, wijzigingsbeheerzaken. Werkprocessen. Problemen richting administraties, richting andere lagen van de organisatie. 1x per 14 dagen

Dat proberen ze wel eens, dat gebeurt wel eens. Dan gedoe over. Niet de bedoeling. Wel verantwoordelijk voor beheerlagen, maar niet via ICTS SLA's zijn oud. SE verantwoordelijk Niet bij ICTS ICTS betrekken alleen bij technische keten overleg.

INTERVIEW GAP-ANALYSE Auteurs

:


Versie

:

0.7

Datum

:

28-04-2014

Version management

Versie

Datum

Verstuurd naar

Doel

0.5

28-04-2014

Kandidaten interview

Ter voorbereiding interview

0.6

29-04-2014



0.7

08-05-2014

Verwerking antwoorden

Interview Gap-analyse IS Beheer Samenwerkende Diensten HvA/UvA

Page. 1 of 21

Index Index .............................................................................................................................................................................................................2 1


2

Interviewvragen ..........................................................................................................................................................................4 2.1

VERANTWOORDELIJKHEID VOOR DE BASISINFORMATIE VAN HET IS .......................................................................4

2.2

VERANTWOORDELIJKHEID VOOR HET BEHEER VAN HET IS ........................................................................................5

2.3


2.4

VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS .......................................................... 11

2.5

RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP ....................................... 12

2.6

OVERIGE ACTIVITEITEN WAAR DE SYSTEEMEIGENAAR EEN ROL BIJ SPELT .......................................................... 14

2.7

ALGEMENE UITGANGSPUNTEN M.B.T. BEHEER ............................................................................................................ 14

2.8

UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER....................................................................................................... 12

2.9

UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN ............................................................................................... 19



Page. 2 of 21




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






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.


Page. 3 of 21

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


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?


Page. 4 of 21

 Niet voor elk systeem.

2.2


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,


Page. 5 of 21



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.






Niet op papier. [Document] [Mondeling]

Zijn ze in gebruik? Ja, niet voor [Naam]. [Naam] wordt uitgefaseerd.


Page. 6 of 21

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? 


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. 

2.3

[Document]


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.


Page. 7 of 21

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. 




[Naam]



[Naam]



Soms [Naam]


Page. 8 of 21

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?


Page. 9 of 21

 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].


Page. 10 of 21

2.4


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.






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.


Page. 11 of 21

2.5


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?


Page. 12 of 21

 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.






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.


Page. 13 of 21

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


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.


Page. 14 of 21



Zijn er lagen uitbesteed?

 Ja,  

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.


Page. 15 of 21

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 BiSL1 

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



Page. 16 of 21

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?


Page. 17 of 21

 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.






Wat wordt er afgestemd?  Procesverandering. Bijv. pas kwijt, naar balie en betalen. Tegenwoordig bestellen en betalen met iDeal. Direct klant effect moet gecommuniceerd worden.


Page. 18 of 21

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


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









Vallen die onder de verantwoordelijkheid van ICTS?








Page. 19 of 21

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.






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.





Page. 20 of 21

 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.


Page. 21 of 21

INTERVIEW GAP-ANALYSE [Naam] [Naam] (HvA) [Naam] (UvA) [Naam] (HvA)

Auteurs

:


Versie

:

0.7

Datum

:

12-05-2014

Version management

Versie

Datum

Verstuurd naar

Doel

0.5

28-04-2014



0.6

29-04-2014



0.7

09-05-2014



Page. 1 of 18

Index Index .............................................................................................................................................................................................................2 1


2



2.2


2.3


2.4

VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS .............................................................9

2.5

RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP ..........................................9

2.6


2.7




Page. 2 of 18




Wie zijn wij?



Masterstudenten UvA






Wat doen we?












Doel van de analyse






Doel van dit interview



Inzicht verkrijgen over invulling van uitgangspunten voor [Naam] en haar informatievoorzieningen






Verzoeken tot opname interview








Page. 3 of 18


2.1



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?





Page. 4 of 18

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. 





2.2


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


Page. 5 of 18

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. 


[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.




[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.


Page. 6 of 18

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? 

2.3

[Document]



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.


Wordt er volgens BiSL gewerkt bij functionele wijzigingen in [Naam]?  Ik zou het niet weten, onbekend.



Bent u daar zelf direct bij betrokken?


Page. 7 of 18

 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).


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)


Page. 8 of 18

2.4


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? 



2.5

[Document]

Voor wie is dit toegankelijk?


Beoordelen op een schaal van 1 tot 10


Page. 9 of 18

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.


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.


Page. 10 of 18

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?  8 .

2.6





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




 7. 


 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.


Page. 11 of 18

2.7



Is het beheer van IS opgedeeld in de lagen: a. functioneel beheer

 Ja. 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





Is functioneel beheer intern belegd?


Page. 12 of 18

 Ja, bij ICTS Ingericht volgens BiSL1 

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



Page. 13 of 18

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?








Page. 14 of 18

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



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 







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.








Page. 15 of 18

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.


Page. 16 of 18

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?


Page. 17 of 18



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.


Page. 18 of 18

INTERVIEWS GAP-ANALYSE [Naam]

Auteurs

:


Versie

:

0.7

Datum

:

12-05-2014

Version management

Versie

Datum

Verstuurd naar

Doel

0.5

28-04-2014



0.6

29-04-2014



0.7

12-05-2014



Page. 1 of 15

Index Index .............................................................................................................................................................................................................2 1


2



2.2


2.3


2.4

VERANTWOORDELIJK VOOR DE COMMUNICATIE MET (EIND)GEBRUIKERS .............................................................8

2.5

RANDVOORWAARDEN VOOR EEN GOEDE INVULLING VAN SYSTEEMEIGENAARSCHAP ..........................................8

2.6


2.7


2.8

UITGANGSPUNTEN M.B.T. FUNCTIONEEL BEHEER....................................................................................................... 11

2.9

UITGANGSPUNTEN M.B.T. DE ANDERE BEHEERLAGEN ............................................................................................... 13



Page. 2 of 15








Wie zijn wij? o

Masterstudenten UvA

o


Wat doen we? o


o


o


Doel van de analyse o





Doel van dit interview o

Inzicht verkrijgen over invulling van uitgangspunten voor [Naam] en haar informatievoorzieningen

o


Verzoeken tot opname interview o







Page. 3 of 15


2.1



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.




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]


Page. 4 of 15







2.2


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.


Page. 5 of 15

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]


[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



Wie zit er op het tactisch niveau van de gebruikersorganisatie?


Page. 6 of 15

 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.


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.


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.


Page. 7 of 15

2.4


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


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.


Page. 8 of 15



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.


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.




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?


Page. 9 of 15

 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





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




 Het is er volgens mij wel, maar ik zit daar niet in. 


 Nee. Betrokkenheid contracten en SLA’s

2.7



Bent u zelf betrokken bij het opstellen van de contracten en SLA’s tussen ICTS en externe leveranciers?



Nee.



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?


Page. 10 of 15

 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.



2.8

Zo ja, in hoeverre bent u daar verantwoordelijk voor?





Is functioneel beheer voor uw IS geoutsourcet?

 Nee, dat zit intern. Ingericht volgens BiSL1 

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



Page. 11 of 15



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?


Page. 12 of 15

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.




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



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.


Page. 13 of 15



Wie is er verantwoordelijk voor?  Weet ik ook niet.



Vallen die onder de verantwoordelijkheid van ICTS?  Weet ik niet.







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.






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?


Page. 14 of 15

 Weet ik niet. 


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.’


Page. 15 of 15

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 [email protected]

T.M. van Bremen

University Supervisor Dhr. drs. A.W. Abcouwer University of Amsterdam


Case Supervisor Mw. S.W. Nolst Trenité University of Amsterdam

August 2014

Content

T.M. van Bremen


August 2014

Case study introduction

 Case study introduction

 Internship

 Problem statement

 Universiteit van Amsterdam

 Research question

 Hogeschool van Amsterdam

 Theoretical background

 April-July 2014

 Method

 Together with Bart van Eck

 Results  Change management  Discussion

There and back again – Summer 2014 T.M. van Bremen


August 2014


T.M. van Bremen


August 2014

Case study introduction  But both business and IT governance are poorly understood. IT governance just happens in

 Three shared service departments

many enterprises. IT governance is not actively designed to achieve business objectives and

 Administrative services

desirable behaviors.

 Facility services

 Effective IT governance arrangements thoughtfully and purposefully combine decision

 ICT services

making about major IT domains, by the right group of people, using appropriate mechanisms. 

T.M. van Bremen



August 2014

T.M. van Bremen

“Verbetertraject” (2013-2014)


August 2014




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


August 2014

Problem statement

T.M. van Bremen


Problem statement

 A lot of information systems

 A lot of information systems

 Management is poorly done

 Management is poorly done

1. Implement requirements

1. Implement requirements

2. Fulfill requirements

2. Fulfill requirements

3. Profit.

3. Profit

T.M. van Bremen


August 2014

August 2014

Research question

T.M. van Bremen


August 2014

Theoretical background

To what extent do the information provision services at the collaborating services of the two institutes fit the newly stated requirements?

 “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)

 (Compare the current situation with the optimal situation where all requirements are met)

 “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



August 2014

T.M. van Bremen


August 2014




Method

 Centralization of decision rights

 Fit-gap analysis

 May lead to increased organization efficiency (Bester, 2009)

 Evaluate business processes achieving a specific goal  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

T.M. van Bremen


August 2014

Method

 Steps: 1. 2. 3.

Identifying current performance Identifying desired performance and gap Addressing the gap

T.M. van Bremen


August 2014

Method

 Investigated 17 information systems

 Discuss every requirement with system owners

 15 Interviews

 Translate requirements to interview questions:

 7 System owners  4 Business process managers  1 Team coordinator

T.M. van Bremen


August 2014

Method

T.M. van Bremen


August 2014

Method  Quality assessment of every requirement for every system

 Discuss every requirement with system owners

 Required documents (proof)

 Translate requirements to interview questions:

 Self-assessment  General consensus of knowledge derived from answer

T.M. van Bremen



August 2014

T.M. van Bremen


August 2014



Method

Results

 Documenting results

T.M. van Bremen


August 2014

Results

T.M. van Bremen


August 2014

Research question

To what degree do the requirements improve change management?

T.M. van Bremen


August 2014


T.M. van Bremen


August 2014


 “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.

 Finding some common ground on competences: Rank Skill 1

Interviewing

2

Directing

3

Managing

4

Speaking

5

Listening

Description Asking the right questions in order to obtain the information needed. Giving instructions and communicating user requirements to programming and support staff. Planning, organizing and controlling projects. 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.

(Jiang et al., 1998)

T.M. van Bremen



August 2014

T.M. van Bremen


August 2014




Conclusion

 Taxonomy of assessment scales for technochange managers (Harison & Boonstra, 2009) Competence

Description

Information technology and information systems (IS/IT) know-how Organizational Change

Actual knowledge of the IS/IT field and experience in IS/IT projects in leading and responsible positions

Technochange Risk and success factors Communication Process management Leadership

Consequences of change

T.M. van Bremen

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


August 2014

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


August 2014

Conclusion

 Aided in raising awareness of the implementations

 Change management  The requirements did not overlap much with the behavioral competence taxonomy derived

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.”

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


August 2014

T.M. van Bremen


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.

T.M. van Bremen



Questions August 2014

T.M. van Bremen


August 2014



Extra: Validity

Extra: HvA

 Limitations of this study:  Doubts about the nature of numerical measurements  The self-assessment methods used for some requirements

 The reliability of this study was estimated as relatively high, mainly due to a strict approach towards the interview procedure.

T.M. van Bremen


August 2014

Extra: UvA

T.M. van Bremen


August 2014

Extra: Results


Extra: Coding


T.M. van Bremen

August 2014

T.M. van Bremen


August 2014

Extra: Requirements



Extra: Requirements

Extra: Requirements

Extra: Requirements



IT Governance at Higher Education Institutes in Amsterdam

Recommend Documents