User types in IDAC
As part of the development of IDAC, we defined five user types that the new system will be able to manage. These are employee, affiliate, doctoral student, student and external/support.
IDAC will be able to manage five different types of users.
- Employee: The person must have a current employment contract with KI.
- Affiliate: The person must have a current affiliation agreement. An affiliate can be an individual or a person who is part of an organisation (company).
- Doctoral student: The person must have been admitted to, and be active in, third-cycle study courses and programmes with KI as a higher education institution. The doctoral student must have a special connection with KI. This entails: an individual study plan for third-cycle studies; research work within KI; and, the doctoral student being either an employee or an affiliate. There is thus a distinction between a doctoral student and other people, employees or affiliates who also study.
- Student: The person must have been admitted to, and be active in, first or second-cycle study courses and programmes with KI as a higher education institution.
- External/support: To fall within the external/support user type, the person must be part of an organisation (company) that has a current agreement/contract recognised by KI.
How were the definitions and terms developed?
Our development of new terms and definitions is based on five guiding principles.
- Security: Security consciousness (as regards both information security and connecting the right person to a KI ID) is our basic premise and has to permeate all our work. Supplementing as an afterthought must not occur.
- Traceability: Decisions and changes must be documented in IDAC.
- Easy to get it right: The standard process follows the current regulations. Deviating from these would require conscious decisions that would also have to be documented.
- Information quality: Information in the system must be correct. This is ensured by the information being saved in only one place (in a so-called “source system”).
- Operational benefit: Further development of, and changes in, the system must always be based on an operational need.
Why are there such strict rules and definitions?
One of the major challenges and problems with KIMKAT has been that there were no uniform rules and definitions regarding which employee and user types there are to be at KI. There are two main reasons why KI needs a university-wide definition of user types.
- Only if everyone uses the same terms and means the same thing when using an individual term can we ensure that KI’s guidelines and rules are being complied with.
- One of the most important reasons for replacing KIMKAT is simplifying and automating the processes when anyone starts, ends or changes their activity at KI. As computer programs and systems are built on ones and zeros, we need university-wide terms so that our system can manage and automate the information flow.