Upload
voliem
View
213
Download
0
Embed Size (px)
Citation preview
Sollspezifikation Projekt
der WIRTSCHAFTSUNIVERSITÄT WIEN
K:\WU-WIEN\SOLLSPEZ\BERICHT8.DOC
Kommentar: Adaptierungsar-beiten unter Word 6.0: Überschriften neu numerieren Nach Einfügung von Querver-weisen unter Word 97: Feld-funktionen anzeigen, alle „\n“ auf „ \n \h“ ändern. Bei Bedarf Inhaltsverzeichnis neu erstellen. Adaptierung unter Word 97: Alle ” auf ” ändern (damit wer-den deutsche Anführungszei-chen verwendet).
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 163
INHALTSVERZEICHNIS
1 EINLEITUNG.........................................................................................................................7
1.1 Auftrag .................................................................................................................................7
1.2 Warenzeichen .....................................................................................................................7
1.3 Redaktionelle Behandlung der Geschlechtlichkeit ..............................................................7
2 PROJEKTDURCHFÜHRUNG .............................................................................................9
2.1 Ziele des Projekts ................................................................................................................9
2.2 Projektpartner....................................................................................................................11
2.3 Projektorganisation............................................................................................................12 2.3.1 Lenkungsausschuß......................................................................................................14
2.3.2 Kernteam ......................................................................................................................14
2.4 Projektablauf......................................................................................................................15 2.4.1 Sitzungen des Kernteams............................................................................................15 2.4.2 Sitzungen des Lenkungsausschusses ........................................................................15
2.4.3 Einbezogene Organisationseinheiten...........................................................................15 2.4.3.1 Einbezogene Institute/Abteilungen .........................................................................15 2.4.3.2 Einbezogene Verwaltungsstellen und sonstige Stellen.........................................16 2.4.3.3 Übersicht über die Interview - und Abstimmungstermine.......................................16
2.4.4 Präsentationen und Workshops...................................................................................19 2.4.5 Plakataktion...................................................................................................................20
3 METHODIK UND VORGEHEN..........................................................................................21
3.1 Die Phasen der Konzeption ..............................................................................................21
3.2 Architektur integrierter Informationssysteme....................................................................23
3.2.1 Hintergrund und Idee.....................................................................................................24 3.2.2 Die ARIS-Ebenen..........................................................................................................25 3.2.3 Die ARIS-Sichten ..........................................................................................................26
3.3 Grundsätze ordnungsmäßiger Modellierung.....................................................................33
3.4 Projekt-/Modellierungskonventionen ..................................................................................36
3.4.1 Verwendung aufbauorganisatorischer Elemente.........................................................36 3.4.2 Aufbau der Modellhierarchie .........................................................................................36
3.4.2.1 Ablaufbeschreibung versus Funktionalitätsbeschreibung .....................................36 3.4.2.2 Bildung von Szenarien ...........................................................................................37
INHALTSVERZEICHNIS
Seite 4 von 163 Erstellt gemeinsam m it 15. April 1998
3.4.2.3 Integration von Daten und Funktionalitäten............................................................37 3.4.3 Detaillierungsgrad.........................................................................................................37
3.4.3.1 Datenmodelle.........................................................................................................37 3.4.3.2 Prozeßmodelle .......................................................................................................37
3.4.4 Übersicht der Methodenverwendung ............................................................................38
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ ............................................43
4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung ...............................43 4.1.1 Übersicht.......................................................................................................................45 4.1.2 Studien..........................................................................................................................47
4.1.2.1 Zulassung Studium ................................................................................................48 4.1.2.2 Rückmeldung Studium...........................................................................................51 4.1.2.3 Zusatzstudium/Wechsel des Studiums.................................................................53 4.1.2.4 Beendigung Studium ..............................................................................................54 4.1.2.5 Erstellung Diplomzeugnis ......................................................................................56
4.1.3 Lehrveranstaltungen.....................................................................................................57 4.1.3.1 Planung von Lehrveranstaltungen..........................................................................58 4.1.3.2 Aufnahme von Lehrveranstaltungen ......................................................................62 4.1.3.3 Lehrveranstaltungen administrieren.......................................................................64
4.1.4 Prüfungen .....................................................................................................................65 4.1.4.1 Planung von Prüfungen..........................................................................................66 4.1.4.2 Leistungsfeststellung .............................................................................................68
4.1.5 Diplomarbeiten/Dissertationen .....................................................................................71 4.1.5.1 Diplomarbeiten/Dissertationen vereinbaren...........................................................73 4.1.5.2 Diplomarbeiten/Dissertationen betreuen ...............................................................74 4.1.5.3 Diplomarbeiten/Dissertationen abschließen ..........................................................75
4.1.6 An- und Abmeldungen ..................................................................................................75 4.1.6.1 LV-Anmeldungen ....................................................................................................76 4.1.6.2 Prüfungsanmeldungen ...........................................................................................78 4.1.6.3 Abmeldungen .........................................................................................................80
4.1.7 Anerkennungen .............................................................................................................82 4.1.7.1 Anerkennungen erzielen.........................................................................................83 4.1.7.2 Nostrifikationen erzielen.........................................................................................85
4.1.8 Abrechnungen...............................................................................................................86
4.1.9 Evaluierung der Lehre...................................................................................................87 4.1.9.1 Beurteilung von Lehrveranstaltungen.....................................................................89 4.1.9.2 Arbeitsberichte erstellen.........................................................................................90
4.1.10 Allgemeine Funktionen................................................................................................91 4.1.10.1 Chipkartenverwaltung...........................................................................................91 4.1.10.2 Hörsaaladministration ..........................................................................................93 4.1.10.3 Stammdatenverwaltung.......................................................................................93
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 163
4.1.10.4 Auswertungen/Ausdrucke....................................................................................94 4.1.11 Allgemeine Systemfunktionen – Grundfunktionalitäten ..............................................95
4.2 Anregungen der verschiedenen Organisationseinheiten..................................................98 4.2.1 Studien- und Prüfungsabteilung ...................................................................................98
4.2.2 Institute/Abteilungen......................................................................................................99 4.2.3 Studiendekanat...........................................................................................................106
4.3 Konzeptionelles Datenschema.......................................................................................108 4.3.1 Intention.......................................................................................................................108
4.3.2 Semantische Datenmodelle .......................................................................................108 4.3.2.1 Studium ................................................................................................................109 4.3.2.2 Studienplan...........................................................................................................111 4.3.2.3 Lehrveranstaltung.................................................................................................113 4.3.2.4 Vorlesungsverzeichnis .........................................................................................114 4.3.2.5 Prüfungen.............................................................................................................114 4.3.2.6 An- und Abmeldung..............................................................................................116 4.3.2.7 Diplomarbeiten und Dissertationen......................................................................117 4.3.2.8 Anerkennung ........................................................................................................118 4.3.2.9 Abrechnung..........................................................................................................119 4.3.2.10 Hörsaalverwaltung..............................................................................................120 4.3.2.11 Evaluierung.........................................................................................................121 4.3.2.12 Adresse ..............................................................................................................122
5 MENGEN- UND WERTGERÜST .....................................................................................123
6 DATENSCHUTZ UND DATENSICHERHEIT ..................................................................125
6.1 Schutzbedarfsermittlung.................................................................................................125 6.1.1 Schutzstufenkonzept..................................................................................................125
6.1.1.1 Stufe I ...................................................................................................................125 6.1.1.2 Stufe II...................................................................................................................126
6.1.2 Schutzbedarf im Projekt „2gether“ .............................................................................127
6.2 Chipkarten .......................................................................................................................129
6.3 Internet.............................................................................................................................132
7 MIGRATIONSKONZEPT ..................................................................................................135
7.1 Allgemeines .....................................................................................................................135
7.2 Ablöse STEPDB und INSTDB.........................................................................................136 7.2.1 Datenübernahme........................................................................................................136 7.2.2 Anmerkungen zur Synchronisation von Datenbanken ...............................................136
7.3 Zeitlicher Aspekt ..............................................................................................................137
7.4 Schnittstellen...................................................................................................................138
INHALTSVERZEICHNIS
Seite 6 von 163 Erstellt gemeinsam m it 15. April 1998
7.4.1 Vorlesungsverzeichnis ...............................................................................................138 7.4.2 Hörsaalbelegung.........................................................................................................139
7.5 Übergangszeitraum.........................................................................................................139 7.5.1 Historische Daten der Studenten ...............................................................................139
7.5.2 Selbstbedienungsfunktionen.......................................................................................140
7.6 Zeitlicher Ablauf...............................................................................................................140 7.6.1 Datenüberleitung.........................................................................................................142 7.6.2 Stammdatenerfassung ...............................................................................................142
7.6.3 Phase 1.......................................................................................................................142 7.6.4 Weitere Phasen..........................................................................................................143
7.7 Zuordnungen alte/neue Datenbank .................................................................................143
8 WIRTSCHAFTLICHKEITSBETRACHTUNG ..................................................................149
8.1 Anmerkungen zum Nutzen des neuen Systems............................................................149 8.1.1 Qualitative Verbesserungen .......................................................................................150 8.1.2 Quantitativ meßbare Verbesserungen .......................................................................151
8.1.2.1 Studien- und Prüfungsabteilung...........................................................................152 8.1.2.2 Institute/Abteilungen .............................................................................................154
8.2 Kosten-/Nutzenrechnung ................................................................................................159
Anhang A: Verzeichnisse
Anhang B: Datenfelder
Anhang C: ARIS-Datenbank/Modell-Liste
Anhang D: ARIS-Datenbank/wichtigste Modelle
Anhang E: ARIS-Datenbank/Auswertungen
Anhang F: Wirtschaftlichkeitsbetrachtungen (ZID)
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 163
1 EINLEITUNG
1.1 Auftrag
Am 27. November 1997 erteilte das
Zentrum für Informatikdienste der Wirtschaftsuniversität Wien
im Auftrag der Vergabekommission der
Secur-Data Betriebsberatungsgesellschaft
gemäß deren Angebot vom 30. Oktober 1997 den Zuschlag für die im offenen Verfahren (in der öffentlichen Ausschreibung) ZID/SW1/97 enthaltenen Leistungen mit der Auflage, eine herstellerneutrale Sollspezifikation zu erstellen.
Gemäß deren Angebot vom 4. Februar 1998 wurde die Secur-Data beauftragt, über den vereinbar ten Projektumfang hinaus 6 weitere Institute bzw. Abteilungen sowie verstärkt das Zentrum für Auslandsstudien und die Hochschülerschaft in das Projekt einzubinden; gleichzeitig wurde die Secur-Data verpflichtet, insgesamt 4 Workshops zu veranstalten, an denen die Projektergebnisse vorgestellt und diskutiert werden konnten.
Beide Aufträge wurden am 15. April 1998 mit Übergabe des vorliegenden Sollkonzepts abgeschlossen. Die Abnahme durch den Lenkungsausschuß ist für den 30. April 1998 vorgesehen.
1.2 Warenzeichen
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenzeichen u.s.w. in die-sem Dokument berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, daß solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären.
1.3 Redaktionelle Behandlung der Geschlechtlichkeit
Aus Gründen der Vereinfachung und damit zur Verbesserung der Lesbarkeit des Textes wurde an den Stellen, an denen von Personen die Rede ist, teilweise auf die explizite Nennung beider Geschlechter verzichtet. Wenn also beispielsweise von Mitarbeitern gesprochen wird, sind damit Mitarbeiter beiderlei Geschlechts gemeint. Es soll somit in
1 EINLEITUNG 1.3 Redaktionelle Behandlung der Geschlechtlichkeit
Seite 8 von 163 Erstellt gemeinsam m it 15. April 1998
keinem Fall der Gleichbehandlungsgrundsatz, so wie er im UOG ’93 oder auch in der Satzung der Wirtschaftsuniversität Wien (WU Wien) formuliert wird, untergraben wer-den.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 9 von 163
2 PROJEKTDURCHFÜHRUNG
2.1 Ziele des Projekts
Ziel des Projekts war die Erstellung einer detaillierten Sollspezifikation auf Basis des Grobkonzepts, das unter Federführung des Zentrums für Informatikdienste der Wirt-schaftsuniversität Wien erstellt wurde.
Die Sollspezifikation soll der WU einerseits Entscheidungsgrundlagen über eine schritt-weise Implementierung des Systems liefern, andererseits als Leistungsverzeic hnis für eine weitere Ausschreibung betreffend Entwicklung und Implementierung des neuen Systems verwendet werden.
Bei der fachlichen Konzeption des Systems „2gether“ zur Unterstützung der Studien- und Prüfungsverwaltung wurde größtmögliches Gewicht auf die Offenheit und Transpa-renz aller Projektschritte sowie die Einbeziehung möglichst vieler WU-Mitarbeiter gelegt. Dies liegt zum einen in dem besonderen Aufbau einer Universität mit ihrer eher netz-werkartigen Struktur und zum anderen in den Vorbehalten der Mitarbeiter begründet, die zum Teil aus vorherigen, anderen Projekten stammen.
Daher ist es eine wesentliche Aufgabe des Projektteams gewesen, Verständnis für bzw. Klarheit über das zu erwartende neue System letztlich bei allen WU-Mitarbeitern zu erreichen. Die große Zahl an Interviews, respektive Interviewpartnern, ist ein Indiz hierfür.
Schließlich münden die unterschiedlichen, teilweise diametral gegenüberstehenden An-forderungen der Interviewpartner und Workshopteilnehmer in dem in den Bericht integ-rierten Anforderungskatalog.
Die bei der Wirtschaftsuniversität Wien vorgefundene Ausgangssituation sowie das vom „2gether“-Projekt erwartete Verbesserungspotential ist in Abbildung 1 festgehalten.
2 PROJEKTDURCHFÜHRUNG 2.1 Ziele des Projekts
Seite 10 von 163 Erstellt gemeinsam m it 15. April 1998
heterogeneDV-Landschaft
redundanteDatenhaltung
mangelndeAuswertungs-möglichkeiten
unnötigeMedien- und
Ablaufbrüche
einheitliches,homogenesDV-System
optimaleAuswertungs-möglichkeiten
keineMehrfach-
Datenerfassung
integrierte,redundanzfreie
Datenbasis
AusgangssituationAusgangssituation ProjektverbesserungenProjektverbesserungen
tlw. veralteteSysteme/Jahr 2000
Gesetzes-änderungen
erhöhter Infor-mationsfluß
Abbildung 1: Ist-Situation und Ziele des Projektes „2gether“
Des weiteren waren folgende Aspekte des Studien- und Prüfungsverwaltung zu berück-sichtigen:
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 11 von 163
Institute Studien- und Prüfungsabteilung Quästur
Rechts- undOrganisations-
abteilungStudenten
PowerPhone/PowerCard/WWW
WU - FIS
Studiendekanat
Studenten/Zulassung
Studien-plan
Lehrveran-staltungen
Vorlesungs-verzeichnis
An- undAbmeldung
Hörsaal-verwaltung
Evaluierungder Lehre
Prüfungs-verwaltung
Diplom-arbeiten/Dis-sertationen
Anerken-nungen
Abrech-nung
Studien- und Prüfungs-verwaltungssystem
Abbildung 2: Aspekte der Studien- und Prüfungsverwaltung in „2gether“
2.2 Projektpartner
Die Durchführung des Projekts wurde der Firma Secur -Data Betriebsberatungsgesell-schaft m.b.H. übertragen, die vornehmlich ihre (auf die Abwicklung komplexer IT -Projekte bezogene) Management-Kompetenz einbrachte, sich jedoch der Modellie-rungskompetenz des ARIS-Herstellers IDS Prof. Scheer GmbH bediente, der als Sub-unternehmen beigezogen wurde. Der vorliegende Bericht ist das Produkt dieser engen Partnerschaft sowie der engen Zusammenarbeit mit allen involvierten Stellen der Wirt-schaftsuniversität, für deren engagiertes Mitwirken wir an dieser Stelle herzlichen Dank sagen wollen.
2 PROJEKTDURCHFÜHRUNG 2.3 Projektorganisation
Seite 12 von 163 Erstellt gemeinsam m it 15. April 1998
Abbildung 3: Partner im Projekt „2gether“
2.3 Projektorganisation
Die Aufbauorganisation des Projekts ist in Abbildung 4 dargestellt.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 13 von 163
o.Univ.Prof. Dr. F. Scheuch, Vizerektor(o.Univ.Prof. Dr. H.-R. Hansen, Rektor)o.Univ.Prof. Dr. W. Janko, Angewandte InformatikDr. T. Herzog, UniversitätsdirektorP. Hysek, ÖH WU-WienMag. C. Ragacs, Kommission für InfrastrukturR. Pieler, DienststellenausschußDr. G. Miksch, ZIDH.-J. Pollirer, Secur-Data
Projektlenkungsausschuß
Arbeitsgruppe n
Kernteam
IDS/Secur-DataWU-Mitarbeiter
UniversitätsverwaltungStudiendekanateInstitute/AbteilungenÖH
Arbeitsgruppe 1
IDS/Secur-DataWU-Mitarbeiter
Dr. Georg Miksch, WU-ZIDMag. Martina Lenk, WU-ZIDEugen Klein, Projektleiter, Secur-Data
fallweise:Ralf Heib, IDS ProjektkoordinatorClaus Hüsselmann, IDSMarkus Kopp, IDSMarkus G. Herb, IDSHerbert Wotzel, Secur-Data
Abbildung 4: Projektaufbauorganisation
2 PROJEKTDURCHFÜHRUNG 2.3 Projektorganisation
Seite 14 von 163 Erstellt gemeinsam m it 15. April 1998
2.3.1 Lenkungsausschuß
Als oberstes Entscheidungsgremium wurde ein Lenkungsausschuß gebildet, der sich wie folgt zusammensetzte:
• Herr Prof. Dr. F. Scheuch (Vizerektor), der später von Prof. Dr. H. -R. Han-sen (Rektor) abgelöst wurde;
• Herr Dr. T. Herzog (Universitätsdirektor);
• Herr Prof. Dr. W. Janko (Studienkommission BWL);
• Frau R. Pieler (Dienststellenausschuß);
• Herr Mag. C. Ragacs (Kommission für Infrastruktur);
• Herr P. Hysek (Vorsitzender der Hochschülerschaft);
• Herr Dr. G. Miksch (Leiter ZID);
• Herr H.-J. Pollirer (GF der Secur-Data);
• Herr Dipl.-Kfm. R. Heib (IDS Projektkoordinator);
• Herr E. Klein (Projektleiter).
2.3.2 Kernteam
Zur Koordination der laufenden Arbeiten wurde das Kernteam eingesetzt, dem folgender Personenkreis angehörte:
• Herr Dr. G. Miksch (Leiter ZID),
• Frau Mag. M. Lenk (ZID Projektkoordinatorin),
• Herr E. Klein (Secur-Data Projektleiter)
sowie fallweise
• Herr Dipl.-Kfm. R. Heib (IDS Projektkoordinator),
• Herr M. Kopp (IDS),
• Herr M. Herb (IDS),
• Herr C. Hüsselmann (IDS),
• Herr H. Wotzel (Secur-Data).
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 15 von 163
2.4 Projektablauf
2.4.1 Sitzungen des Kernteams
Das Kick-off-Meeting des Kernteams fand am 18. November 1997 statt. In weiterer Fol-ge wurden insgesamt 13 Sitzungen des Kernteams mit wechselnder Beteiligung ab-gehalten.
2.4.2 Sitzungen des Lenkungsausschusses
Der Lenkungsausschuß trat am 1. Dezember 1997 zu seiner konstituierenden Sitzung zusammen. Weitere Sitzungen folgten:
• 2. Sitzung am 30. Jänner 1998;
• 3. Sitzung am 5. März 1998;
• 4. Sitzung am 30. März 1998.
Nach Abgabe des vorliegenden Sollkonzepts am 15. April 1998 wird der Lenkungsauss-chuß zu seiner 5. und letzten Sitzung am 30. April 1998 zusammentreten.
2.4.3 Einbezogene Organisationseinheiten
2.4.3.1 Einbezogene Institute/Abteilungen
Im Rahmen der 1. Sitzung des Lenkungsausschusses am 1. Dezember 1997 wurden folgende Institute bzw. Abteilungen als Interviewpartner ausgewählt:
• Romanische Sprachen
• Bürgerliches Recht
• Warenhandel
• Wirtschaftsinformatik
Im Rahmen der 2. Sitzung des Lenkungsausschusses am 30. Jänner 1998 wurde be-schlossen, 6 weitere Institute bzw. Abteilungen in die Erhebungs- bzw. Abstimmungs-gespräche einzubeziehen. Folgende Institute bzw. Abteilungen wurden ausgewählt:
• Englische Sprache/Wirtschaftssprache
• Finanzierung & Finanzmärkte
• Betriebswirtschaftliche Steuerlehre
2 PROJEKTDURCHFÜHRUNG 2.4 Projektablauf
Seite 16 von 163 Erstellt gemeinsam m it 15. April 1998
• Wirtschafts- & Sozialgeschichte
• Personalwirtschaft
• Politische Ökonomie
Die Auswahl der beteiligten Institute und Abteilungen erfolgte seitens der WU und wurde nach dem Zufallsprinzip vorgenommen. Dabei wurden zunächst Größenklassen anhand des administrativen Aufwandes der jeweiligen Bereiche gebildet; innerhalb dieser Grö-ßenklassen wurden zufällige Einheiten ermittelt, die – nach deren Zustimmung – in den Untersuchungsbereich aufgenommen wurden.
2.4.3.2 Einbezogene Verwaltungsstellen und sonstige Stellen
Neben den genannten Instituten bzw. Abteilungen war geplant, folgende Verwaltungs- bzw. übrige Stellen einzubeziehen:
• Studien- und Prüfungsabteilung
• Zentrum für Informatikdienste
• Büro der Studiendekane
• Quästur
• Rechts- und Organisationsabteilung
Im Rahmen der 2. Sitzung des Lenkungsausschusses am 30. Jänner 1998 wurde be-schlossen, 2 weitere Verwaltungs- bzw. sonstige Stellen verstärkt einzubeziehen:
• Hochschülerschaft
• Zentrum für Auslandsstudien
2.4.3.3 Übersicht über die Interview- und Abstimmungstermine
Im Rahmen der Projektdurchführung wurden folgende Interview- und Abstimmungster-mine wahrgenommen:
Datum Stelle Interviewpartner
26.11.1997 Romanische Sprachen I. Hubmann, E. Lavric, N. Riehs
3.12.1997 Wirtschaftsinformatik M. Fritscher, C. Drimmel, O. Kump
3.12.1997 Wirtschaftsinformatik A. Schüller, M. Kaukal
3.12.1997 Wirtschaftsinformatik R. Flatscher, R. Brandtweiner
3.12.1997 Wirtschaftsinformatik M. Fritscher
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 17 von 163
Datum Stelle Interviewpartner
4.12.1997 Wirtschaftsinformatik A. Schuster
4.12.1997 Wirtschaftsinformatik A. Scharl
4.12.1997 ZID R. Barthauer, J. Langitz
4.12.1997 Wirtschaftsinformatik O. Kump, C. Ragacs
9.12.1997 Warenhandel T. Reutterer
9.12.1997 Romanische Sprachen I. Hubmann, E. Lavric, N. Riehs
9.12.1997 Wirtschaftsinformatik R. Flatscher
10.12.1997 Wirtschaftsinformatik O. Kump
10.12.1997 Wirtschaftsinformatik Prof. Hansen
11.12.1997 Warenhandel H. Kotzab, B. Gasner
12.12.1997 ZID C. Kaiser
12.12.1997 Bürgerliches Recht W. Blocher
16.12.1997 STAB W. Axterer, H. Spitzer, M. De Pellegrin
17.12.1997 Büro d. Studiendekane G. Zihr
17.12.1997 STAB W. Axterer, H. Spitzer, temporär verschiedene Mitarbeiter
18.12.1997 STAB W. Axterer, M. De Pellegrin
18.12.1997 Büro d. Studiendekane G. Zihr
8.1.1998 Warenhandel H. Kotzab
12.1.1998 Bürgerliches Recht W. Martetschläger
13.1.1998 ÖH P. Hysek
14.1.1998 Büro d. Studiendekane H. Gabler, Prof P. Hackl (tw.), G. Sedlacek
27.1.1998 Quästur G. Krotky
28.1.1998 Zentrum für Auslands-studien
F. Brück, T. Friedlmayer
29.1.1998 ÖH S. Schmidt
22.1.1998 ZID J. Loibl
10.2.1998 Rechts- und Organisati-onsabteilung
G. Mautner
11.2.1998 ZID J. Loibl
24.2.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer
26.2.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer
2 PROJEKTDURCHFÜHRUNG 2.4 Projektablauf
Seite 18 von 163 Erstellt gemeinsam m it 15. April 1998
Datum Stelle Interviewpartner
3.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer
4.3.1998 Quästur; Rechts- und Organisationsabteilung
G. Krotky; G. Mautner
4.3.1998 Rechts- und Organisati-onsabteilung
D. Pouha
4.3.1998 Bürgerliches Recht W. Martetschläger
5.3.1998 Warenhandel H. Kotzab
5.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer
10.3.1998 ÖH Hysek
10.3.1998 Englische Sprache Prof. W. Obenaus, D. Schleihs
10.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer
10.3.1998 Politische Ökonomie H. Klausinger
12.3.1998 Wirtschafts- und Soz ial-geschichte
G. Senft
12.3.1998 Romanische Sprachen E. Lavric, N. Riehs, I. Hubmann
12.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer
16.3.1998 ZID B. Sommer
17.3.1998 Studiendekanat G. Zihr
17.3.1998 Studiendekanat G. Sedlacek
17.3.1998 Dienststellenausschuß R. Pieler
18.3.1998 Personalwirtschaft G. Lueger
18.3.1998 Betriebswirtschaftliche Steuerlehre
F. Hörmann
18.3.1998 Wirtschaftsinformatik O. Kump, A. Schuster
18.3.1998 Wirtschaftsinformatik R. G. Flatscher, M. Kaukal, R. Klimesch
18.3.1998 Wirtschaftsinformatik S. Feregyhazy, C. Drimmel
18.3.1998 Wirtschaftsinformatik M. Fritscher
19.3.1998 Wirtschafts- und Soz ial-geschichte
G. Senft, S. Wolf, B. Bauer, R. Lackner, H. Hemetsber-ger-Koller
19.3.1998 Bürgerliches Recht W. Blocher, W. Martetschläger
24.3.1998 Warenhandel H. Kotzab, B. Gasner
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 19 von 163
Datum Stelle Interviewpartner
24.3.1998 Personalwirtschaft Prof. D. Eckardstein, H. Mayerhofer, G. Riedl , G. Lueger u. a.
24.3.1998 Romanische Sprachen E. Lavric, N. Riehs, I. Hubmann
24.3.1998 Finanzierung und Fi-nanzmärkte
S. Schmidt, H. Pichler, P. Hysek
25.3.1998 Betriebswirtschafltiche Steuerlehre
F. Hörmann
25.3.1998 ZAS A. M. Schator, K. Zollner
25.3.1998 Studiendekanat H. Haller
26.3.1998 Politische Ökonomie Prof. J. H. Pichler, C. Ragacs, S. Holzweber, H. Klausin-ger
26.3.1998 Englische Sprache Prof. W. Obenaus, R. Markwitz, K. Wenschitz, D. Schleihs
1.4.1998 Wirtschaftsinformatik O. Kump, A. Schuster
1.4.1998 Personalwirtschaft Prof. D. Eckardstein, H. Mayerhofer, G. Riedl
1.4.1998 ADV-Abteilung R. Barthauer
2.4.1998 STAB H. Spitzer, Svaljug, Szalay
2.4.1998 STAB H. Spitzer, Nagy, Vario
2.4.1998 Finanzierung; ÖH S. Schmidt, P. Hysek
7.4.1998 ADV-Abteilung R. Barthauer
8.4.1998 ZID G. Miksch
Tabelle 1: Interviews und Abstimmungsgespräche
2.4.4 Präsentationen und Workshops
Am 11. Dezember 1997 wurde eine Präsentation des Projektes durchgeführt, zu der al-le Mitarbeiter eingeladen waren. An der Veranstaltung nahmen ca. 40 – 50 Mitarbeiter teil.
Im Rahmen der 2. Sitzung des Lenkungsausschusses am 30. Jänner 1998 wurde be-schlossen, vier Workshops durchzuführen, zu denen alle Mitarbeiter eingeladen waren, und an denen die Ergebnisse des Projekts vorgestellt und diskutiert werden konnten. Die Workshops fanden an folgenden Terminen mit folgender Beteiligung statt:
2 PROJEKTDURCHFÜHRUNG 2.4 Projektablauf
Seite 20 von 163 Erstellt gemeinsam m it 15. April 1998
Datum Stelle Interviewpartner
30.3.1998 Gewerbe, Klein- und Mittelbetriebe B. Mahel
30.3.1998 Arbeit und Sozialrecht C. Münster
30.3.1998 Angewandte Informatik R. Franz
30.3.1998 Rektorat: Forschungsservice B. Moravec
30.3.1998 Finanzwissenschaft S. Brunner
30.3.1998 Verfassungs- und Verwaltungsrecht H. Beclin
31.3.1998 Industrielle Informationsverarbeitung A. Prosser
31.3.1998 Genossenschaftswesen; Studiendekanat G. Zihr
31.3.1998 Angewandte Informatik; Wirtschaftsstatistik; Studiendekanat
G. Sedlacek
31.3.1998 Studiendekanat H. Gabler
31.3.1998 Rechts- und Organisationsabteilung G. Mautner, D. Pouha, A. Melcsok, H. Gelegs
1.4.1998 Raumordnung G. Maier
1.4.1998 Außenhandel Y. Fuchs
1.4.1998 Organisation und Materialwirtschaft E. Chwosta
2.4.1998 Finanzrecht M. Zueger
2.4.1998 FBK Rechtswissenschaft I. Berger
2.4.1998 Tourismus G. Ullrich
Tabelle 2: Workshops – Termine und Teilnehmer
2.4.5 Plakataktion
Die noch nicht vollständig abgestimmten Ergebnisse mit Stand 13. März 1998 wurden auf DIN A0-Plakaten ausgedruckt und ab dem 24. März 1998 auf der Galerie vor dem Rektorat öffentlich ausgestellt. Die Mitarbeiter der Wirtschaftsuniversität wurden per E-Mail über die Plakataktion verständigt.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 21 von 163
3 METHODIK UND VORGEHEN
3.1 Die Phasen der Konzeption
Das vorliegende Projekt gliederte sich im wesentlichen in zwei Projektphasen
• der Ist-Analyse sowie
• der Soll-Konzeption.
Diese Phasen wiederum lassen sich – wie in Abbildung 5 aufgezeigt – weiter detaillie-ren.
Projektvorbereitung/Ist-Analyse
Soll-Konzeption
Aufbau der Projektorganisation
Festlegung der Projektkonventionen
Schulung der WU-Projektmitarbeiter
Aufnahme des Ist-Zustands
Einarbeitung der Sekundärliteratur
Design der Soll-Modelle
Validierung der Soll-Modelle
Erhebung des Mengengerüstes
Vorstellung der Soll-Modelle
Wirtschaftlichkeitsbetrachtung
Migrationskonzept
Erstellung Abschlußbericht
Abbildung 5: Phasen des Projektes ‘2gether’
Der Schwerpunkt wurde dabei auf die Konzeption der universitären Verwaltungsabläufe unter Verwendung des neuen Systems ‘2gether’, im weiteren Verlauf „Universitätspro-zesse“ genannt, gelegt. Ein solcher Universitätsprozeß mit seinen verschiedenen In-stanzen ist beispielhaft in Abbildung 6 dargestellt
Aufgrund des relativ engen zeitlichen Rahmens des Projektes und vor dem Hintergrund bereits existierender umfangreicher Studien erfolgte die Ist-Aufnahme dabei nicht in Form aus führlich ausmodellierter ARIS-Modelle. Daher fokussiert dieser Bericht nahezu ausschließlich auf die Soll-Konzeption.
3 METHODIK UND VORGEHEN 3.1 Die Phasen der Konzeption
Seite 22 von 163 Erstellt gemeinsam m it 15. April 1998
Antrag-stellung
erforderlich
Antragist
eingereicht
UniversitätsverwaltungUniversitätsverwaltung MinisteriumMinisteriumStudentStudent
Gutachtenerforderlich
Akte
Antragerfaßt
Stellung-nahmeerfolgt
GesetzlicheVorlagen
Antragsdaten
Studenten-daten
Fach-referat
DV-System
Genehmigungs-bescheid
Antrags-eckwerte
Begut-achtungerfolgt
Antrags-erfassung
Antrags-prüfung
Antragbearbeitet
Abt.
Gremium
Antrags-stellung
Antrags-bearbeitung
Ext.Fach-referat
Begut-achtung
Abbildung 6: Die Instanzen eines Universitätsprozesses
Eine ausführliche Beschreibung der Darstellungstechnik erfolgt im Abschnitt Architektur integrierter Informationssysteme.
Um eine möglichst schnelle und effiziente Realisierung des Projektvorhabens zu errei-chen und gleichzeitig eine hohe Wiederverwendbarkeit der Projektergebnisse sicherzu-stellen, wird im Projekt durchgängig ein computergestütztes Werkzeug - das ARIS-Toolset - eingesetzt.
In allen Phasen des Projektes wurden daher die Interviewergebnisse sowie die Erkennt-nisse aus bereits vorhandener Literatur – wie z. B. des ‘Grobkonzeptes 2gether’ – mit Hilfe des ARIS-Toolsets aufbereitet und verarbeitet (vgl. Abbildung 7). Eine vollständige Auflistung sämtlicher zur Verfügung stehender Sekundärliteratur erfolgt im entspre-chenden Kapitel des Anhangs.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 23 von 163
Aufgaben- und Tätigkeitsanalyse Controlling VCAnzahl der Mitarbeiter nach Köpfen:
7
Personalkapazität in Mannjahren:7,00
Stunden pro Mannjahr:1582
Arbeitstage pro Jahr: 210Hauptaufgabe Aufgaben
Mi
ni
ma
le
D
FZ
(
in
h
)
fü
rd
ie
ein
ma
lig
e
Du
rc
hf
üh
ru
ng
Ma
xi
ma
le
D
FZ
(
in
h
)
fü
rd
ie
ein
ma
lig
e
Du
rc
hf
üh
ru
ng
Ge
wi
ch
te
te
,
mi
tt
le
re
D
FZ
(i
n
h)
f
ür
d
ie
e
in
-m
al
ig
e
Du
rc
hf
üh
ru
ng
Me
ng
e
p.
a.
An
za
hl
de
r
be
te
ilig
te
nM
it
ar
be
it
er
a
n
de
r
Te
ila
uf
ga
be
%-
An
te
il
e
de
r
DF
Z(
mi
n)
a
n
Me
ng
e
p.
a.
%-
An
te
il
e
de
r
DF
Z(
ma
x)
a
n
Me
ng
e
p.
a.
Ge
sa
mt
au
fw
an
d(
in
h
)
p.
a.
T
ei
la
uf
ga
be
Ge
sa
mt
au
fw
an
d(
in
MJ
)
p.
a.
T
ei
la
uf
ga
be
Ge
sa
mt
au
fw
an
d(
in
h
)
p.
a.
H
au
pt
au
fg
ab
eG
es
am
ta
uf
wa
nd
(i
n
MJ
)
p.
a.
%
-A
nte
il
de
r
Te
il-
au
fg
ab
e
an
H
au
pt
au
fg
ab
e%
-A
nt
ei
l
de
r
Ha
up
ta
uf
-g
ab
e
am
G
es
am
ta
uf
wa
nd
Unternehmenspla-
nung (kf., mf., lf.) 1782,2 1,12655 13,72%Wirtschaftlichkeit einzelner Projekte berechnen 1,52 7,6 4,56 2 0 50% 50% 91,2 0,0576 5%Haushaltsplan aufstellen u. bearbeiten 1178 1254 1216 1 50% 50% 12160,7686 68%mittelfristige Unternehmensplanung erstellen 228 304 266 1 50% 50% 2660,1681 15%
langfristige Unternehmensplanung erstellen 114 114 114 1 50% 50% 1140,0721 6%bei strat. Untern. entscheidungen mitarbeiten 76 114 95 1 50% 50% 9 5 0,0601 5%
Unternehmenskontrol-le bzw. -steuerung 300,1 0,1897 2,31%
Ergebnisrechnung laufend
kontrollieren 190 228 209 1 50% 50% 2090,1321 70%
Einzelmaßnahmen steuern 45,6 60,8 53,1 1 51% 49% 53,1 0,0336 18%neue Erkenntnisse berücksichtigen 30,4 45,6 38 1 50% 50% 3 8 0,024 13%
Kostensteuerung 1580,8 0,99924 12,17%Kostenrechnungssystem (KRS)
pflegen 197,6 684 440,8 1 50% 50% 440,8 0,2786 28%Anwender KRS schulen u. betreuen 76 152 114 1 50% 50% 1140,0721 7%
KRS weiterentwickeln 0 152 76 1 50% 50% 7 6 0,048 5%Kostenstellen auf Abweichungen analysieren 114 228 171 1 50% 50% 1710,1081 11%
Kostenstellengespräche vorbereiten und führen 304 456 380 1 50% 50% 3800,2402 44%Wertefluß der Kostenstellen analysieren 342 456 399 1 50% 50% 3990,2522 25%
Berichte erstellen 866,4 0,54766 6,67%Monatsberichte f.d. Entscheider-Ebene erstellen 15,2 15,2 15,2 6 50% 50% 91,2 0,0576 11%
Ber. z. Weitergabe a.d. Aufsichtsgremien erstellen 304 380 342 1 50% 50% 3420,2162 39%
Kostenstellen-Berichte erstellen 7,6 19 13,3 4 50% 50% 53,2 0,0336 6%
Aufgaben- und Tätigkeitsanalyse Controlling VC
Anzahl der Mitarbeiter nach Köpfen:7
Personalkapazität in Mannjahren: 7,00
Stunden pro Mannjahr: 1582
Arbeitstage pro Jahr: 210
Hauptaufgabe Aufgaben
Mi
ni
ma
le
D
FZ
(
in
h
)
fü
rd
ie
ein
ma
lig
e
Du
rc
hf
üh
ru
ng
Ma
xi
ma
le
D
FZ
(
in
h
)
fü
rd
ie
ein
ma
lig
e
Du
rc
hf
üh
ru
ng
Ge
wi
ch
te
te
,
mi
tt
le
re
D
FZ
(i
n
h)
f
ür
d
ie
e
in
-m
al
ig
e
Du
rc
hf
üh
ru
ng
Me
ng
e
p.
a.
An
za
hl
de
r
be
te
ilig
te
nM
it
ar
be
it
er
a
n
de
r
%-
An
te
il
e
de
r
DF
Z(
mi
n)
a
n
Me
ng
e
p.
a.
%-
An
te
il
e
de
r
DF
Z(
ma
x)
a
n
Me
ng
e
p.
a.
Ge
sa
mt
au
fw
an
d(
in
h
)
p.
a.
T
ei
la
uf
ga
be
Ge
sa
mt
au
fw
an
d(
in
MJ
)
p.
a.
T
ei
la
uf
ga
be
Ge
sa
mt
au
fw
an
d(
in
h
)
p.
a.
H
au
pt
au
fg
ab
e
Ge
sa
mt
au
fw
an
d(
in
M
J)
p
.a
.
Ha
up
ta
uf
ga
be
%-
An
teil
d
er
T
eil
-a
uf
ga
be
a
n
Ha
up
ta
uf
ga
be
%-
An
te
il
d
er
H
au
pt
au
f-
ga
be
a
m
Ge
sa
mt
au
fw
an
d
Unternehmenspla-nung (kf., mf., lf.) 1782,2 1,12655 13,72%
Wirtschaftlichkeit einzelner Projekte berechnen 1,52 7,6 4,56 2 0 50% 50% 91,2 0,0576 5 %Haushaltsplan aufstellen u. bearbeiten 1178 12541216 1 50% 50% 1216 0,7686 68%mittelfristige Unternehmensplanung erstellen 228 304 266 1 50% 50% 266 0,1681 15%langfristige
Unternehmensplanung erstellen 114 114 114 1 50% 50% 114 0,0721 6 %bei strat. Untern. entscheidungen mitarbeiten 76 114 95 1 50% 50% 95 0,0601 5 %
Unternehmenskontrol-le bzw. -steuerung 300,1 0,1897 2,31%
Ergebnisrechnung laufend
kontrollieren 190 228 209 1 50% 50% 209 0,1321 70%
Einzelmaßnahmen steuern 45,6 60,8 53,1 1 51% 49% 53,1 0,0336 18%neue Erkenntnisse berücksichtigen 30,4 45,6 38 1 50% 50% 38 0,024 13%
Kostensteuerung 1580,8 0,99924 12,17%
Kostenrechnungssystem (KRS) pflegen 197,6 684 440,8 1 50% 50% 440,8 0,2786 28%Anwender KRS schulen u. betreuen 76 152 114 1 50% 50% 114 0,0721 7 %
KRS weiterentwickeln 0 152 76 1 50% 50% 76 0,048 5 %
Kostenstellen auf Abweichungen analysieren 114 228 171 1 50% 50% 171 0,1081 11%Kostenstellengespräche vorbereiten und führen 304 456 380 1 50% 50% 380 0,2402 44%Wertefluß der Kostenstellen analysieren 342 456 399 1 50% 50% 399 0,2522 25%
Berichte erstellen 866,4 0,54766 6,67%Monatsberichte f.d. Entscheider-Ebene erstellen 15,2 15,2 15,2 6 50% 50% 91,2 0,0576 11%Ber. z. Weitergabe a.d. Aufsichtsgremien erstellen 304 380 342 1 50% 50% 342 0,2162 39%
Kostenstellen-Berichte erstellen 7,6 1 9 13,3 4 50% 50% 53,2 0,0336 6 %
Instand-haltungs-s u m m eermitteln
Instandhaltungs-s u m m e
istermittelt
Instand-hal tungssummemit
U-planung abgleichen
X O R
X O R
Instandhaltungs-summe istungleich
U-planung
Instandhaltungs-aufwand
kürzen
Instandhaltungs-aufwand istermittelt
Instandhaltungs-summe istzu planen
oThema: Neugestaltung der Budgetplanung und -abwicklung
oRahmenbedingung:
ßBudget pro KC nach Kennzahlen
oQuantitative Verbesserungen:
ßAbstimmungsgespräche in BST mitPlanungsingenieur (Bewertung der Projekte) entfällt
ßDV-Eingabe der Planungswerte und
Projekteinrichtung in HV entfällt
ßBewertung der HHP-Projekte nachPlanungsrichtlinien in der HV entfällt
ßAbstimmungsgespräche der Grobplanung im KC mitKC-Leiter u. Fachbereichen wird reduziert
ßBudgetgenehmigung und Freigabe an KC wird
r e d u z i e r t
ßManuelle Einkaufsdisposition entfällt
ßGeringeres Volumen der gedruckten Pläne u. desErstellungsaufwandes (HHP)
ßVereinfachte Materialbestellung undAufmaßerstellung mit anschließender
Rechnungserstellung der Baufirmen
ßVereinfachte DV-Erstellung und Fortführung derNetzpläne in KC
ßWeniger Projektänderungsdienst
ßVereinfachte Lohnaufschreibung
ßSynergieeffekt durch hohe Transparenz und Zugriff
der MA auf gleiche, aktuelle Infos
ßAbbau dezentraler Controllingtätigkeiten durchzielgerichtete, qualitative Planungsunterstützung
oThema: Neugestaltung der Budgetplanung und -abwicklung
oRahmenbedingung:
ßBudget pro KC nach Kennzahlen
oQuantitative Verbesserungen:
ßAbstimmungsgespräche in BST mitPlanungsingenieur (Bewertung der Projekte) entfällt
ßDV-Eingabe der Planungswerte und
Projekteinrichtung in HV entfällt
ßBewertung der HHP-Projekte nachPlanungsrichtlinien in der HV entfällt
ßAbstimmungsgespräche der Grobplanung im KC mitKC-Leiter u. Fachbereichen wird reduziert
ßBudgetgenehmigung und Freigabe an KC wird
reduziert
ßManuelle Einkaufsdisposition entfällt
ßGeringeres Volumen der gedruckten Pläne u. desErstellungsaufwandes (HHP)
ßVereinfachte Materialbestellung undAufmaßerstellung mit anschließender
Rechnungserstellung der Baufirmen
ßVereinfachte DV-Erstellung und Fortführung derNetzpläne in KC
ßWeniger Projektänderungsdienst
ßVereinfachte Lohnaufschreibung
ßSynergieeffekt durch hohe Transparenz und Zugriff
der MA auf gleiche, aktuelle Infos
ßAbbau dezentraler Controllingtätigkeiten durchzielgerichtete, qualitative Planungsunterstützung
Grobkonzept‘2gether’
‘Sinz-Studie’ etc.
GraphischeOrganisations-
modelle Reports
ßGeringeres Volumen der gedruckten Pläne u. desErstellungsaufwandes (HHP)
ßVereinfachte Materialbestellung undAufmaßerstellung mit anschließenderRechnungserstellung der Baufirmen
ßVereinfachte DV-Erstellung und Fortführung derNetzpläne in KC
ßWeniger Projektänderungsdienst
ßVereinfachte Lohnaufschreibung
ßSynergieeffekt durch hohe Transparenz und Zugriffder MA auf gleiche, aktuelle Infos
ßAbbau dezentraler Controllingtätigkeiten durch
zielgerichtete, qualitative Planungsunterstützung
Erhebungsbogen Interviews/Workshops
ARIS-Toolset
Abbildung 7: Werkzeuggestütztes Vorgehen im Projekt ‘2gether’
Dabei entstand eine umfangreiche Datenbasis in Form einer ARIS-Datenbank, deren Auszüge wesentlicher Bestandteil in diesem Bericht sind (siehe Abschnitt Fachliche Konzeption des Systems ‘2gether’).
3.2 Architektur integrierter Informationssysteme
Das ARIS-Toolset ist ein DV-gestütztes Beratungswerkzeug auf Datenbankbasis, ins-besondere für folgende Fragestellungen:
• Analyse- und Optimierung organisatorischer Abläufe, Geschäfts- bzw. Uni-versitätsprozesse;
• Erstellung fachlicher und organisatorischer Sollkonzepte;
• Erstellung von IV-Strategien und IV-Bebauungsplänen;
• Einführung von Software, insbesondere Standardsoftware.
3 METHODIK UND VORGEHEN 3.2 Architektur integrierter Informationssysteme
Seite 24 von 163 Erstellt gemeinsam m it 15. April 1998
Das von der IDS Prof. Scheer GmbH entwickelte ARIS -Toolset ist ein wissenschaftlich fundiertes und in vielen Projekten erprobtes Modellierungs-Werkzeug, welches inzwi-schen im Bereich der Werkzeuge zur Geschäftsprozeßoptimierung weltweit marktfüh-rend ist.
3.2.1 Hintergrund und Idee
Wissenschaftliche Grundlage für das Werkzeug ist die Architektur integrierter Informa-tionssysteme (ARIS), ein Methodenrahmen zur Unter nehmensmodellierung, der am In-stitut für Wirtschaftsinformatik der Universität des Saarlandes entwickelt worden ist. Kerngedanke des ARIS ist der der Zerlegung der darzustellenden Organisation nach verschiedenen Aspekten und der zielgerechten (Wieder-) Integration der Information zur effizienten Erreichung des Projektzieles.
Dadurch wird einerseits eine große Übersichtlichkeit in der Darstellung komplexer Sachverhalte, andererseits aber auch ein systematisches Vorgehen im Projekt erreicht. Je nach Darstellungsfokus kommen dabei unterschiedliche Modell-, d.h. Diagrammty-pen zum Einsatz.
Die Zerlegung des Gesamtsystems erfolgt nach Sichten und Ebenen (vgl. Abbildung 8):
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 25 von 163
Organigramm
Netztypologie-Diagramm*
Netzdiagramm**
Analyzer Typologiediagramm, eEPK, Ereignisdiagramm, Funktions-/Organisationsebenendiagramm, Funktionszuordnungsdiagramm,
Informationsflußdiagramm, Klassendiagramm, Klassifizierungsdia-gramm, Prozeßauswahlmatrix, Regeldiagramm, (VKD), Wert-
schöpfungskettendiagramm
Zugriffsdiagramm*Programmablaufdiagramm
Zugriffsdiagramm (physikalisch)**
FunktionsbaumY-DiagrammZieldiagramm
Anwendungssystem-diagramm**
Anwendungssystem-typdiagramm*
eERMeERM-Attributzuordnungs-diagramm, [SAP-SERM]
Fachbegriffsmodell***
Attributzuordnungs-diagramm,
Relationendiagramm*
Tabellendiagramm**
Organisation
Steuerung FunktionDaten
Abbildung 8: Das ARIS -Haus im Gesamtüberblick
3.2.2 Die ARIS-Ebenen
Bei der Unternehmensmodellierung treffen in den Projekten oftmals Mitarbeiter unter-schiedlicher Fachrichtungen aufeinander. Dies ist beispielsweise immer dann der Fall, wenn zum Zwecke der Anwendungssystementwicklung Entwickler und Sac hbearbeiter zusammenarbeiten. Jede Richtung hat dabei ihren eigene Sprachgebrauch: die Sac h-bearbeiter reden in fachlichen Termini, während die Entwickler dv-bezogene Ausdrücke und Begriffe verwenden. Dies macht die Verwendung jeweils spezifischer Beschrei-bungsmethoden naheliegend. ARIS bietet daher Modelltypen in drei verschiedenen Ebe-nen, die sich durch ihre Nähe einerseits zur fachlichen Seite, andererseits zur imple-mentierungsnahen Beschreibung unterscheiden (vgl. Abbildung 9).
3 METHODIK UND VORGEHEN 3.2 Architektur integrierter Informationssysteme
Seite 26 von 163 Erstellt gemeinsam m it 15. April 1998
Fachkonzept
DV-Konzept
Implementierung
Fachbereich
Datenverarbeitung
Abbildung 9: Ebenenkonzept des ARIS
Die Breite der Pfeile symbolisiert dabei die Stärke der Kopplung zwischen den Ebenen, so daß in der ARIS-Methodik bewußt eine lose Verbindung zwischen Fach- und DV-Konzept realisiert wird.
Entsprechend der Zielsetzung des Projektes wird hier nur im Bereich des Fachkonzep-tes modelliert, so daß im weiteren auch nicht näher auf die Ebenen DV-Konzept und Implementierung eingegangen wird und sich folgende Ausführungen stets auf die Fac h-konzeptebene beziehen. Grundsätzlich erstreckt sich die im nächsten Abschnitt be-schriebene Sichtenbildung natürlich auf alle Ebenen des ARIS-Hauses (Literaturhinweis: [Scheer95|98]).
3.2.3 Die ARIS-Sichten
Ein weiterer wesentlicher Aspekt der ARIS -Methode ist die Verwendung von vier ver-schiedenen Sichten:
• der Organisationssicht,
• der Funktionssicht,
• der Datensicht sowie
• der Steuerungssicht.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 27 von 163
In der Organisationssicht wird die Aufbauorganisation beispielsweise einer Universität beschrieben. Wichtigster Modelltyp ist hier das - auch außerhalb des ARIS verwendete - Organigramm, in dem die statischen, hierarchischen Beziehung von Organisationsein-heiten wie Fachbereichen, Abteilungen oder auch Stellen beschreiben und definiert wer-den (vgl. Abbildung 10).
Universitäts-direktion
Rechts - undOrganisations-
abteilungPersonalabteilung
Studien- undPrüfungsabteilung
(STAB)
Wirtschaftsabtei-lung und Abteilung
für Gebäudeund Technik
Quästur
Abbildung 10: Beispiel eines Organigramms (Ausschnitt)
In den Organigrammen werden in der Regel sämtliche organisatorische Einheiten defi-niert, die in den anderen Modellen verwendet werden können.
In der Funktionssicht wird die statische, hierarchische funktionale Struktur einer Institu-tion abgebildet. Dies kann in einer Universität beispielsweise deren Aufgabenstruktur oder aber auch natürlich die (hierarchische) Struktur der Vorgangsbearbeitung sein. Dies bedeutet, daß Aufgaben, Prozesse, Arbeitsvorgänge und Tätigkeiten etc. definiert und ihre Einordnung in die funktionale Gesamtstruktur beschrieben werden. Verwen-dung findet dabei in erster Linie der Modelltyp Funktionsbaum, der eben diesen Zweck ermöglicht und der beispielhaft in Abbildung 11 dargestellt ist.
3 METHODIK UND VORGEHEN 3.2 Architektur integrierter Informationssysteme
Seite 28 von 163 Erstellt gemeinsam m it 15. April 1998
Studien- undPrüfungs-verwaltung
allgemeineFunktionenStudium
*
Lehrver-anstaltung
*
Prüfung
*
Abschluß-arbeiten
*
An-undAbmeldung
*
Anerkennung
*
Abrechnung
*
Evaluierungder Lehre
*
allgemeineSystem-
funktionen
Abbildung 11: Beispiel eines Funktionsbaums
Die dritte Säule des sogenannten ARIS-Hauses ist die Datensicht. Hier wird die (stati-sche) Struktur der im Untersuchungsbereich verwendeten Nutzendaten beschrieben. Die Beschreibung der Datenstruktur ist in erster Linie für Projekte im Bereich Anwen-dungssystementwicklung vonnöten, da aus ihr das notwendige Datenbankschema ab-geleitet oder gar (mit Hilfe eines CASE-Tools) generiert werden kann. Bekanntester Mo-delltyp ist dabei das seit den 70er Jahren verbreitete Entity-Relationship-Modell.
Dieser Modelltyp bildet unter anderem einen Schwerpunkt dieses Projektes. Dabei wer -den die Datenstrukturen beschrieben, so wie sie im Bereich der Studien- und Prüfungs-verwaltung Verwendung finden. Zentrales Objekt im ERM ist der Entitytyp mit seinen Beziehungen im betrachteten Umfeld. Dieses Objekt wird dargestellt mittels eines Rechtecks, seine Beziehungen zu anderen Entitytypen mittels einer Raute, s.d. die Kombination „Entitytyp - Beziehungstyp - Entitytyp“ i.d.R. der Semantik eines Satzes mit „Subjekt - Prädikat - Objekt“ entspricht.
Zur genaueren Spezifizierung der Beziehung zweier Entitytypen werden sog. Kardi-nalitäten eingeführt. Diese beschreiben, wie oft ein Entitytyp in einer Beziehung er -scheinen kann. So bedeutet „cn“ beispielsweise, daß der Entitytyp keinmal bis beliebig oft in der entsprechenden Beziehung existieren kann.
Darüber hinaus können Beziehungstypen zur Konstruktion eines neuen Objektes, wel-ches wiederum eigene Beziehungen eingehen kann, führen. Ein markantes Beispiel hierfür ist die Lehrveranstaltungsanmeldung, die eine Kombination aus Student und Lehrveranstaltung ist. Grafisch werden diese uminterpretierten Beziehungstypen durch ein um die Raute gelegtes Rechteck dargestellt.
Schließlich sei als wichtiges logisches Mittel noch die Generalisierung/Spezialisierung erwähnt. Diese Beziehung, dargestellt in Form eines Dreiecks, beschreibt die hierarchi-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 29 von 163
sche Struktur der Datenobjekte. Je nach Betrachtungsrichtung liest man sie „kann sein“ oder „ist ein“: z.B. eine Diplomarbeit ist eine Abschlußarbeit. Diese Konstruktion wird insbesondere verwendet zur Verdeutlichung von Vererbungsmechanismen, mit denen die Attribute und Beziehungen des übergeordneten Objektes auf das untergeordnete übertragen werden (Abbildung 12).
Die Objekte des Datenmodells definieren sich schließlich im Grunde durch eine Zu-sammenfassung von Attributen, sprich Datenfeldern, welche aus Gründen der Über -sichtlichkeit in dieser Arbeit in einer EXCEL-Tabelle erfaßt werden.
*
Organisations-einheit
*
istbeteiligt
an
*
Student
*
Lehrver-anstaltung
*
Lehrver-anstaltungs-anmeldung
Teilnehmer-gruppe
bildet
*
Lehrver-anstaltungs-
termin
[Teilnehmerzahl] etc.
findetstatt an
Anwesenheit
*
Lehrver-anstaltungs-teilnahme
generiert
externeOrganisations-
einheit
interneOrganisations-
einheit
1
Organisations-struktur
cn cn
n
cn
1
cn
cn
1
c
cn
cn
cn
cn ist übergeordnet
c ist untergeordnet
Legende:
‘c’: 0 bis 1 Bez.
‘1’: genau 1 Bez.
‘cn’: 0 bis n Bez.
‘n’: 1 bis n Bez.
Abbildung 12: Beispiel Entity-Relationship-Modell
Es folgt die zentrale Sicht des ARIS-Hauses, die Steuerungssicht.
In ihr werden die Prozesse, beispielsweise der Vorgangsbearbeitung in ihrem zeitlich-logischen Ablauf beschrieben. Sie ist damit von wesentlicher Bedeutung bei der Aufzei-gung der organisatorischen Konsequenzen, die mit der Einführung eines neuen Anwen-dungssystems verbunden sind. Im Gegensatz zu den rein statischen Beschreibungen der anderen Sichten werden hier - unter Verwendung der in eben diesen Sichten defi-nierten Organisationseinheiten, Funktionen und auch Anwendungssysteme - Prozesse in ihrer dynamischen Folge dargestellt. Wesentlicher Modelltyp ist die Ereignisgesteuer-te Prozeßkette (EPK), wie sie beispielhaft in Abbildung 13 gezeigt ist.
3 METHODIK UND VORGEHEN 3.2 Architektur integrierter Informationssysteme
Seite 30 von 163 Erstellt gemeinsam m it 15. April 1998
Semester-beginn
eingetreten
automatische Generationvom System
Beauftragungs-Bescheidegenerieren
LV-Leiterelektronischerreichbar
Normalfall
2gether
Beaufragungs-bescheide
verschicken
automatisch
LV-Leiterbenachrichtigt
Beauftragungs-bescheidedrucken
Beauftragungs-bescheide
2gether 2gether
Beauftragungs-bescheidegedruckt
absoluterAusnahmefall
LV-Leiterbenachrichtigen
LV-Leiterelektronisch
nicht erreichbar
absoluterAusnahmefall
Rechts - undOrganisations-
abteilungBeauftragungs-bescheide
Rechts - undOrganisations-
abteilung
Beauftragungs-bescheideeinsehen
LV-Leiter
Abbildung 13: Beispiel einer Ereignisgesteuerten Prozeßkette (Ausschnitt)
Grundgedanke der EPK ist - wie der Name schon sagt - die „Ereignissteuerung“ eines Prozesses. Dabei wird jede Tätigkeit (Funktion) durch ein genau definiertes Ereignis ausgelöst und mit einem bestimmten Ergebnis beendet. Dieses Ergebnis - auch in Form eines Ereignis ses - löst sodann eine weitere Funktion aus u.s.w. Dies bedeutet, daß auch ein Prozeß selbst durch ein oder mehrere Startereignisse ausgelöst und mit einem oder mehreren Endereignissen beendet wird. Diese Start- und Endereignisse können wiederum auch mit anderen Prozessen in Verbindung stehen, die dann durch sogenannte Prozeßwegweiser dargestellt werden (hier nicht im Bild). Desweiteren las-sen sich in der EPK auch die mit den einzelnen Tätigkeiten verbundenen Informations-objekte wie Stellen, Dokumente (Informationsträger), Daten oder Anwendungssysteme aber auch beispielsweise externe Beteiligte etc. darstellen.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 31 von 163
Dabei sind folgende Lesarten angezeigt:
• Das Anwendungssystem unterstützt die Funktion
• Das Organisationselement führt aus die Funktion
• Der Datum ist Input/Output der Funktion
• Der Informationsträger ist Input/Output der Funktion u.s.w.
Diese Zusammenhänge lassen sich fallweise auch in eigenen, ausgelagerten Modellen, den Funktionszuordnungsdiagrammen (FZD) darstellen (vgl. Abschnitt Projektkonventi-onen).
Zusammenfassend seien im folgenden Abbildung 14 die in diesem Projekt verwendeten Objekttypen in Form einer Legende aufgelistet.
Ereignis
Funktion
log. 'und'
log. 'exklusiv oder'
log. 'und/oder'
Anwendungssystem
Organisations-einheit (-styp)
Informationsträger(Dokument)
Personentyp
Informationsträger(Datei)
Entitytyp
Datencluster
Beziehungstyp
uminterpretierterBeziehungstyp
Legende
Generalisierung/Spezialisierung
3 METHODIK UND VORGEHEN 3.2 Architektur integrierter Informationssysteme
Seite 32 von 163 Erstellt gemeinsam m it 15. April 1998
Abbildung 14: Legende der verwendeten Objekttypen
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 33 von 163
3.3 Grundsätze ordnungsmäßiger Modellierung
Die Grundsätze ordnungsmäßiger Modellierung (GoM) schaffen in begrifflicher Anleh-nung an die ‘Grundsätze ordnungsmäßiger Buchführung’ eine methodenunabhängige Grundlage für die Darstellung von Informationsstrukturen in Form von Modellen, wie sie z.B. bei der Unternehmensmodellierung - zu der ja auch die Geschäftsprozeßmodellie-rung gehört - durchgeführt wird.
Dabei schaffen sie einerseits ein theoretisches Fundament für die Beschreibungsme-thoden als solche (‘Meta-Ebene’), andererseits werden aber auch Richtlinien für die ei-gentliche Modellierung der Inhalte entwickelt. Die GoM’s werden dabei in einer Anzahl von Grundsätzen formuliert.
Ersterer Aspekt, die Meta-Ebene, beinhaltet dabei
• den Grundsatz der Vergleichbarkeit sowie
• den Grundsatz des systematischen Aufbaus.
Diese Anforderung sind durch die verwendete ARIS -Methode voll abgedeckt, so daß „le-diglich“ die inhaltlichen Grundsätze für dieses wie für jedes Projekt zu verwirklichen sind. Diese lauten:
• Grundsatz der Richtigkeit,
- syntaktisch
- semantisch
• Grundsatz der Relevanz,
• Grundsatz der Wirtschaftlichkeit und
• Grundsatz der Klarheit
- Strukturiertheit
- Übersichtlichkeit
- Lesbarkeit.
Auf eine ausführliche Beschreibung der einzelnen Grundsätze kann an dieser Stelle nicht eingegangen werden; das intuitive Verständnis der Begriffe erscheint aber jedoch auch als ausreichend.
Zur Realisierung der GoM’s in einem GPO-Projekt unter Einsatz eines Modellierungs-werkzeugs stellen sich damit konkret folgende Fragen der:
3 METHODIK UND VORGEHEN 3.3 Grundsätze ordnungsmäßiger Modellierung
Seite 34 von 163 Erstellt gemeinsam m it 15. April 1998
• Methodenverwendung, d.h.
- Auswahl der Modelltypen,
- Auswahl der Objekttypen,
- Auswahl der Kantentypen,
- Auswahl der Attributtypen;
• Modellierungsrichtlinien, d.h.
- Benennung von Objekten,
- Benennung von Modellen,
- Detaillierungsgrad von Objekten,
- Gruppierung von Objekten;
• Darstellungskonventionen, d.h.
- allgemeine grafische Einstellungen,
- grafische Normen für Diagramme,
- Ausrichtung von Objekten sowie des
• Werkzeugeinsatzes, d.h.
- Aufbau der Gruppenhierarchie,
- Festlegung der Benutzerrechte,
- [Zusammenführen von Datenbanken,]
- Koordination bei Multi-User-Betrieb,
- Verwendung von Kopierarten,
- Definition von Standardreports sowie
- Definition von Konsistenzchecks
All diese Aspekte münden in der Festlegung von projektspezifischen Konventionen, die ihren Niederschlag in
• der (Aufbau-) Organisation des Projektes,
• der inhaltlichen Vorgehensweise in der Modellierung,
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 35 von 163
• der Administration und dem Aufbau der ARIS-Datenbank,
• der Erstellung eines projektspezifischen Methodenfilters,
• der Definition von Standardauswertungen mit Hilfe von Reports und Makros sowie in der
• verbalen Beschreibung der weiterhin getroffenen Konventionen
finden.
Es ergibt sich also als methodische Grundlage für die Projektdurchführung folgender, in Abbildung 15 dargestellter Aufbau:
Grundsätze ordnungs-mäßiger Modellierung (GoM)
Architektur integrierterInformationssysteme (ARIS)
ZielgerichteteProjektkonventionen
Projekterfolg
Abbildung 15: Bestandteile der Methodik
So weit möglich und sinnvoll wird auf die verschiedenartigen Konventionen in den fol-genden Abschnitten eingegangen. Insbesondere letztere sind wertvoll zum Verständnis der Modelle und somit letztlich auch zur sinnvollen Weiterverwendung des Erarbeiteten.
3 METHODIK UND VORGEHEN 3.4 Projekt-/Modellierungskonventionen
Seite 36 von 163 Erstellt gemeinsam m it 15. April 1998
3.4 Projekt-/Modellierungskonventionen
An dieser Stelle erfolgt eine Beschreibung der im Rahmen des Projektes aufgestellten Konventionen. Dabei handelt es sich einerseits um solche, die durch den speziellen ARIS-Methoden-Filter („WU-Wien-Filter“) sichergestellt werden, andererseits um Kon-ventionen, die nur durch Modellierungsdisziplin und manuelle Qualitätssicherung zu rea-lisieren sind:
Unter den „Erweiterten Modellierungskonventionen“ werden Konventionen gefaßt, die über die reine Einschränkung von ARIS -Modelltypen, -Objekttypen oder –Kantentypen – realisiert durch den Methodenfilter – hinausgehen.
Dies sind insbesondere Konventionen zur Interpretation der Modelle („implizite“ Konven-tionen), zur Verwendung von Objekttypen oder bspw. zur Verwendung von Ausprä-gungskopien etc.
3.4.1 Verwendung aufbauorganisatorischer Elemente
Zur leichteren Lesbarkeit und Erhöhung der Allgemeingültigkeit wird auf die explizite Ver -wendung einzelner Instituts- oder Abteilungsbezeichnungen aus den Fachbereichen verzichtet. Statt dessen wird in den Prozeßmodellen das Objekt „Institut/Abteilung" ver-wendet zum Verweis auf die jeweils betroffenen Organisationseinheit. Dies wird durch die unsymmetrische Struktur der Fachbereiche - Aufgliederung in Institute und/oder Ab-teilungen - an der WU Wien erforderlich und fördert zudem die allgemeine, übergreifen-de Verwendung der Ergebnisse.
Entsprechend gilt Analoges für die jeweiligen Leiter/-innen der betreffenden Organi-sationseinheit.
3.4.2 Aufbau der Modellhierarchie
3.4.2.1 Ablaufbeschreibung versus Funktionalitätsbeschreibung
Es wird unterschieden zwischen Funktionalitäten, die eine dezidierte Beschreibung der ablauforganisatorischen Einbindung des Systems ‘2gether’ erfordern und solchen, die eher Ad-Hoc-Funktionalitäten entsprechen, d.h. bei denen die beschriebenen Teilaspek-te im weitesten Sinne Modulen entsprechen, die von Berechtigten jederzeit ausgeführt werden können.
Erstere werden dementsprechend durch Ereignisgesteuerte Prozeßketten beschrieben, letztere durch Funktionsbäume. Diese Funktionsbäume werden allerdings ergänzt um
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 37 von 163
Funktionszuordnungsdiagramme, die jeweils den sog. „Level-1-Funktionen“ hinterlegt werden und die sowohl die organisatorische Zuordnung als auch die systemseitige Un-terstützung der beschriebenen Funktionalität definieren.
3.4.2.2 Bildung von Szenarien
Erfordert die Beschreibung der Funktionalitäten, respektive Abläufe, die Bildung von Va-rianten, sogenannten „Szenarien“, dann erfolgt dies über das Instrument der Proz e-ßauswahlmatrix (PAM). Dabei wird diese – in Ergänzung der Standardkonventionen – um ihre Bedeutung erweitert, so daß letztlich über die PAMs auch in Funktionsbäume navigiert werden kann.
3.4.2.3 Integration von Daten und Funktionalitäten
Entsprechend des Zeitrahmens sowie insbes ondere den Zielen dieses Projektes (näm-lich eine Ausschreibungsgrundlage zu erzeugen), erfolgt die Spezifikation lesender oder schreibender Datenzugriffe durch Funktionen mit Hilfe von Funktionszuordnungsdia-grammen auf Prozeß- und Clusterebene. Entsprechend wird auf die Zuordnung detail-lierter Datenobjekte oder gar -felder zu einzelnen Funktionalitäten verzichtet.
3.4.3 Detaillierungsgrad
Der Detaillierungsgrad der Modellierung richtet sich nach den Zielen des Projektes und folgt somit insbesondere den Grundsätzen der Relevanz sowie der Wirtschaftlichkeit (vgl. Abschnitt Grundsätze ordnungsmäßiger Modellierung). Im Einzelnen:
3.4.3.1 Datenmodelle
Die konzeptionellen Datenmodelle wurden in Form detaillierter (erweiterte) Entity-Relationship-Modelle erstellt. Diese beinhalten zunächst keine Datenfelder (Attribute), sondern Verweise der einzelnen Datenobjekte auf eine EXCEL-Tabelle. Diese Verweise können im ARIS-Toolset unmittelbar ausgelöst werden und enthalten jeweils eine Liste der wesentlichen Datenfelder.
3.4.3.2 Prozeßmodelle
Der in den Ereignisgesteuerten Prozeßketten verwendete Detaillierungsgrad richtet sich nach der Klarheit und Aussagekraft der jeweiligen Beschreibung der Funktion. Es ist daher möglich, daß in den Modellen sowohl sogenannte „Elementartätigkeiten“ als auch komplexere Arbeitsschritte verwendet wurden. Dadurch wird eine intuitivere Lesbarkeit und somit ein besseres Verständnis erreicht.
In diesem Zusammenhang ist auch zu betonen, daß die Funktionen in den Proz e-ßabläufen teilweise als optional einzuordnen sind.
3 METHODIK UND VORGEHEN 3.4 Projekt-/Modellierungskonventionen
Seite 38 von 163 Erstellt gemeinsam m it 15. April 1998
3.4.4 Übersicht der Methodenverwendung
In den folgenden tabellarischen Übersichten werden die im Projekt verwendeten Modell-, Objekt- und Attributtypen beschrieben. Dabei wird spezifiziert, ob es sich jeweils um ei-nen optionalen („Kann“) oder um einen obligaten („Muß“) Bestandteil handelt. Darüber hinaus werden zum besseren Verständnis intuitive Beispiele angeführt.
Auf eine darüber hinausgehende Auflistung der verwendeten Kantentypen wurde aus Gründen der Übersichtlichkeit verzichtet.
Modelltyp Kann Muß Beispiel
Organigramm X Organigramm WU Wien
EEPK X Planung von Lehrveranstaltungen
Prozeßauswahlmatrix X An- und Abmeldung
EERM X Lehrveranstaltung
Funktionszuordnungsdiagramm X Abrechnung
Funktionsbaum X Prüfungsanmeldung
Tabelle 3: Modelltypverwendung
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 39 von 163
Modelltyp Objekt -/Symboltyp Kann Muß Beispiel
eEPK Ereignis X „VVZ ist erstellt“
Funktion X „VVZ drucken“
Prozeßwegweiser X
Personentyp X Student/-in (im Sinne einer Rolle)
(externe) Person X Druckerei
Organisationseinheit (-styp) X Institut
Anwendungssystem (-typ) X ‘2gether’
Regel X ‘und’, ‘oder’, ‘exkl. oder’
Prozeßwegweiser X folgender Prozeß
Dokument X Beauftragungsbescheid
Datei X VVZ
FZD1 Funktion X Abrechnung
Personentyp X Student/-in (im Sinne einer Rolle)
Organisationseinheit (-styp) X Institut
Anwendungssystem (-typ) X 2gether
Cluster X Lehrveranstaltung
Funktionsbaum Funktion X Chipkarten personalisieren
Organigramm Organisationseinheit (-styp) X STAB, Institut
Prozeßaus-wahlmatrix
Szenario X Lehrveranstaltungsan- und -abmeldung
Hauptprozeß X Einzelanmeldungen
Prozeß X Lehrveranstaltungsanmel-dung
eERM Entitytyp X Student/-in
Beziehungstyp X Reservierung; (Terminliste) gibt Vorlagetermin für (Aner-
1 Funktionszuordnungsdiagramm
3 METHODIK UND VORGEHEN 3.4 Projekt-/Modellierungskonventionen
Seite 40 von 163 Erstellt gemeinsam m it 15. April 1998
Modelltyp Objekt -/Symboltyp Kann Muß Beispiel kennungsantrag)
Uminterpretierter Beziehungs-typ
X LV-Anmeldung
Generalisierung/ Spezialisie-rung
X (WU-Angehöriger) kann sein (wiss. MA)
Tabelle 4: Modell-/Objekttypzuordnung
Objekt-/Symboltyp
Attributtyp Kann Muß Inhalt
<alle> Name X2 --
Identifizierer X Ids1.4711
Langbezeichnung X Name ohne Abkürzungen
Bemerkung/Beispiel X Zusatzinfo
Beschreibung/Definition X Zusatzinfo
Funktion Bearbeitungskennzeichen X „*“ als Hinweis auf WORD-Hinterlegung
Systemattribute/Extern i X Verweis auf WORD-Hin-terlegung
Funktionstyp/Typ 1 X „P“: hinterlegter Prozeß
„F“: hinterlegter Funktions-baum
Bearbeitungsart/auto-dezentral
X Automatisch, dezentral von ‘2gether’ durchgeführte Funk-tion
Bearbeitungsart/auto-zen-tral
X Automatisch, zentral von ‘2gether’ durchgeführte Funk-tion
Hauptprozeß Bearbeitungskennzeichen X „*“ als Hinweis auf WORD-Hinterlegung
Systemattribute/Extern i X Verweis auf WORD-Hin-terlegung
2 außer ‘Generalisierung/Spezialisierung’
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 41 von 163
Objekt-/Symboltyp
Attributtyp Kann Muß Inhalt
Informationsträger --
Organisations-einheit
--
Organisationsein-heitstyp
--
(externe) Person --
Personentyp --
Anwendungs-system typ
--
Beziehungstyp Beschreibung/Definition X Beispielhafte Datenfelder
System/Extern i X Verweis auf EXCEL-Hin-terlegung
Bearbeitungskennzeichen X „*“ als Hinweis auf EXCEL-Hinterlegung
Cluster/Daten-modell
Verfasser/Quelle X Zugehöriges Altsystem
Ereignis --
Generalisie-rungstyp
Zerlegungsgrad X ‘c’: unvollständig, disjunkt
‘1’: vollständig, disjunkt
‘cn’: unvollständig, nicht dis-junkt
‘n’: vollständig, nicht disjunkt
Regel --
Entitytyp Beschreibung/Definition X Beispielhafte Datenfelder
System/Extern i X Verweis auf EXCEL-Hin-terlegung
Bearbeitungskennzeichen X „*“ als Hinweis auf EXCEL-Hinterlegung
Tabelle 5: Objekt-/Attributtypzuordnung
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 43 von 163
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“
4.1 Organisatorische Gestaltung der Studien- und Prü-fungsverwaltung
Die organisatorische Einbindung des Systems ‘2gether’ in die WU Wien ist Gegenstand dieses Kapitels. Die erwähnten Organisationseinheiten sind dabei – wie in der folgenden Abbildung 16 aufgezeigt – in die Aufbauorganisation eingegliedert.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 44 von 163 Erstellt gemeinsam m it 15. April 1998
Uni
vers
itäts
-ko
llegi
um
UK
Kom
mis
sion
Bes
onde
reU
nive
rsitä
ts-
einr
icht
ung
Bür
o de
rK
olle
gial
-or
gane
Stu
dien
-de
kana
t
Stu
dien
-de
kan
Uni
vers
itäts
-di
rekt
ion
Bib
lioth
ekA
ußen
inst
itut
Zent
rum
für
Aus
land
s-st
udie
nZI
DS
prac
hlab
or
Rec
hts
- un
dO
rgan
isat
ions
-ab
teilu
ngP
erso
nal-
abte
ilung
Stu
dien
- und
Prü
fung
sabt
eilu
ng(S
TAB
)
Wirt
scha
ftsab
tei-
lung
und
Abt
eilu
ngfü
r G
ebäu
deun
d Te
chni
k
Quä
stur
Vol
ksw
irt-
scha
fts-
lehr
eR
echt
swis
sen-
scha
ftG
eist
es-
und
Form
al-
wis
sens
chaf
t
Bet
riebs
-w
irtsc
hafts
-le
hre
Inst
itut/
Abt
eilu
ngIn
stitu
t/A
btei
lung
Inst
itut/
Abt
eilu
ngIn
stitu
t/A
btei
lung
Stu
dien
-ko
mm
issi
on
WU
Wie
n
Rek
tor/
Viz
erek
tore
n
Abbildung 16: WU Wien Aufbauorganisation nach UOG 93, Überblick3
3 Quelle: UOG 93
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 45 von 163
4.1.1 Übersicht
Studien- undPrüfungs-verwaltung
allgemeineFunktionenStudium
*
Lehrver-anstaltung
*
Prüfung
*
Abschluß-arbeiten
*
An-undAbmeldung
*
Anerkennung
*
Abrechnung
*
Evaluierungder Lehre
*
allgemeineSystem-
funktionen
Abbildung 17: Funktionsbaum „Studien- und Prüfungsverwaltung“
Bemerkungen:
Unterteilt werden die organisatorischen Themengebiete nahezu wie im Grobkonzept 2gether, das im Vorfeld zu diesem Bericht entstand - also in Studium, Lehrveranstaltun-gen, Prüfungen etc. (vgl. Abbildung 17). Das Grobkonzept bildet also den Rahmen der fachlichen Konzeption.
Die im Grobkonzept aufgeführten „allgemeinen Funktionen“ der Anwendungssoftware (Kapitel 5.1 Grobkonzept) und die Themenpunkte der „Systemimplementierung und -verwaltung“ (Kapitel 6 Grobkonzept) wurden ohne größeren Zusatz übernommen und dem Kapitel „allgemeinen Systemfunktionen“ zugeordnet – ausgenommen die Chipkar-tenverwaltung, die dem Kapitel „allgemeine Funktionen“ zugeordnet wurden. Bei den anderen Themengebieten wurden Prozeßketten (eEPK) und Funktionsbäume model-liert, um die künftige Ablaufbeschreibung detaillierter und transparenter zu machen und damit die Akzeptanz der potentiellen Benutzer zu erhöhen. Das Kapitel „Sonstige Funk-tionen“ (Kapitel 5.10 Grobkonzept), wurde in „Allgemeine Funktionen“ umbenannt.
In jedem Themenabschnitt, wie z.B. „Lehrveranstaltungen“, findet man das Übersichts-modell (Prozeßauswahlmatrix oder Funktionsbaum) abgebildet mit Erläuterungen. In al-len Unterabschnitten, wie z.B. „Planung von Lehrveranstaltungen“, werden Funktions-zuordnungsdiagramme mit Beschreibung der teilnehmenden Organisationsabteilungen und wichtigen Anwendungssystemen aufgeführt. Außerdem kommen Bemerkungen zu den Prozessen oder Funktionsbäumen hinzu. Die Prozesse und Funktionsbäume findet
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 46 von 163 Erstellt gemeinsam m it 15. April 1998
man im Anhang, tragen den gleichen Namen wie die Unterabschnitte (also z.B. „Pla-nung von Lehrveranstaltungen“) und liefern die Detailinformationen. Natürlich sollte grundsätzlich bei Unklarheiten auf die ARIS-Datenbank ‘WU_Wien’ zurückgegriffen werden, in der bei vielen Objekten weitere Informationen hinterlegt sind. Ein wesentli-cher Bestandteil am Ende fast jeden Abschnitts/Unterabschnitts ist die Abschätzung des Nutzenpotentials aus der Sicht der beteiligten Organisationseinheiten. Aufgrund der hohen Heterogenität der Abteilungen/Institute der WU-Wien kann nicht jeder Nutzen al-len Abteilungen/Instituten zugeordnet werden; auch finden sich dieselben Arbeiten in den einen Abteilungen/Instituten bei den Sekretariaten in den anderen dagegen im Mittelbau, so daß die Nutzenpotentiale aus der Sicht dieser beiden Organisationseinheiten sich häufig ähneln. Bei allen Fragestellungen sollten die erstellten Prozeßketten und Funkti-onsbäume zu Rate gezogen werden.
Als Abschluß findet man ein Aufzählung aller Einwände der interviewten Bereiche, also eine Art Forum für die Meinungsvielfalt an der WU-Wien. Hier möchten die Autoren be-sonders allen Teilnehmern für ihre engagierte Mitarbeit danken.
Auf Ergebnisse des Grobkonzepts, das als Anhang vorliegt, wird im folgenden des öfte-ren verwiesen werden.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 47 von 163
4.1.2 Studien
P
Rück-meldungStudium
*
P
Zusatzstudium/Wechsel des
Studiums*
P
BeendigungStudium
*
P
ZulassungStudium mit bes.Voraussetzung
P
ZulassungStudium mit Be-
rechtigungsprüfungP
ZulassungStudium mit ind.
StudiengangP
ZulassungStudium
mit Auflagen
P
ErstellungDiplomzeugnis
Studium mit allg.Voraussetzung
Studium mit bes.Voraussetzung
Studium mit Be-rechtigungsprüfung
Studium mit ind.Studiengang
Studium mitAuflagen
ZulassungStudium mit allg.Voraussetzung* P
ZulassungStudium
Rück-meldungStudium
Studien-wechsel
BeendigungStudium
P
Rück-meldungStudium
*Zusatzstudium/
Wechsel desStudiums
P*
BeendigungStudium
P*
P
ErstellungDiplomzeugnis
P
Rück-meldungStudium
*
* P
Zusatzstudium/Wechsel des
Studiums
P*
BeendigungStudium
ErstellungDiplomzeugnis
P
Rück-meldungStudium
P*Zusatzstudium/
Wechsel desStudiums
P*
P
BeendigungStudium
*
P
ErstellungDiplomzeugnis
P
Rück-meldungStudium
*
P
Zusatzstudium/Wechsel des
Studiums*
P
BeendigungStudium
*
P
ErstellungDiplomzeugnis
Abbildung 18: PAM „Studium“
Bemerkungen:
Angestrebt wird eine umfangreichere Kommunikation der Studenten mit der DV-Welt und die damit verbundene Erleichterung von Routineaufgaben in der STAB. Datenein-gaben werden z.B. über Internet möglich sein, Bezahlungen und Rückmeldungen mit der Studentenausweis -Chipkarte oder auch über Internet, Studienwechsel können sys-temunterstützt direkt vom Studenten durchgeführt werden. Bei der Beendigung des Studiums werden Folgeaktivitäten automatisch angestoßen. Wichtig ist ein Umden-kungsprozeß der Studenten, daß Termine mit der STAB einzuhalten und zu vereinbaren sind – letztendlich zum Wohl aller, da dann ein schnellerer reibungsloser Ablauf garan-tiert werden kann.
Siehe auch Kapitel 5.2 im Grobkonzept.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 48 von 163 Erstellt gemeinsam m it 15. April 1998
4.1.2.1 Zulassung Studium
(Zulassung Studierende mit allg. Voraussetzungen, Zulassung Studierende mit bes. Voraussetzungen, Zulassung Studierende mit Studienberechtigungsprüfung, Zulassung Studierende mit Nostrifikationsauflagen, Zulassung Studierende mit indiv. Diplom-studiengang)
ZulassungStudium
Studien- undPrüfungsabteilung
(STAB)Studium
Student/-in
Abbildung 19: Funktionszuordnungsdiagramm „Zulassung Studium“
Bemerkungen:
Zulassungen von Studenten sollten in Zukunft nur mit vorheriger Terminvereinbarung systemunterstützt zwischen der STAB und den Studenten stattfinden. Ein Großteil der Datenmenge wäre also beim Zu lassungsantrag vom Studenten ins System zu stellen, und ein Termin würde vom Studenten ausgewählt werden. Leider muß man, um einen Mißbrauch der Terminvereinbarung auszuschließen, diesen Antrag direkt mit der Za h-lung eines Kostenbeitrages (ÖH-Beitrag) verbinden. Die Zulassungsprozedur sieht da-her die Integration von Kreditkartenzahlungen bei der Einwahl über Internet oder Quick-Card-Bezahlung bei Zugriff über WU-eigene Terminals vor. Sollte dies Probleme berei-ten, wäre als Serviceeinrichtung in der STAB ein Schalter zur Betreuung für Studenten ohne Termin einzurichten (dies ist auf jeden Fall sinnvoll in der Phase der Systemein-führung).
Wichtig ist die Vergabe einer vorläufigen Kennung, die der Student zur Anmeldung bei Lehrveranstaltungen erhalten sollte – gerade für Studenten aus dem Ausland (Aus-tauschstudenten) ein von der ZAS geforderter Service. Sollte die Zulassung nicht inner-halb einer festgesetzten Frist erteilt werden, erlöschen diese Anmeldungen.
Nach Erteilung der Zulassung am Schalter wird von der STAB eine Chipkarte als Stu-dentenausweis ausgegeben, die neben der Legitimationsfunktionalität auch Zahlungs-funktionen integriert. Die Karte sollte als Rohling von der STAB mit den notwendigen Daten und den digitalen Lichtbildern der Studenten – auch in einer Servicestelle der WU
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 49 von 163
(am besten direkt in der STAB) aufgenommen – nur noch bestückt werden (Variante 1 des Grobkonzepts). Die Chipkartenbetreuung sollte auch in der STAB angesiedelt sein.
Unterschieden wird in den Prozessen zwischen einer Zulassung mit allg. Zulassungs-voraussetzungen und mit besonderen Zulassungsvoraussetzungen, wobei letztere Rahmenbedingung die Integration der StabDat in das neue System erfordert mit um-fangreichen Drag- und Drop-Funktionalitäten und Layout-Gestaltungsmaßnahmen. Wei-tere Prozeßszenarien wurde geschaffen mit der Zulassung mit Nostrifikationsauflagen, der Zulassung mit Studienberechtigungsprüfung und der Zulassung zum individuellen Diplomstudiengang, in der unter Umständen das Rektorat und die Studienkommissio-nen befragt werden müssen. Bei der Zulassung mit Auflagen zum Ziel der Nostrifikation sollte eine Fristverlängerung durch die STAB möglich sein; auch sollte der Student an das Fristende über E-Mails erinnert werden.
Siehe auch Kapitel 5.2.3 im Grobkonzept.
Nutzenpotential: Zulassung Studium
Verwaltung
Plus STAB: Abschaffung des Studienblattes
STAB: Kontakttermine werden im voraus elektronisch vereinbart - optimale Kapazi-tätsauslastung möglich
STAB: Zulassungsdaten der Studenten werden im voraus im System eingegeben – geringe Dateneingabe und Datenverwaltung in Papierform mehr.
STAB: Plausibilitätsprüfungen finden beim Dateneintrag im System automatisch statt.
STAB: statistische Auswertungen können direkt durch das System vorgenommen werden - Eintrag von Codierungen (zumindest eines großen Teiles) fallen weg.
STAB: kein manueller Datenabgleich zwischen STEP und STAB-DAT mehr nötig (Funktionen integriert in 2gether).
STAB: keine Verschickung von Semesteretikett nötig .
STAB: neue Terminvereinbarung mit zurückgestellten Studenten wird systemunter-stützt möglich sein.
STAB: Groupware-Funktionalitäten beschleunigen Genehmigungsverfahren bei ind. Di-plomstudiengängen und Studienberechtigungsprüfungen.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 50 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Zulassung Studium
STAB: Prüfungsbescheid mit Fächern wird automatisiert erstellt.
STAB: Analysen bzgl. Studienberechtigungsprüfungen können aus dem System abge-rufen werden.
STAB: statistische Analysen umfangreich möglich über ‘2gether’ - bisher in der STAB-DAT nur beschränkt möglich.
STAB: ‘2gether’ wird die Aufnahme mit Auflagen zum Studium (z.B. Fachhochschulab-solventen zu Doktoratsstudium mit Auflagen) unterstützen müssen, was bisher nicht von STEP unterstützt wurde.
Minus STAB: möglicherweise Mißbrauch des Fernzulassungsantrags (z.B. über Internet), da
eine Legitimierungsüberprüfung unmöglich ist. Falsche systemunterstützte Termini erung ist zu überprüfen (eingeschränkt bei ÖH-Betragsabbuchung beim Zulassungswunsch).
STAB: möglicherweise mangelnde Auslastung bei Nichterscheinen der Studenten zu den Terminen.
STAB: Abweisung von Studenten ohne Termin problematisch (zumindest in der Anfangs-phase).
STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitar-beiterumschulung.
STAB: digitale Lichtbilder müssen angefertigt werden.
ZID
Plus kein Druck der Zulassungsunterlagen nötig (Studienblatt, Semesteretikett, Zahlschein
etc.)
Studierende
Plus Schnellere Zulassung
Fernzulassungsantrag möglich
Schnellere Bearbeitungszeit am Schalter
Durch Terminierung geringere Wartezeit vor dem Schalter
Mehr Zahlungsmöglichkeiten durch Chipkarte
ÖH: automatische Rückerstattung des ÖH-Beitrags bei zurückgewiesenen Studenten
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 51 von 163
Nutzenpotential: Zulassung Studium
Minus Daten zur Zulassung müssen selbst in ‘2gether’ eingetragen werden
Zusätzlich zum Studentenausweis muß ein „wallet“ zur Authentifizierung außerhalb der Universität (Kinos etc.) finanziert werden.
4.1.2.2 Rückmeldung Studium
(Rückmeldung Studierende mit Zahlschein, Rückmeldung Studierende ohne Zahl-schein)
P*
Rück-meldungStudium
Studien- undPrüfungsabteilung
(STAB)
Student/-in
ZIDStudium
Abbildung 20: Funktionszuordnungsdiagramm „Rückmeldung Studium“
Bemerkungen:
In Prozeßketten (eEPK) wird die Rückmeldung der Studenten in zwei Szenarien be-schrieben; zum einen für eine Rückmeldung ohne Zahlschein, zum anderen für eine Rückmeldung mit Zahlschein.
Bei einer Rückmeldung ohne Zahlschein wird die Bezahlung des ÖH-Beitrags und die Rückmeldung über Internet oder WU-interne Terminals vorgenommen; im ersten Fall muß ein Karteneintrag der Rückmeldung nachträglich von den Studenten am System vorgenommen werden können. Bei Bezahlung mit Zahlscheinen mit Scancodes erfolgt der Dateneintrag der Bezahlung über einen Datenabgleich mit der Bank - Vermerk der Rückmeldung im Ausweis muß vom Studenten auch hier direkt an den WU-Terminals nachgetragen werden. Bezahlungen mit Zahlscheinen ohne Scancodes sollten die Aus-
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 52 von 163 Erstellt gemeinsam m it 15. April 1998
nahme bilden, da sich der Verwaltungsaufwand sehr umfangreich darstellt. Wichtig sind zur Rückmeldung automatisch vom System generierte Erinnerungsfunktionalitäten, als auch die Möglichkeit der Prüfung der Rückmeldung online im System durch die Studen-ten. Sowohl Rückmeldungen ohne Bezahlung des ÖH-Beitrags (bei Zulassung an ande-ren Universitäten), als auch Bezahlungen ohne Rückmeldung sollten möglich sein.
Siehe auch Kapitel 5.2.4 im Grobkonzept.
Nutzenpotential: Rückmeldung Studium
Verwaltung
Plus STAB: keine Datenüberspielung der Bankdaten anzustoßen (bei Bezahlung mit Zahl-
schein mit Scancode)
STAB: Rückmeldung und Bezahlung des ÖH-Beitrags in den meisten Fällen ohne Schal-terbetreuung der Studenten
STAB: automatische Ermahnung wird an Studenten geschickt beim Erreichen des Rück-meldefristendes minus einer Woche
STAB: Rückmeldemerkmal wird auf Chipkarte automatisch gesetzt (Ansicht über „wal-lets“)
Minus STAB: Betreuung der Studenten am Schalter nötig bei Rückmeldung über Internet (Chip-
karteneintrag der Rückmeldung), falls automatischer Chipkarteneintrag fehlschlägt (wie heute über Reklamation zu lösen).
Studierende
Plus Rückmeldung ohne Zahlschein möglich
Fernrückmeldung möglich
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 53 von 163
4.1.2.3 Zusatzstudium/Wechsel des Studiums
P*
Zusatzstudium/Wechsel des
StudiumsStudent/-in
Studien- undPrüfungsabteilung
(STAB)
Studium
Lehrver-anstaltung
Prüfung
Anerkennung
Studienplan
Abbildung 21: Funktionszuordnungsdiagramm „Wechsel Studium/Aufnahme Zusatzstudi-um“
Bemerkung:
Bei Wechsel und Aufnahme von Studien innerhalb der WU-Wien sollte zuerst von den Studenten am Terminal überprüft werden, ob eine automatisch generierte Anerkennung von Studienleistungen und Aufnahme des neuen Studiums möglich ist. Nur - und das sollte eine Minderheit der Fälle betreffen - bei Negation des Systems ist die STAB zu kontaktieren, die dann die Entscheidung zu treffen hat.
Bei der Genehmigung durch das System werden vorher alle Voraussetzungen des Stu-denten geprüft und daraus die notwendigen Aktionen abgeleitet. Kann das System die entsprechenden Wünsche des Studenten nicht vollziehen, sollte eine Ablehnung ange-zeigt werden.
Siehe auch Kapitel 5.2.5 im Grobkonzept.
Nutzenpotential: Zusatzsturium/Wechsel des Studiums
Verwaltung
Plus STAB: Automatische Prüfmöglichkeit für Studenten durch das System, ob Studienwech-
sel oder Zusatzstudium möglich ist.
STAB: Dateneintrag für Studienwunsch direkt durch die Studenten am System.
STAB: Automatische Leistungsanrechnungen für Ergebnisse, die an der WU erbracht wurden (im Normalfall).
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 54 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Zusatzsturium/Wechsel des Studiums
STAB: Keine Schalterbetreuung der Studenten nötig (im Normalfall).
STAB: Zulassungsbestätigung wird vom Student ausgedruckt.
Studierende
Plus Studienwechsel und Zusatzstudium schnell direkt am System.
Prüfungen über verschiedene Studienszenarien direkt am System.
4.1.2.4 Beendigung Studium
(Beendigung des Studiums, Beendigung des Sonderstudiums)
P*
BeendigungStudium
Student/-in
Studien- undPrüfungsabteilung
(STAB)
Bibliothek
ZID
Institut/Abteilung
Studium
Abbildung 22: Funktionszuordnungsdiagramm „Beendigung Studium“
Bemerkungen:
In der Prozeßkette „Beendigung des Studiums“ (eEPK) kann man den gewünschten Ab-lauf zur Studienbeendigung verfolgen. Natürlich müssen bei Studienbeendigung Folge-aktivitäten angestoßen werden, die aufgrund der sehr dezentralen Verteilung idealerwei-se von dem System angesteuert und verwaltet werden sollten - z.B. per Jobverteilung.
Unterstützung findet z.B. die STAB durch Erinnerungsfunktionalitäten des Systems, das informiert, wenn die Voraussetzungen der Beendigung des Studiums für einen Studen-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 55 von 163
ten gegeben sind. Auch werden einige Bescheide (Abgangsbescheide, Feststellungs-bescheide) in Zukunft direkt vom Studenten am System ohne größeren Verwaltungs-aufwand ausgedruckt werden können .
Hier, wie auch teilweise in den anderen Prozessen, böte sich eine Unterstützung durch eine Workflow-Funktionalität an, da eine starre Ablaufstruktur mit relativ hohem Men-gengerüst bearbeitet wird.
Die Prozeßkette „Beendigung des Sonderstudiums“ beschreibt die leicht geänderte Si-tuation bei Studien mit Auflagen, Studien mit Studienberechtigungsprüfungen und indivi-duellen Diplomstudiengängen (zu beachten: Sonderstudien ist ein nur vom Projektteam der Beratungsunternehmen definierter Begriff zur kürzeren Prozeßetikettierung).
Siehe auch Kapitel 5.2.6 im Grobkonzept.
Nutzenpotential: Rückmeldung Studium
Verwaltung
Plus STAB: Salden der Abrechungskonten werden direkt am System geprüft.
STAB: Deaktivierung des Studentenstammsatzes, Chipkartendeaktivierung und Generie-rung des Abgangsbescheids erfolgt automatisch.
STAB: automatische Abmelde-Information (per E-Mail) wird an entsprechende Stellen verschickt - z.B. um Powernetkennung zu löschen.
STAB: automatische Prüfung, ob erzwungene Abmeldung erfolgen muß, und Einleitung von Schritten.
STAB: Abgangsbescheinigung und Feststellungsbescheid werden vom Studenten selbst ausgedruckt.
Minus STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitar-
beiterumschulung.
Quästur
Plus Kontenabrechnung wird automatisch angestoßen und ausgeführt.
Studierende
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 56 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Rückmeldung Studium
Plus Abmeldungswunsch kann direkt am System erfolgen ohne Schalterkontakt.
Fernabmeldung möglich
keine „Stellenrundgang“ nötig (PowerNet-Kennung löschen, Kontenabrechnung etc.).
4.1.2.5 Erstellung Diplomzeugnis
P
ErstellungDiplomzeugnis
StudiumStudiendekan/
Vizestudiendekan
Studien- undPrüfungsabteilung
(STAB)
Student/-in
Abbildung 23: Funktionszuordnungsdiagramm „Erstellung Diplomzeugnis“
Bemerkung:
Auch die Diplomzeugniserstellung kann durch das System sinnvoll unterstützt werden, zieht man in Betracht, daß das Studiendekanat eingebunden werden kann durch direkte Jobvermittlung. Während hier das Mengengerüst (ca. 1200/a) eine vorgegebene Ab-laufunterstützung fordert, können bei der Verleihung des Doktortitels (ca. 100/a) auch Ad-hoc-Funktionalitäten des Systems zum Zuge kommen.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 57 von 163
4.1.3 Lehrveranstaltungen
*
Lehrver-anstaltungen
*
Planung vonLehrver-
anstaltungen
*
Aufnahme vonLehrver-
anstaltungen
*
Lehrver-
anstaltungenadministrieren
Abbildung 24: Funktionsbaum „Lehrveranstaltung“
Bemerkungen:
Geplant ist eine Einbindung aller LV-Leiter bei der Eingabe der Daten zur Lehrveranstal-tung direkt in das System 2gether. Natürlich wird eine Akzeptanz kritisch von der An-wenderfreundlichkeit des Systems und von der Vertrautheit dem System gegenüber ab-hängen sowie von umfangreichen Zugriffsmöglichkeiten. So sollte ein Dateneintrag auch von außerhalb der WU-Wien über das Internet möglich sein, um externe Dozenten ein-beziehen zu können. Durch die tägliche Arbeit mit dem System ‘2gether’ über Groupwi-se-Funktionalitäten, wie Jobverwaltung, Terminplanung und E-Mail-Verwaltung, und un-terstützende Module bei der Administration der Lehrveranstaltung (siehe das Modell „Lehrveranstaltungen administrieren“) sollte eine intuitive Benutzerführung für den LV-Leiter gegeben sein. Natürlich kann der LV-Leiter seine Tätigkeiten am Institut über eine Delegation der Benutzerrechte verwalten lassen; dies sollte jedoch eher die Ausnahme als die Regel sein.
Siehe auch Kapitel 5.3 im Grobkonzept.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 58 von 163 Erstellt gemeinsam m it 15. April 1998
4.1.3.1 Planung von Lehrveranstaltungen
P*
Planung vonLehrver-
anstaltungen
Institut/Abteilung
LV-Leiter/-in
Büro desStudiendekans
Rechts - undOrganisations-
abteilung
Abt.-/Inst.-Leiter/-in
Druckerei
Fachbereich
Studien-dekan
Lehrver-anstaltung
Raum-verwaltung
Studienplan
Vorlesungs-verzeichnis
Abbildung 25: Funktionszuordnungsdiagramm „Planung Lehrveranstaltung“
Bemerkungen:
Der Prozeß, der im Vorfeld des Semesters zur Planung von Lehrveranstaltungen und zur Erstellung des VVZ durchlaufen werden muß, wird in Form einer eEPK wiedergege-ben.
Bei Planung einer Lehrveranstaltung im System sollte auf eine Datenbasis bereits ab-gehaltener Lehrveranstaltungen zurückgegriffen werden können. Eine „Revitalisierung“ dieser Lehrveranstaltungen kann dann jederzeit möglich sein; mitsamt der dazugehöri-gen Anmeldemodalitäten, Beschreibungen, Terminwünsche etc.. Auch eine Präferenz-liste von Hörsälen und Terminen sollte bearbeitet werden, um eine möglichst optimale Zuordnung aller Hörsäle gewährleisten zu können.
Automatisch werden die vor zwei Semestern stattgefundenen Lehrveranstaltungen zur Erstellung des VVZ berücksichtigt, in denen nur die Daten korrigiert werden müssen. Bei der Zuordnung der Hörsäle durch die Rechts- und Organisationsabteilung sind mehrere Szenarien möglich. Sinnvoll wäre gewiß eine systemberechnete Optimierung, die jedes Semester durchgeführt werden würde, einschließlich der damit verbundenen optimalen Auslastung aller Hörsaal-Kapazitäten. Allerdings würden damit liebgewonnene Gewohn-heiten aufgegeben werden müssen - so könnte jedes Semester eine Lehrveranstaltung in einem anderen Hörsaal stattfinden. Sicher wäre das zweite Szenario vorzuziehen, in dem jede Lehrveranstaltung nur bei gewünschter Änderung der Hörsaalzuordnung und bei Neuplanung optimiert vom System einem Raum zugeordnet wird. Unterstützt würde diese Prozedur durch eine Hörsaalbörse, die z.B. in einem Forum des Groupwise-Systems abgewickelt werden könnte, und in der mit Benachrichtigung der Rechts-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 59 von 163
Organisationsabteilung Hörsäle getauscht werden können. Weitere Maßnahmen zur ei-ner Verbesserung der Kapaz itätsausnutzung wären eine Online-Einsicht in die aktuellen Daten der Hörsaalbelegung und ein Warns ystem bei großer Diskrepanz der Teilnehmer einer Lehrveranstaltung (natürlich auch bei Prüfungen) zu der Hörsaalkapazität - auf-grund dieses Sachbestandes könnte automatisch eine Nachricht an den Studiendekan generiert werden, der weitere Schritte einzuleiten hätte. Während des Semesters wäre wegen einer Raumbelegung bei der Hörsaalverwaltung anzufragen, die eine Service-stelle für die Institute/Abteilungen bilden sollte – also auch bei kurzfristigem Ausfall einer Lehrveranstaltung für Informationen direkt am Hörsaal sorgen sollte.
Vorteilhaft wäre für die Institute/Abteilungen auf jeden Fall die immer – auch im Semes-ter – gegebene Einsichtsmöglichkeit in aktuelle Daten zu den Lehrveranstaltungen, da das VVZ im Internet ständig aus dem System heraus aktualisiert werden würde mit au-tomatisch generierten Links zu den Internetseiten der Institute/Abteilungen. Somit wäre der Versorgung des Informationsbedarfs der Studenten bei Wartung der Daten im Sys-tem Sorge geleistet. Auch eine Papierversion des VVZ sollte am Anfang des Semesters gedruckt werden, damit auch an nicht computerunterstützten Lokalitäten – wie z.B. Bushaltestellen – eine Einsicht und Suche in angebotene Lehrveranstaltungen möglich wäre.
Aufgrund der zu erwartenden schnelleren Durchlaufzeit bei der Erstellung des VVZ - kein Hausposttransport von Fahnen, Waschzetteln etc. zur Korrektur, systemunter-stützte Abfragemöglichkeiten im System bzgl. Hörsaalbelegung, Datenvollständigkeit und Korrektheit des Lehrveranstaltungsspektrums und weltweiter Zugriff auf die Daten - kann der Beginn der Planung deutlich näher an den Semesterbeginn gelegt werden, womit wiederum akkuratere Daten eingetragen werden können. Auch werden planungs-relevante Einträge im System – wie z.B. Anmeldefristen, max. Teilnehmerzahl, Anmel-demodalitäten – von den Instituten/Abteilungen durchgeführt werden, so daß Anmel-dungen bis kurz vor Vorlesungsbeginn und auch darüber hinaus möglich sein werden und so die Bearbeitung von Nachmeldefristen größtenteils wegfallen kann.
Ein wichtiges Werkzeug zur Unterstützung der Planung von Lehrveranstaltungen bildet die Budgetsimulation, in der die Berechnung von Kostenwerten zu möglichen Lehrver-anstaltungsszenarien systemgeneriert durchgeführt werden kann, und so Institute, aber auch die Fachbereiche und das Studiendekanat schnell an wichtige Kontrolldaten ge-langen können. Natürlich sind auch andere Regelhinterlegungen bei Prüfungsdefinition denkbar – so z.B. die Prüfung der Vollständigkeit des Lehrangebots und der Vermeidung von Überschneidungen. Um diese Prüfungen systemunterstützt durchführen zu können ist die Wartung der Studienpläne im System unbedingt erforderlich – dies sollte von der STAB durchgeführt werden mit einer Drag- and Drop-Funktionalität auf Systemseite.
Siehe auch Kapitel 5.3.1 im Grobkonzept.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 60 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Planung von Lehrveranstaltungen
Institute/Mittelbau
Plus Erinnerung bzgl. Beschreibung einer neuen LV und bzgl. Erhebungsbogen eines neuen
LV-Leiters wird automatisch zugestellt.
Lehrveranstaltungsankündigung, Erhebungsbogen und Remunerationsantrag können direkt am System bearbeitet und per E-Mail weitergeleitet werden (keine Hauspost).
Erhebungsbogen und Lehrveranstaltungsankündigung brauchen (im Normalfall) nicht mehr verwaltet werden (wird direkt vom LV -Leiter bearbeitet ).
Budgetsituationen können schon bei der Grobplanung des VVZ überprüft werden.
Verifizierung der VVZ-Daten in der Grobplanung braucht (im Normalfall) nicht mehr verwal-tet zu werden (wird vom LV-Leiter direkt bearbeitet).
Simulationen versch. Szenarien sind immer möglich - Überprüfung von Budget-Rahmenwerten.
Kommentar zu Lehrveranstaltungen werden direkt im System gepflegt und sind im VVZ abrufbar.
Institute/Sekretariate
Plus Lehrveranstaltungsankündigung, Erhebungsbogen und Remunerationsantrag können
direkt am System bearbeitet und per E-Mail weitergeleitet werden.
Budgetsituationen können schon bei der Grobplanung des VVZ überprüft werden (per automatischer Überprüfung).
Verifizierung der VVZ-Daten in der Grobplanung braucht (im Normalfall) nicht mehr verwal-tet werden (wird vom LV-Leiter direkt bearbeitet).
keine Verschickung der VVZ-Versionen mehr nötig (1.Version oder spätere Versionen) - direkte Eingabe in das System.
Automatische Erstellung von Adressenangaben auf den zu versendeten Dokumenten bei LV-Leitern ohne E-Mail.
Simulationen versch. Szenarien sind immer möglich - Überprüfung von Budget-Rahmenwerten.
Keine „Waschzettel“ und „Fahnen“ mehr zu bearbeiten.
Minus bei manchen (meist externen) LV-Leitern werden häufig die Daten von den Sekretariaten
ins System eingegeben werden müssen - bisher wurden die in Schriftform vorliegenden Daten an die Verwaltung zur Verwertung weitergegeben.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 61 von 163
Nutzenpotential: Planung von Lehrveranstaltungen
Verwaltung
Plus Rechts- und Organisationsabteilung: keine Papierverwaltung bzgl. Erhebungsbögen und
Lebenslauf mehr notwendig.
Rechts- und Organisationsabteilung: kein Druck der Lehrveranstaltungsankündigungen.
Rechts- und Organisationsabteilung: keine Papierverwaltung der Lehrveranstaltungsan-kündigungen.
Rechts- und Organisationsabteilung: kein Ausdruck und Zuschicken des Grobplanungs-VVZ (an externe Druckerei) mehr notwendig.
Rechts- und Organisationsabteilung: keine Eingabe der Institutsdaten zur Erstellen des Grobplanungs-VVZ mehr nötig.
Rechts- und Organisationsabteilung: bei Vollständigkeits- und Korrektheitsprüfungen werden fehlerhafte LV-Beschreibungen automatisch aufgelistet.
Rechts- und Organisationsabteilung: Hörsaalvergabe wird durch das System unterstützt.
Rechts- und Organisationsabteilung: kein Ausdruck der 1.Version VVZ zur Korrektur nötig.
Rechts- und Organisationsabteilung: keine Eingabe der Institutsdaten zur Erstellen des 1.Verson und freigegebener Version des VVZ mehr nötig.
Minus Erinnerungsmail ist den Instituten zur Überarbeitung des Grobplanungs -VVZ zustellen (E-
Mail) - wird automatisch für alle Institute generiert (nur auszulösen).
Studiendekanat
Plus keine Papierverwaltung der Remunerationsanträge notwendig.
keine Papierverwaltung bzgl. der LV -Kontingenterhebung nötig.
Budgetsituationen können automatisch überprüft werden.
Allgemein
Plus Planungsprozeß des VVZ wird wesentlich beschleunigt.
Studierende
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 62 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Planung von Lehrveranstaltungen
Plus Einsicht in das VVZ schneller möglich und direkt über das Internet (mit anspruchsvoller
Gestaltung der Web-Seiten).
Fachbereiche
Plus Budgetsituationen können automatisch überprüft werden.
4.1.3.2 Aufnahme von Lehrveranstaltungen
P*
Aufnahme vonLehrver-
anstaltungen
LV-Leiter/-in
Institut/Abteilung
Rechts - undOrganisations-
abteilung
ZID
Lehrver-anstaltung
Abbildung 26: Funktionszuordnungsdiagramm „Aufnahme Lehrveranstaltung“
Bemerkungen:
Alle Aktivitäten, die am Anfang der Durchführung einer Lehrveranstaltung stehen, sind in einer eEPK festgehalten.
Geplant ist der Wegfall der LV-Beginnmeldungen. An ihre Stelle tritt die automatische Versendung von Beauftragungsbescheiden per E-Mail zwecks Information der LV-Leiter und die Quittierung der LV-Aufnahme mit elektronischer Unterschrift im System von den LV-Leitern. Eine Reduzierung dieses Arbeitsgebietes auf eine Quittierung nur bei Nicht-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 63 von 163
aufnahme einer Lehrveranstaltung läßt sich leider aus rechtlichen Gründen momentan nicht fordern.
Eine Quittierung der Teilnehmerzahl nach ca. 4-5 Wochen nach Beginn der Lehrveran-staltung erscheint sinnvoll im Hinblick auf spätere Planungsaktivitäten und einer automa-tischen Generierung von Teilen des Evaluierungsreports aus dem System heraus.
Siehe auch Kapitel 5.3.2 im Grobkonzept.
Nutzenpotential: Aufnahme von Lehrveranstaltungen
Institute/Mittelbau
Plus Keine Kontaktaufnahme zum LV-Leiter und Zusendung der LV-Beginnmeldungen nötig.
Kein Einsammeln der LV-Beginnmeldungen von den LV-Leitern nötig (im Normalfall)
Kein Bearbei ten von LV-Beginnmeldungen mehr.
Hörereintrag und Quittierung der Aufnahme der LV im System ‘2gether’ dient direkt den Evaluierungsberichten und Arbeitsberichten der Institute.
Ständig Information über aktuellen Stand des VVZ im Internet.
Schnellere Bezahlung der LV-Leiters wg. Wegfall der Beginnmeldung in Papierform.
Bearbeitung und Verwaltung der „Teilnehmerliste“ (Meldung der Höreranzahl an das Stu-diendekanat) fällt weg.
Institute/Sekretariate
Plus Keine Kontaktaufnahme zum LV-Leiter und Zusendung der LV-Beginnmeldungen nötig.
Kein Weiterleiten der Dokumente an die Rechts- und Organisationsabteilung nötig.
kein Dateneintrag in einem DV -System (z.B. Wufis) nötig (im Normalfall).
keine Bearbeitung von LV-Beginnmeldungen mehr.
Bearbeitung und Verwaltung der „Teilnehmerliste“ (Meldung der Höreranzahl an das Stu-diendekanat) fällt weg.
Verwaltung
Plus Rechts- und Organisationsabteilung: automatisch generierte E-Mail (Beauftragungsbe-
scheide) an den LV-Leiter anstatt der Erstellung und Versendung der schriftlichen LV-Beginnmeldungen an die Institute (im Normalfall).
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 64 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Aufnahme von Lehrveranstaltungen
Rechts- und Organisationsabteilung: automatische Selektion der nicht bearbeiteten Lehr-veranstaltungen
Rechts- und Organisationsabteilung: keine Einmahnungen an die Institute
Rechts- und Organisationsabteilung: automatische Generation der Benachrichtigung an den Studiendekan (nur Freigabe der automatisch generierten E-Mail)
Rechts- und Organisationsabteilung: kein Anstoß zur Datenübernahme zwischen WUFIS und STEP nötig
Rechts- und Organisationsabteilung: kein Vergleich der LV -Beginnmeldungen und den Einträgen im STEP-System nötig
Rechts- und Organisationsabteilung: keine Bearbeitung von zurückgemeldeten LV-Beginnmeldungen mehr.
ZID
Plus kein Druck der LV -Beginnmeldungen nötig
4.1.3.3 Lehrveranstaltungen administrieren
F*
Lehrver-anstaltungen
administrieren
Lehrver-anstaltung
Institut/Abteilung
LV-Leiter/-in
Student/-in
Studien-dekanat
Abbildung 27: Funktionszuordnungsdiagramm „Administration Lehrveranstaltung“
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 65 von 163
Bemerkungen:
Aufgeführt in einem Funktionsbaum sind die wesentlichen Funktionalitäten, die ein zu-künftiges System zur Administration der Lehrveranstaltungen anbieten sollte.
Über die Anmeldelisten lassen sich wesentliche Daten zur Beschreibung der Leistung der Teilnehmer erfassen, wie z.B. Anwesenheit, Zwischennoten, Endnoten. Das Layout dieser Listen im System sollte von Seite der Institute/Abteilungen definierbar sein; inte-ressant wäre eine Tabellenstruktur, deren Köpfe entsprechend den Anforderungen eti-kettiert werden könnten. Auch eine Vorgabe der tatsächlichen LV-Termine im Semester wäre sinnvoll (wobei Feiertage und Rektoratstage etc. schon bereinigt wären). Wichtig ist eine intuitive Benutzerführung und die Möglichkeit der Datenfreigabe der Einträge zwecks Information der Studenten.
Siehe auch Kapitel 5.3.3 im Grobkonzept.
4.1.4 Prüfungen
Prüfungen
*
Planung vonPrüfungen
*
Leistungs-feststellung
*
Abbildung 28: Funktionsbaum „Prüfung“
Bemerkungen:
Angestrebt wird, ein virtuelles Prüfungsamt im System abzubilden. Dazu sollten Tätig-keiten der Prüfungsreferate der STAB auf die systemunterstützte Mitarbeit der Studen-
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 66 von 163 Erstellt gemeinsam m it 15. April 1998
ten umgelegt werden. Hinzukommen sollte die Mitarbeit der Prüfer an den Abteilun-gen/Instituten, die die relevanten Daten direkt in das System eingeben.
Siehe auch Kapitel 5.4 im Grobkonzept.
4.1.4.1 Planung von Prüfungen
P*
Planung von
Prüfungen
LV-Leiter/-in
Büro des
Studiendekans
Studien- undPrüfungsabteilung
(STAB)
Hörsaal-verwaltung
Prüfung
An- und
Abmeldung
Raum-verwaltung
Abbildung 29: Funktionszuordnungsdiagramm „Planung Prüfungstermin“
Bemerkungen:
Regelmäßig stattfindende Prüfungen werden schon automatisch vorgeplant im System und im WU-Kalender entsprechend festgehalten. Alle unregelmäßig stattfindenden Prü-fungen sollten vorher, über die Hörsaalverwaltung, einen Termin mit Raumbelegung re-serviert bekommen – bei der Absprache können Groupware-Eigenschaften des zukünf-tigen Systems eingesetzt werden.
Zur Unterstützung der Erstellung von Prüfungsunterlagen sollten Ausdrücke („Deckblät-ter“) aus dem System möglich sein mit den Personalien und den Terminen des Prüf-lings – diese können dann den Prüfungsfragen oder bei mündlichen Prüfungen dem Prüfungsprotokoll beigefügt werden.
Die Prüfer sollten direkt die Daten in das System eingeben – auch hier ist ein Datenein-trag über das WWW vorzusehen, um externe Prüfer miteinzubeziehen.
Siehe auch Kapitel 5.4.1 im Grobkonzept.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 67 von 163
Nutzenpotential: Planung von Prüfungen
Institute/Mittelbau
Plus Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsalgorith-
men)
bei generierter Anmeldeliste Unterscheidung, ob mündliche oder schriftliche Prüfung er-folgen soll.
Deckblätter bei Unterlagen für Prüfungen (mit Personaldaten) werden automatisch erstellt aus dem System heraus.
Daten der Prüfungen sollten direkt vom Prüfer in das System eingegeben werden (keine schriftliche Datenweitergabe mehr).
maximale Teilnehmerzahl muß nach Hörsaal-Vergabe automatisch auf die max. Kapazi-tät des Hörsaals beschränkt werden.
aktuelle Informationen über Anmeldeliste im System - keine Papierbearbeitung bzgl. Abfragen mehr nötig.
Bestimmung der Anmeldefristen etc. durch das Institut selbst (und nicht mehr durch die STAB). Dadurch können Nachmeldefristen vermieden werden.
Minus Planungstermine müssen in das System eingegeben werden (bisher teilweise Festlegung
von der STAB).
Institute/Sekretariate
Plus Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsalgorith-
men).
Anmeldelisten werden von den Studenten selbst gepflegt.
Verwaltung
Plus STAB: Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsal-
gorithmen).
STAB: Prüfungsliste muß nicht mehr vor Semesterbeginn erstellt und an die Institute verschickt werden.
STAB: bearbeitete Prüfungsliste muß nicht mehr entgegengenommen werden.
STAB: bearbeitete Prüfungsliste muß nicht mehr für die Hörsaalverwaltung umgeschrie-ben werden.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 68 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Planung von Prüfungen
STAB: die Erstellung des Prüfungskalenders erfolgt vollautomatisch.
STAB: Korrekturen bei Hörsaal - Änderungen müssen nicht mehr eingetragen werden.
STAB: Einträge in das WWW sind nicht mehr nötig.
STAB: Anmeldeformulare zur Prüfung sind nicht mehr zu bearbeiten.
STAB: Zulassungsvoraussetzungen zur Prüfung sind nicht mehr zu prüfen.
STAB: Anmeldeliste für Prüfungen sind nicht mehr zu erstellen und zu verschicken.
STAB: Anmeldeliste der Prüfungen ist nicht mehr auszudrucken und auszuhängen.
Hörsaalverwaltung: Hörsaalvergabe wird durch das System unterstützt (Groupware, Op-t imierungsalgorithmen).
Hörsaalverwaltung: Hörsaalvergabe wird durch das System ständig kontrolliert und bei Fehlern werden Mahnungen verschickt.
Studierende
Plus Fernanmeldung zu Prüfungen möglich.
Kein Anmeldeformular auszufüllen und einzuwerfen.
Kein Einreichen von Sammelzeugnissen nötig.
4.1.4.2 Leistungsfeststellung
P*
Leistungs-feststellung
Institut/Abteilung
LV-Leiter/-in
Prüfung
An- undAbmeldung
Abrechnung
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 69 von 163
Abbildung 30: Funktionszuordnungsdiagramm „Leistungsfeststellung“
Bemerkung:
Die Noteneingabe sollte direkt vom Prüfer am System vorgenommen werden - externe Dozenten können über das Internet auf das System zugreifen. Nach Noteneintrag in ei-ne Liste der dem Prüfer im Semester zugeteilten Prüfungen wird per E-Mail automa-tisch an den Studenten die Benotung verschickt mit Angabe der vom Institut beschlos-senen Einsichtsfrist (nicht zu verwechseln mit der rechtlichen Einsichtsfrist). Notenab-fragen durch die Studenten werden auch jederzeit über IVR und Internet möglich sein, so daß Anfragen in den Instituten/Abteilungen entfallen sollten. Die Auswahl der ange-zeigten Daten sollte vom Prüfer leicht im System zu definieren sein (Anwählen von Ta-bellenköpfen). Zusätzlich wird das zu erwartende Datum der Noteneingabe jederzeit im Internet einzusehen sein.
Nach Abschluß der Einsichtsfrist gibt der Prüfer die Daten mit seiner elektronischen Un-terschrift frei - im Nachhinein sollten nur noch Änderungen mit Genehmigung des Prü-fers eingegeben werden können, wobei fundamentale Änderungen für die Abrechnung der Rechts- und Organisationsabteilung mitgeteilt werden sollten.
Prüfungsprotokolle, bisher in Papierform, müssen nicht mehr bearbeitet werden. Zeug-nisse sollten - soweit angestrebt - von den Studenten direkt vom System ausgedruckt werden mit maschineller Unterschrift (ausgenommen Diplomzeugnisse und Promoti-onszeugnisse).
Siehe auch Kapitel 5.4.2- 5.4.3 im Grobkonzept.
Nutzenpotential: Leistungsfeststellung
Institute/Mittelbau
Plus Nur einmalige Noteneingabe in Instituten - keine zusätzlichen Excel - Listen oder andere
Systemeinträge ( PC-Levis, WUFIS) nötig.
Prüfungsergebnisse werden normalerweise vom Prüfer direkt in das System eingegeben (Delegation möglich).
Prüfungsprotokoll muß nicht mehr bearbeitet werden (Eintrag in BTX, Kontrolle der Aus-drucke, Bestätigung und Unterschrift).
Institute/Sekretariate
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 70 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Leistungsfeststellung
Plus Nur einmalige Noteneingabe in Instituten - keine zusätzlichen Excel - Listen oder andere
Systemeinträge ( PC-Levis, WUFIS) nötig.
Keine Korrektur der von der ADV -Stelle ausgedruckten (aus WUFIS) Prüfungsprotokolle nötig.
Prüfungsergebnisse werden normalerweise vom Prüfer direkt in das System eingegeben (Delegation möglich).
Keine Verwaltung von Interimszeugnisse, Diplomzeugnissen mehr (Stempeln etc.).
Kein Aushändigen von Zeugnisse an Studenten nötig.
Falls Zweiterfassungssysteme zur Notenfestlegung benutzt werden, ist Datenüberspi e-lung in/aus dem System ‘2gether’ (Word, Excel) möglich.
Minus Bei vielen externen Lektoren muß doch der Papierweg gewählt werden. Dies führt dazu,
daß die Sekretariate die Daten eingeben müssen, anstatt das Papier einfach weiterzulei-ten.
Verwaltung
Plus STAB: Daten der ausgefüllten Anmeldelisten/Prüfungsprotokolle brauchen nicht mehr in
STEP eingetragen zu werden.
Minus STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitar-
beiterumschulung.
STAB: Archivierung muß zugriff auf Historie sicherstellen - Bedenken bei Systemwechsel in der Zukunft.
ZID
Plus Kein Ausdruck und Versenden von WUFIS-Daten (BTX) nötig.
Studierende
Plus Automatische Benachrichtigung über Einsichtstermine.
Noteninformation auch über Fernabfrage möglich.
Automatische Benachrichtigung über Ergebnisse.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 71 von 163
4.1.5 Diplomarbeiten/Dissertationen
Diplomarbeiten/Dissertationenvereinbaren
* F
Diplomarbeiten/Dissertationen
betreuen* F
Diplomarbeiten/Dissertationenabschließen
* P
Diplomarbeit/Dissertation
*
Abbildung 31: Funktionsbaum „Diplomarbeit/Dissertation“
Bemerkungen:
Für die Administration der Diplomarbeiten und Dissertationen wird in ‘2gether’ eine eige-ne Datenbank eingerichtet mit den wesentlichen Informationen zu den Abschlußarbei-ten, so daß alle aktuellen Daten zu den laufenden und vorgeschlagenen Diplomarbeiten und Dissertationen hier zu finden sind.
Unterteilt wird in die Themengebiete der Vereinbarung, der Betreuung und der Beendi-gung der Abschlußarbeiten.
Siehe auch Kapitel 5.5 im Grobkonzept.
Nutzenpotential: Diplomarbeiten/Dissertationen
Institute/Mittelbau
Plus Studenten geben Daten direkt in das System ein.
Themendatenbank informiert übersichtlich alle Studenten.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 72 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Diplomarbeiten/Dissertationen
Mustervorlagen ergeben einheitliche Formate der Arbeiten.
Terminabstimmungen und Dokumententransfers können über das System getätigt wer-den.
Informationen über einen stattgefundenen Betreuerwechsel werden automatisch vom System an die Institute versendet.
Institute/Sekretariate
Plus Studenten geben Daten direkt in das System ein.
Mustervorlagen ergeben einheitliche Formate der Arbeiten.
automatische Fristenüberwachung durch das System
Zweitgutachter wird vom Studiendekan direkt am System festgelegt.
Betreuerwechsel kann durch das System unterstützt werden.
Manuelles Karteikartensystem wg. alten Diplomarbeiten, falls vorhanden, fällt weg.
Minus Möglicherweise höherer Wartungsaufwand wegen Nachfrage nach mehr Analysen (erwei-
terte Möglichkeiten durch das System verlangen aktuellere Daten).
Verwaltung
Plus STAB: Formular zur Genehmigung der Arbeit durch das Studiendekanat muß nicht mehr
administriert werden - Abholung durch den Antragsteller, Versendung an Studiendekanat etc.
STAB: Versendung der Exemplare der Doktorarbeit zur Hauptbibliothek, Nationalbiblio-thek erfolgt nicht mehr durch STAB.
STAB: Statistikformulare müssen nicht mehr administriert werden.
STAB: Erfassungsblätter zur Arbeit („Abstracts“) müssen nicht mehr administriert wer-den.
STEP: Rigorosum-Zeugnis, Diplomarbeitszeugnis wird aus dem System ‘2gether’ ausge-druckt - kein händischer Übertrag der Daten zwischen verschiedenen Systemem mehr nötig (bisher nach StabDAT aus STEP).
STAB: Herausragende Arbeiten werden dem Ausseninstitut automatisch gemeldet .
STAB: Daten werden der Abrechnungsstelle automatisch mitgeteilt.
STAB: Automatische Fristenüberwachung durch das System („Erinnerungsfunktion“).
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 73 von 163
Nutzenpotential: Diplomarbeiten/Dissertationen
Studierende
Plus Kein Besuch mehrerer Bearbeitungsstellen zum Erhalt des Sponsionsbescheids nötig.
schnellere Bearbeitungszeit.
Themendatenbank gibt guten Überblick über mögliche Arbeitsgebiete.
4.1.5.1 Diplomarbeiten/Dissertationen vereinbaren
F*
Diplomarbeiten/Dissertationenvereinbaren
Diplomarbeit/Dissertation
Student/-in
Betreuer/-in
Studien-dekan
Institut/Abteilung
Abbildung 32: Funktionszuordnungsdiagramm „Themenvereinbarung“
Bemerkungen:
In einem Funktionsbaum sind die wesentlichen Funktionalitäten des Systems fes tgehal-ten, die bei der Vereinbarung von Diplomarbeiten und Dissertationen zum Einsatz kommen könnten.
Im Mittelpunkt steht die Themendatenbank, aus dem der Student, aber auch Interessen-ten außerhalb der WU-Wien, sich Vorschläge zu einer möglichen Diplomarbeit bzw. Doktorarbeit holen können. Natürlich ist dieses Angebot an die Studenten seitens der In-stitute/Abteilungen keine Pflicht, doch wäre es zum allgemeinen Überblick empfehlens-wert alle Informationen rechtzeitig dort einzutragen. Über eine Stichwortsuche kann der Student sein Interessensgebiet weiter einengen und danach sein Interesse über das System bekunden, das weitere Terminkoordinationen zwischen Student und Insti-
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 74 von 163 Erstellt gemeinsam m it 15. April 1998
tut/Abteilung regelt. Jederzeit sollte der Status der Diplomarbeit (z.B. in Bearbeitung) gepflegt werden und damit abrufbar sein.
Natürlich sollten vom System die Voraussetzungen zur Aufnahme einer Abschlußarbeit, falls möglich, geprüft werden. Jederzeit kann der Zweitgutachter im Falle einer Promoti-on vom Studiendekan vorgeschlagen werden (meist in Absprache mit dem Institut).
Siehe auch Kapitel 5.5.1 im Grobkonzept.
4.1.5.2 Diplomarbeiten/Dissertationen betreuen
F*
Diplomarbeiten/Dissertationen
betreuen
Diplomarbeit/Dissertation
Student/-in
Betreuer/-in
Abbildung 33: Funktionszuordnungsdiagramm „Laufende Betreuung“
Bemerkungen:
In einem Funktionsbaum werden die wesentlichen Funktionalitäten bei der Betreuung der Abschlußarbeiten festgehalten.
Sinnvoll in der Systemunterstützung der Betreuung könnte der Aufbau eines Diskussi-onsforums zur Arbeit sein, in der z.B. Literaturdateien, eine Linkliste im WWW zu the-menverwandten Seiten oder auch verschiedene Versionen der Arbeit abgelegt werden würden.
Im Falle eines Betreuerwechsels durch den Studenten würden alle betreuenden Perso-nen informiert, wodurch das Aufkommen von „Datenleichen“ vermindert werden könnte.
Siehe auch Kapitel 5.5.2 im Grobkonzept.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 75 von 163
4.1.5.3 Diplomarbeiten/Dissertationen abschließen
P*
Diplomarbeiten/Dissertationen
abschließen
Studiendekan/Vizestudiendekan
Betreuer/-in
Student/-inStudium
Diplomarbeit/Dissertation
Abrechnung
Abbildung 34: Funktionszuordnungsdiagramm „Einreichung, Beurteilung und Veröffentli-chung“
Bemerkungen:
In der Prozeßkette (eEPK) kann detailliert der mögliche Ablauf einer Abgabe von Abschlußarbeiten abgelesen werden. Auch hier bietet sich aufgrund der hohen Dezen-tralität eine Unterstützung mit einem im System integrierten Workflow-Tool an, das die Folgeaktivitäten nach Abgabe koordiniert.
Siehe auch Kapitel 5.5.3 im Grobkonzept.
4.1.6 An- und Abmeldungen
LV-Anmeldungen
Abmeldungen
Prüfungs-anmeldungen
*
Lehrveranstal-tungsan- und -abmeldung
*
Prüfungs-an- und
-abmeldung
*
Einzel-anmeldungen
*
Sammel-anmeldungen
*
Einzel-abmeldungen
Abmeldungen
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 76 von 163 Erstellt gemeinsam m it 15. April 1998
Abbildung 35: PAM „An- und Abmeldung“
Bemerkungen:
Anmeldungen und Abmeldungen zu Lehrveranstaltungen und Prüfungen können vom System ideal unterstützt werden. Voraussetzung dazu ist natürlich die exakte Pflege der Studienpläne im System durch die STAB.
Siehe auch Kapitel 5.6 im Grobkonzept.
4.1.6.1 LV-Anmeldungen
F
LV-Anmeldungen
LV-Leiter/-in
Student/-inLehrver-
anstaltung
An- undAbmeldung
StudiumStudien- und
Prüfungsabteilung(STAB)
Abbildung 36: Funktionszuordnungsdiagramm „Lehrveranstaltungsanmeldung durchfüh-ren“
Bemerkungen:
Einen Überblick über die wichtigsten Funktionalitäten einer Anmelde-Unterstützung durch ein System bietet der Funktionsbaum „LV-Anmeldungen“.
Bei der Anmeldung der Studenten zu Lehrveranstaltungen finden auf Systemseite ver-schiedene Überprüfungen statt, um die korrekte Anmeldung gewährleisten zu können. Hervorzuheben wäre die Überprüfung der Anmeldevoraussetzungen, aufbauend auf den Informationen der bisherigen Studienleistung des Studenten und der Daten aus der Stu-dienplanverwaltung im System, und das Negieren von Anmeldungen zu Parallellehrver-anstaltungen; wobei auch Gruppen von Lehrveranstaltungen definiert werden können, in denen nur eine Anmeldung möglich ist. Natürlich muß ein solches Anmeldesystem auch
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 77 von 163
die Eingabe von Anmeldemodalitäten unterstützen - so die Zuordnung der Studenten nach vom Institut/Abteilung definierten Algorithmen - z.B. Sammeln der Anmeldungen über einen Zeitraum hinweg, Einteilung nach Zufallsgenerator, Einteilung nach definier-ten Präferenzlisten etc.. Die Layout-Gestaltung der Anmeldemaske sollte institutssei-tig/abteilungsseitig ohne größere Einarbeitungszeit definiert werden können, um auch Auswahlmenüs festzulegen - z.B. um eine Themenauswahl bei Proseminaren gleich bei der Anmeldung vorzunehmen.
Auch Wartelistenfunktionalitäten sollten unterstützt werden. So wird bei Überschreitung der max. Teilnehmerzahl dem Studenten ein Eintrag in eine Warteliste angeboten. Ständig ist im System die aktuelle Wartelistenplazierung einsehbar vom Studenten. Per E-Mail wird er automatisch als möglicher Nachrücker informiert, um freigewordene Plät-ze aufzufüllen, falls er sich innerhalb einer gewissen Frist anmeldet. Ansonsten wird der Nächste der Warteliste informiert. Zu unterstützen ist die Vergabe von Anmeldeprioritä-ten aufgrund von Wartelistenpositionen in vergangenen Semestern.
Betont werden sollte, daß Anmeldungen ausschließlich am System und nicht mehr in den Abteilungen/Instituten stattfinden sollten. Positiv wurde vermerkt, daß zu jeder Zeit die aktuelle Anzahl der angemeldeten Studenten aus dem System verfügbar ist. Auch sollten E-Mail-Verteiler automatisch aus den Teilnehmerlisten generiert werden, um so eine einfache und schnelle Informationsübermittlung gewährleisten zu können. Schwie-rig gestaltet es sich, die Abmeldung von den Lehrveranstaltungen zu urgieren, da ein Druck auf die Studenten aufgrund fehlender rechtlicher Mi ttel nahezu unmöglich ist - hier ist eine interessante Variante im Workshop 2 vorgeschlagen worden (siehe Anregungen der Institute/Abteilungen zu Lehrveranstaltungen).
Erwähnt sei hier noch die Möglichkeit, Kapazitätsengpässe bei der Anmeldung direkt den Instituten/Abteilungen und dem Studiendekanat zu melden, um rechtzeitig Fehlent-wicklungen stoppen zu können. Natürlich sind umfangreiche statistische Erhebungen über einen längeren Untersuchungszeitraum jederzeit systemunterstützt möglich.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 78 von 163 Erstellt gemeinsam m it 15. April 1998
4.1.6.2 Prüfungsanmeldungen
F
Prüfungs-anmeldungen
Student/-in
An- undAbmeldung
Studium
Studien- undPrüfungsabteilung
(STAB)
Prüfung
Fachbereich
Abbildung 37: Funktionszuordnungsdiagramm „Prüfungsanmeldung durchführen“
Bemerkungen:
Analog zu den Anmeldungen zu den Lehrveranstaltungen sollten auch die Prüfungsan-meldungen systemunterstützt möglich sein. Zu beachten ist eine erhöhte Sicherheitsan-forderung, da Anmeldung zu Prüfungen kritischer sein könnten (Sanktionierung bei Nich-tantritten). Eine Anmeldung in den Instituten/Abteilungen sollte nunmehr die absolute Ausnahme sein.
Aus der Liste möglicher Prüfungen nach seinen erbrachten Studienleistungen wählt der Student seine Kombination aus Prüfer, Prüfungstermin und Studium, um danach seine Anmeldung zu bestätigen. Auf Systemseite erfolgt die Prüfung der Teilnahme und die Bestätigung des Prüfungseintrags oder des Eintrags in die Warteliste. Kapazitätsüber-schreitungen werden den zuständigen Stellen gemeldet, um rechtzeitig reagieren zu können.
Aktuell können die Anmeldedaten von den Instituten/Abteilungen ständig im System ver-folgt werden. Die Anzahl der Prüfungsantritte sollte dem/der Institut/Abteilung angezeigt werden, damit die Brisanz der Prüfung abgeschätzt werden kann. Auch Spätanmelder können mit Genehmigung des Prüfers nach Anmeldeschluß eingetragen werden - mit Verifizierung des Prüflings, wobei die Anmeldefristen von den Instituten/Abteilungen fle-xibel definierbar sind. Die Anmeldeliste sollte jederzeit von den Instituten/Abteilungen konfigurierbar sein und z.B. eine Eingrenzung des Prüfungsstoffs (z.B. Abfrage nach besuchten Vorlesungen) fordern können. Auch hier sorgen automatisch generierte E-Mail-Verteiler für schnellen Informationsaustausch an die Studenten.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 79 von 163
Nutzenpotential: Prüfungsanmeldungen
Institute/Mittelbau
Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.
Voraussetzungen zur Anmeldung werden automatisch geprüft.
Anmeldung zu Parallelveranstaltungen nicht möglich.
Anmeldelisten dienen als Verteilerlisten für E-Mail, wodurch schnell Informationen an die Teilnehmer verschickt werden können.
Erhöhte Auskunftsfähigkeit, z.B. aktuelle Anmeldelisten, durch das System.
Flexibilität erhöht sich, da die Administration der Daten auf Institutsseite liegt (z.B. An-meldefrist).
Minus Anmeldemodalitäten müssen zumindest einmal festgelegt werden im System.
Institute/Sekretariate
Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.
Nachrücker werden vom System über Wartelisten automatisch berücksichtigt; Spätan-melder können direkt in das System eingegeben werden (mit Zustimmung des LV -Leiters).
Anmeldungen/Abmeldungen werden nicht mehr in den Instituten abgewickelt.
Voraussetzungen zur Anmeldung werden automatisch geprüft.
Anmeldung zu Parallelveranstaltungen nicht möglich.
Anmeldelisten dienen als Verteilerlisten für E-Mail, wodurch schnell Informationen an die Teilnehmer verschickt werden können.
Minus Anmeldemodalitäten müssen zumindest einmal festgelegt werden im System.
Verwaltung
Plus STAB: Anmeldezeitraum wird automatisch überprüft.
STAB: Überschreitung der max. Teilnehmerzahl wird automatisch überprüft.
STAB: Prüfung, ob Zulassungsvoraussetzungen gegeben sind, findet automatisch statt (Regeln werden durch STAB definiert - Studienplan).
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 80 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Prüfungsanmeldungen
STAB: Keine Betreuung des Studenten zur Anmeldung nötig.
STAB: Anmeldemodalitäten werden automatisch berücksichtigt (Präferenzeingaben, Kapazitätsauslastungen).
STAB: Nachrücker und Wartelisten werden automatisch und institutsseitig administriert.
STAB: Kapazitätsengpässe und Kapazitätsanalysen werden automatisch gemeldet.
Studiendekanat
Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.
Studierende
Plus Prüfung, ob Anmeldung erfolgen kann, erfolgt sofort online.
Präferenzen zu LV können berücksichtigt werden
Wartelisten werden erstellt - Nachrücker werden sofort per E-Mail verständigt.
Prüfungstermine, Prüfer und Dauer werden per E-Mail sofort mitgeteilt.
4.1.6.3 Abmeldungen
F
Abmeldungen
Student/-in
An- undAbmeldung
Studien- undPrüfungsabteilung
(STAB)
Studien-dekanat
Prüfung
Fachbereich
Lehrver-anstaltung
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 81 von 163
Abbildung 38: Funktionszuordnungsdiagramm „Abmeldung durchführen“
Bemerkungen:
In einem Funktionsbaum finden sich die wesentlichen Funktionen des Systems zur Un-terstützung der Abmeldemodalitäten.
Abmeldungen sind vom Schutzbedarf her besonders kritisch zu sehen, da hier Miß-brauch der Abmeldung von unbefugten Personen zu ernsten Konsequenzen führen könnten für die angemeldeten Studenten.
Die Sperrfrist bei Nichterscheinen zu Prüfungen sollte im System von der STAB gewar-tet werden.
Nutzenpotential: Abmeldungen
Institute/Mittelbau
Plus Verschiebungen können direkt in das System eingetragen werden (daraus resultierende
anmelderechtlichen Konsequenzen werden durch das System automatisch berücksich-tigt).
Institute/Sekretariate
Plus Nachrücker werden vom System über Wartelisten automatisch berücksichtigt; Spätan-
melder können direkt in das System eingegeben werden (mit Zustimmung des LV -Leiters).
Abmeldungen werden nicht mehr in den Instituten abgewickelt.
Verwaltung
Plus STAB: Abmeldezeitraum wird automatisch überprüft.
STAB: Verschiebungen können direkt in das System eingetragen werden (daraus resul-tierende anmelderechtlichen Konsequenzen werden durch das System aut omatisch be-rücksichtigt).
STAB: Prüfung, ob Abmeldevoraussetzungen gegeben sind, findet automatisch statt (Regeln werden durch STAB definiert - Studienplan).
STAB: Keine Betreuung des Studenten zur Abmeldung nötig.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 82 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Abmeldungen
STAB: Nachrücker und Wartelisten werden automatisch und institutsseitig administriert.
Studierende
Plus Prüfung, ob Abmeldung erfolgen kann, erfolgt sofort online.
Fernabmeldung sollte möglich sein.
Wartelisten werden erstellt - Nachrücker werden sofort per E-Mail verständigt.
4.1.7 Anerkennungen
An-erkennungen
*
P
Aner-
kennungenerzielen
P
Nostrifi-kationen
erzielen
Abbildung 39: Funktionsbaum „Anerkennung“
Bemerkungen:
Anerkennungen sollten mit Systemunterstützung gewährt werden können. Während die Aktivitäten bei der Nostrifikation vom Charakter her sehr heterogen und daher schlecht im System abbildbar sind, sollten die Arbeiten im Umfeld von Anerkennungen von Prü-fungen und wissenschaftlichen Tätigkeiten gute Hilfeleistung durch das System be-kommen können.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 83 von 163
Alle Anerkennungen von WU-internen Leistungen bei Aufnahme von Zusatzstudien und Wechsel des Studiums sollten automatisch durch das System gewährt werden; nähe-res findet man im Prozeß „Zusatzstudium/Wechsel des Studiums“ wieder.
Siehe auch Kapitel 5.7 im Grobkonzept.
4.1.7.1 Anerkennungen erzielen
P
Aner-kennungen
erzielenStudium
Anerkennung
StudienplanStudent/-in
Service-Einrichtungfür die Studien-kommissionen
Abbildung 40: Funktionszuordnungsdiagramm „Erzielen von Anerkennungen“
Bemerkungen:
In einer Prozeßkette (eEPK) wird der Ablauf zwecks Vergabe von Anerkennungen do-kumentiert.
Verschiedene Verbesserungspotentiale ergeben sich bei Analyse der derzeitigen Situa-tion: Zum Beispiel können Daten direkt in das System vom Studenten eingegeben wer-den, Terminvereinbarungen können im Vorfeld getroffen werden, Ergebnisinformationen den Antragstellern über E-Mail gegeben werden, und Teile der Schriftstücke in der Ver-waltung schon aus den Daten vom System vorgeneriert werden.
Nutzenpotential: Anerkennungen erzielen
Verwaltung
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 84 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Anerkennungen erzielen
Plus STAB/Studienkommission: Anerkennungsbescheid wird automatisch aus den Daten
generiert.
STAB/Studienkommission: Berufungsbescheid bei Einspruch des Antragstellers muß nicht mehr händisch erstellt werden.
STAB/Studienkommission: durch Einscannen von Originaldokumente wird das Versen-den von Schriftstücken eingeschränkt - z.B. Versendung an die Studienkommission zur Entscheidung, Versendung an Fachgutachter - und die Archivi erung von Kopien in Papier-form wird obsolet.
STAB/Studienkommission: Anerkennungsbescheid wird vom Studenten am System aus-gedruckt - keine Schalterbetreuung mehr nötig.
STEP: Information der Vorlage des Anerkennungsbescheids wird automatisch an den Studenten geschickt (E-Mail) oder später schriftlich automatisch generiert.
STAB/Studienkommission: Information über Einspruch des Antragstellers an die Stu-dienkommission erfolgt systemunterstützt über E-Mail.
STAB/Studienkommission: Terminvereinbarung mit Antragsteller zur Vorlage der Origi-naldokumente erfolgt systemunterstützt.
STAB/Studienkommission: Daten zwecks Anerkennung werden vom Studenten direkt in das System im Vorfeld eingegeben.
STAB/Studienkommission: Nachfrage nach zusätzlichen Unterlagen kann elektronisch geschehen (bei Empfangsbestätigung mit elektr. Unterschrift vom Studenten).
STAB/Studienkommission: Schreiben an die Fachgutachter wird automatisch aus den Daten generiert.
Minus STAB/Studienkommission: Einscannen von Originaldokumente nötig, falls diese Aufgabe
vom Antragsteller nicht übernommen wird.
Studierende
Plus Terminabstimmung am System im Vorfeld möglich.
schnellere Bearbeitungszeit
Anerkennungsbescheid kann direkt aus dem System ausgedruckt werden - keine Schal-terbetreuung notwendig.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 85 von 163
4.1.7.2 Nostrifikationen erzielen
P
Nostrifi-kationenerzielen
Studium
Anerkennung
Studienplan
Studien- undPrüfungsabteilung
(STAB)
Antragsteller/-in
Studiendekan/Vizestudiendekan
Abbildung 41: Funktionszuordnungsdiagramm „Erzielen von Nostrifikationen“
Bemerkungen:
Nach einer Gesetzesänderung könnte die Anzahl der durchzuführenden Nostrifikationen im Gebiet der EU deutlich absinken; allerdings werden weiterhin auch aus diesem Ge-biet Nostrifikationen durchzuführen sein.
In der Prozeßkette „Nostrifikationen erzielen“ wird dokumentiert, wie in Zukunft die Bear-beitung der Nostrifikation aussehen könnte. Verbesserungspotential liegt in der Informa-tion der beteiligten Stellen. In diesem Zusammenhang ist auch die Prozeßkette „Zulas-sung Studierende mit Nostrifikationsauflagen“ zu beachten, in der eine Zulassung zum Studium mit Auflagen zum Erlangen der Nostrifikation beschrieben wird.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 86 von 163 Erstellt gemeinsam m it 15. April 1998
4.1.8 Abrechnungen
P*
Ab-rechnungen
Rechts - undOrganisations-
abteilung
Quästur
wissenschaftl.Mitarbeiter/-in
Lehrver-anstaltung
PrüfungDiplomarbeit/Dissertation
Abrechnung
Abbildung 42: Funktionszuordnungsdiagramm „Abrechnung“
Bemerkungen:
Abrechnungen der erbrachten Leistungen werden von der Rechts - und Organisations-abteilung und der Quästur vorgenommen. Bei beiden Organisationseinheiten sind An-wendungssysteme im Einsatz, die mit den entsprechenden Daten über Schnittstellen gefüttert werden müssen.
In der Rechts- und Organisationsabteilung wird mit einer Access-Datenbank mit Namen „PTKG“ gearbeitet, während in der Quästur das System „PAV“ - auch zum Teil in der Rechts - und Organisationsabteilung - eingesetzt werden wird, das österreichweit zum Einsatz kommen soll.
In der Prozeßketten (eEPK) „Abrechnungen mit PAV und PTKG“ wird ein Szenario be-schrieben, in dem das System ‘2gether’ mit beiden Systemen die Abrechnung verwaltet - sicherlich in der ersten Ausbaustufe ein sinnvoller Weg. Bei Integration des Systems „PTKG“ in ‘2gether’ könnte der Ablauf wie in der Prozeßkette (eEPK) „Abrechnungen mit PAV und ohne PTKG“ aussehen. Das Szenario einer Integration beider Systeme ist in der Prozeßkette „Abrechnungen ohne PAV und PTKG“ abzulesen, wobei eine solche Lösung als Endausbaustufe aufgrund der weiten Verbreitung von „PAV“ mehr als frag-lich ist.
Auf jeden Fall sollten die Abrechnungen durch ein perfektionierte Schnittstelle in Zukunft schneller ablaufen. Wesentlich ist, daß alle abrechnungsrelevanten Daten, also Prü-fungstaxen, Kollegiengelder und Lehraufträge,aus dem System abrufbar sind und in Verbindung mit den Personaldaten - ‘2gether’ sollte wesentliche Personaldaten (zumin-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 87 von 163
dest die Personaldaten aus WUFIS) integrieren und Schnittstellen zu dem System „PIS“ aufzeigen - alle notwendigen Informationen zur Abrechnung liefern.
Siehe auch Kapitel 5.8 im Grobkonzept.
4.1.9 Evaluierung der Lehre
*
Beurteilung
von Lehrver-anstaltungen
P
*
Arbeitsberichte
erstellen
F
Evaluierungder Lehre
*
Evaluierung
der Lehre
Abbildung 43: PAM „Evaluierung der Lehre“
Bemerkungen:
Natürlich bietet es sich an, mit Hilfe der mannigfaltigen Dateneinträgen im System auch die regelmäßigen Arbeitsberichte (einmal im Jahr) und die Berichte zur Evaluierung (im Moment geplant: alle vier Jahre) zu unterstützen. Dabei sollte eine automatische Gene-ration aller Berichtsteile, die auf Daten im System basieren, von den Institu-ten/Abteilungen ohne größere Umstände möglich sein.
Siehe auch Kapitel 5.9 im Grobkonzept.
Nutzenpotential: Evaluierung der Lehre
Institute/Mittelbau und Sekretariate
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 88 von 163 Erstellt gemeinsam m it 15. April 1998
Nutzenpotential: Evaluierung der Lehre
Plus Arbeitsberichte können aus den Daten des Systems automatisch generiert werden.
Evaluierungsberichte können aus dem System automatisch generiert werden.
Layout - Vorgabe der Arbeitsberichte möglich über 2gether.
Studiendekanat
Plus Doppelte Stimmabgaben eines Studenten zur Bewertung der Lehrveranstaltung können
vermieden werden (wird mit dem bisherigen System nicht abgedeckt).
Legitimation der Stimmabgabe kann durch das System ‘2gether’ überprüft werden (wird mit dem bisherigen System nicht abgedeckt) - dadurch wird Mißbrauch nahezu unmög-lich.
Layout - Vorgabe der Arbeitsberichte möglich über 2gether.
Studierende
Plus Einheitliche Systemlandschaft bei Benutzung von ‘2gether’ zur Abgabe der Eval uierung.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 89 von 163
4.1.9.1 Beurteilung von Lehrveranstaltungen
P*
Beurteilungvon Lehrver-
anstaltungen
Evaluierung
Student/-in
LV-Leiter/-in
Studien-
dekan
Studien-
kommission
Abbildung 44: Funktionszuordnungsdiagramm „Beurteilung Lehrveranstaltung“
Bemerkungen:
Evaluierungen sollten in Zukunft regelmäßig durchgeführt werden. Dazu ist es notwen-dig, daß die Studenten ihre Wertungen anonym abgeben können. Hier bietet sich der Einsatz von ‘2gether’ geradezu an, da gewährleistet werden kann, daß Studenten nur einmal ihre Stimme abgeben, und eine Überprüfung der Berechtigung der Stimmabgabe durchgeführt wird - also ob z.B. der Student in der von ihm bewerteten Lehrveranstal-tung auch angemeldet ist. In der beiliegenden Prozeßkette (eEPK) wird ein Evaluie-rungsszenario beschrieben. Zu betonen ist, daß hiermit nur die Evaluierung der Lehre eine Unterstützung durch das System bekommt - als weitere Ausbaustufen könnte man sich auch eine Integration der Forschungsevaluierung vorstellen.
Das vom Studiendekanat in den letzten Monaten erstellte Anwendungssystem, das eine Stimmabgabe der Studenten dv-technisch unterstützt, sollte natürlich in seinen Funktio-nalitäten in das System ‘2gether’ integriert werden.
Siehe auch Kapitel 5.9.1 im Grobkonzept.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 90 von 163 Erstellt gemeinsam m it 15. April 1998
4.1.9.2 Arbeitsberichte erstellen
F*
Arbeitsberichte
erstellenEvaluierung
Studien-
dekan
Studien-kommission
Institut/Abteilung
Abbildung 45: Funktionszuordnungsdiagramm „Arbeitsbericht Institutsvorstände“
Bemerkungen:
Alle Funktionalitäten, die das System zur Unterstützung der Erstellung von Arbeitsbe-richten präsentieren kann, sind in einem Funktionsbaum dargestellt.
Umfangreiche Statistiken und Analysen sollten in den Abteilungen/Instituten vom System abrufbar sein. Hinzukommen sollte die automatische Generation eines Berichtes mit ei-ner darauffolgenden Verschickung an das Studiendekanat und die Studienkommissio-nen über das System.
Siehe auch Kapitel 5.9.2 im Grobkonzept.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 91 von 163
4.1.10 Allgemeine Funktionen
allgemeine
Funktionen
Stammdaten
verwaltung
*
Aus-
wertungen/Ausdrucke
*
Hörsaal-administration
*
Chipkarten-
verwaltung
*
Abbildung 46: Funktionsbaum „allgemeine Funktionen“
Bemerkungen:
Hier werden grundlegende organisatorische Funktionalitäten dargestellt, die von dem System zu unterstützen sind.
4.1.10.1 Chipkartenverwaltung
Der Lebenzyklus der an der WU Wien zum Einsatz kommenden Chipkarten läßt sich im wesentlichen in fünf Phasen unterteilen.
Der erste Schritt - die Herstellung der Karte - wird von einem externen Anbieter, der die notwendigen technischen Gerätschaften vorhalten kann, durchgeführt. Alle weiteren Schritte im Zusammenhang mit der Chipkartenverwaltung sollten von der WU selbst vorgenommen werden. Aus diesem Grunde wurde die entsprechende Funktion im Dia-gramm grau hinterlegt.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 92 von 163 Erstellt gemeinsam m it 15. April 1998
So sollte bereits der nächste Schritt, die Initialisierung der Chipkarte, von einer WU-internen Stelle, dem sogenannten „Trust-Center“, durchgeführt werden. Diese Trust-Center-Funktionalität könnte sinnvollerweise von einer um diese Aufgabe erweiterte Studien- und Prüfungsabteilung vorgenommen werden. Bei der Initialisierung enthält die Chipkarte alle Informationen der Anwendung ‘PowerCard’, d.h. von diesem Zeitpunkt an ist es sinnvoll, den Begriff ‘PowerCard’ zu verwenden.
An die Initialisierung schließt sich die Personalisierung der ‘PowerCard’ an. Auch die-se – wie auch alle weiteren Tätigkeiten – sollte sinnvollerweise vom o.e. WU-internen Trust-Center durchgeführt werden. In dieser Phase werden die für den späteren Gebrauch der PowerCard notwendigen (personenbezogenen) Daten in die Karte ge-schrieben und das Lichtbild mittels Thermotransferverfahrens aufgebracht.
Die nächsten im Funktionsbaum im Anhang detailliert aufgeführten Phasen umfassen die Verwendungs- und Endphase der PowerCard.
Mit der hier geschilderten Organisation der Verwaltung der Chipkarte ist eine größtmög-liche Sicherheit und Effizienz in der Handhabung gewährleistet. So fallen unnötige Transportwege sowie die unnötige Herausgabe WU-interner oder gar persönlicher Da-ten an einen Fremdanbieter weitgehendst weg. Durch die zeitnahe Initialisierung und Personalisierung der Karte kurz vor der Ausgabe sind auch Risiken – beispielsweise durch Diebstahl – minimiert.
Sinnvollerweise sollte das Trust-Center auch die Verwaltung der Karten von WU-Mitarbeitern übernehmen, obwohl dies nicht zu den ursprünglichen Aufgaben der Stu-dien- und Prüfungsabteilung gehört.
Siehe auch Kapitel 6.2 im Grobkonzept.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 93 von 163
4.1.10.2 Hörsaaladministration
Hörsaal-administration
*Lehrver-anstaltung
Prüfung
Raum-verwaltung
WU-Angehörige/-r
Wirtschaftsabtei-lung und Abteilung
für Gebäudeund Technik
Rechts - undOrganisations-
abteilung
Abbildung 47: Funktionszuordnungsdiagramm „Hörsaaladministration“
Bemerkungen:
Sinnvoll erscheint weiterhin eine Servicestelle für die Hörsaaladministration als An-sprechpartner der Institute und Abteilungen bereitzuhalten. Diese sollte sowohl während des Semesters Wünsche zur Belegung von Räumen bearbeiten, an andere Stellen (Rektorat) zur Genehmigung weiterleiten, als auch über Kostenersätze informieren. Auch für die Information über kurzfristige Verschiebungen von Veranstaltungen könnte von hier gesorgt werden.
Online sollte immer die aktuelle Raumbelegung einsehbar sein für interessierte Abtei-lungen der WU-Wien; auch hier könnte die Service-Stelle ihren Part leisten, wie auch bei der Unterstützung einer Hörsaaltauschbörse.
Siehe auch Kapitel 5.10.4 im Grobkonzept.
4.1.10.3 Stammdatenverwaltung
Die Stammdatenverwaltung sollte je nach Datenbereich klar definierte Zuständigkeiten aufweisen.
Siehe auch Kapitel 5.10.1 im Grobkonzept.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 94 von 163 Erstellt gemeinsam m it 15. April 1998
4.1.10.4 Auswertungen/Ausdrucke
Die verschiedensten Auswertungen und Statistiken sollten jederzeit über der Datenbank des Systems abrufbar sein. Wichtig ist Möglichkeit, Abfragen flexibel den Bedürfnissen anpassen zu können. Dies sollte ohne allzu viel Vorkenntnisse auch von Anwenderseite durchführbar sein.
Alle durchgeführten Abfragen sollten sich speichern lassen (sowohl die Abfrage-Einstellungen an sich als auch die Ergebnisse) und sollten automatisch archiviert wer-den. Datenexporte der Ergebnisse in verschiedenen Formaten sollten unterstützt wer-den.
Eine Übersicht wünschenswerter Abfragen und weitere Informationen enthält das Kapi-tel 5.10.2 des Grobkonzepts.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 95 von 163
4.1.11 Allgemeine Systemfunktionen – Grundfunktionalitäten
Benutzer-führung
Delegations-mechanismen
Vorgangs-sicherheit
(Authentifizierung)
Vorgangs-Protokollierung
elektronischeSchautafel
allgemeineSystem-
funktionen
Benutzer-administration
Backup-und Archivierung
Begleit-maßnahmen
Grundfunktionalitäten
Abbildung 48: Funktionsbaum „allgemeine Systemfunktionen“
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung
Seite 96 von 163 Erstellt gemeinsam m it 15. April 1998
Bemerkungen:
Wesentliche „Grundfunktionalitäten“ des Systems werden an dieser Stelle genannt. Für detaillierte Informationen sei an dieser Stelle auf das Grobkonzept Kapitel 5.1 und Kapi-tel 6 verwiesen, das sehr anschaulich und umfangreich entsprechende Anforderungen auflistet.
Die Benutzerführung sollte intuitiv und einfach ablaufen und alle angesprochene Einga-bemedien unterstützen (IVR, Internet etc.). Auch wurde bei den Interviews eine engli-sche Sprachvariante als conditio sine qua non gefordert und eine französische als sinn-volle Erweiterung angesprochen (unabdingbar für die Information der Austauschstuden-ten).
Eine wichtige Kernfunktionalität deckt der Delegationsmechanismus ab, mit dem es möglich sein sollte, Berechtigungen auf andere Personen zu übertragen. Zu klären wäre noch, ob bei Leistung von elektr. Unterschriften seitens der delegierten WU-Angehörigen auch die Zuordnung der Verantwortlichkeiten entsprechend gesetzlich geregelt sind. Dies sollte das in naher Zukunft erwartete Gesetz zur Regelung der elektr. Unterschrif-ten beantworten können.
Es sollte den je nach durchgeführter Transaktion unterschiedlichen Sicherheitsanforde-rungen Rechnung getragen werden. Hier bieten die Eingabe der Benutzerkennung und Paßwörter, elektr. Unterschriften, TAN-Nummern und die Verwendung von Verschlüsse-lungsalgorithmen vielfältige Möglichkeiten je nach Eingabemedium die korrekte Authenti-fizierung gewährleisten zu können. Zum Zeitpunkt der Einführung des Systems sollten auch Transaktionen über das Internet per WWW vom Sicherheitsstandard her allen An-sprüchen gerecht werden (128-Bit Schlüssel etc.), falls die derzeitige Entwicklung an-hält.
Alle Transaktionen im System sollten mitprotokolliert werden und von den verschiede-nen interessierten Abteilungen einsehbar sein, falls die Datenschutzgesetze dies erlau-ben. So könnte die Überprüfung der Anmeldung zu Lehrveranstaltungen und Prüfungen auch direkt von Abbteilungsseite/Institutsseite sinnvoll sein.
Eine Möglichkeit alle interessanten Daten direkt zur Veröffentlichung („Schaukasten“) ins WWW zu stellen sollte gegeben sein. Per E-Mail sollten bei Veränderungen von Daten je nach Zuordnung alle Betroffene automatisch informiert werden („shared-Mail-Mechanismus“ bei Massenmailings). Fristerinnerungen sollten automatisch verschickt werden. Ausdrücke der angezeigten Daten sollten jederzeit möglich sein für die Anwen-der.
Eine umfangreiche Benutzerverwaltungskomponente sollte im System integriert wer-den. Berechtigungen müssen anwenderfreundlich verwaltet werden und automatisiert vergeben werden können. Bisherige Benutzerverwaltungssysteme können eingespart werden.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 97 von 163
Datenschutz muß entsprechend berücksichtigt werden - insbesondere sollten Anforde-rungen der ÖH bzgl. der Einschränkung der Einsicht in Studentenstammdaten einbe-zogen werden.
Eine Auslagerung von Altbeständen von Daten zur Archivierung muß unterstützt wer-den, wie auch die Rückspielen dieser Daten zur Ansicht. Transaktionen (z.B. Zuordnun-gen zu Prüfungen) sollten rückgängig gemacht werden können (roll-back), natürlich mit entsprechender E-Mail-Information.
Begleitmaßnahmen wie Anwender - und Administrator- Schulungen und die Erarbeitung von Ausfallkonzepten und Sicherheitskonzepten müssen vor Systemeinführung sicher-gestellt sein. Umfangreiche Informationsaktivitäten für die Studentenschaft erscheint notwendig und sind rechtzeitig durchzuführen.
Weitere Grundfunktionalitäten wie das Abspeichern der erstellten Daten, die Aufruf- und Eingabefunktionalität, Maus- und Keyboard - unterstützte Benutzerführung etc. verste-hen sich von selbst.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.2 Anregungen der verschiedenen Organisationseinheiten
Seite 98 von 163 Erstellt gemeinsam m it 15. April 1998
4.2 Anregungen der verschiedenen Organisationseinhei-ten
In den Interviews wurden die verschiedenen Anforderungen, Bemerkungen und Befürch-tungen der beteiligten Interviewpartner aufgenommen und werden im Folgenden doku-mentiert. Die aufgeführten Themen entsprechen nicht unbedingt der Meinung der bera-tenden Firmen - sie sollen vielmehr ein Forum zur Transparenz der Meinungsvielfalt der WU-Wien bilden. Manche Themen wurden auch von den beratenden Firmen im Ge-spräch gefordert oder von mehreren Abteilungen angesprochen, wobei hier meist nur der erste Anstoß vermerkt wurde. Die von den beratenden Firmen unterstützten Anre-gungen werden durch das unterstrichene erste Wort des Satzes gekennzeichnet. Im Anhang findet man eine Legende zu den Abkürzungen der interviewten Abteilun-gen/Institute.
4.2.1 Studien- und Prüfungsabteilung
• Durch Nachschauen vom Studenten im Medium (z.B. WWW) sollte mög-lich sein zu klären, ob Rückmeldung erfolgt ist - dadurch ist rechtzeitiges Reklamieren möglich!
• StabDat also die in der STAB verwendete Filemaker-Datenbank, sollte in Funktionalität und Anwenderfreundlichkeit im neuen System vorliegen (ca. 10000 Briefe an ausländ. Studenten) - also Layout-Generierung, Datenfel-derkontrolle, Datenlinks, Funktionalitäten (zB Summierung).
• Die Änderung der Kennzahl (entspricht Studienrichtung) war bisher nur möglich über Löschung des gesamten Eintrags und neues Erfassen; dies sollte verbessert werden!
• Der gesamte Briefverkehr sollte archiviert werden und auf Anfrage abrufbar sein.
• Ähnlichen Prüfungen sollten ähnlich Nummern zugeordnet werden – in Zu-kunft sind alle Prüfungen wie LV-Prüfungen zu handhaben.
• Layout: bisher Gestaltung der Ausdrucke aus Step nur über Programmierer; hier läge ein deutliches Verbesserungspotential.
• Automatisches Zuschicken der Sammelzeugnisse (2x im Jahr) sollte nur er-folgen falls sich eine Veränderung im System ergab!
• Zulassungsdaten sollen direkt von Schulen eingespielt werden in Zukunft (von Schuldatenbanken).
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 99 von 163
• Exaktes Ausfallkonzept muß vor Einführung erstellt werden.
• Fristerinnerungen bei Studien mit Auflagen sind automatisch vom System zu verschicken.
• Verlängerung des Studiums über Fristende hinaus (z.B. bei Nostrifikationen) muß möglich sein.
• Bei Studien mit Auflagen sollte Auflagenerfüllung automatisch vom System zurückgemeldet werden.
• Informationen über Studienberechtigungsprüfungen per Schnittstelle aus ‘2gether’ in das Ministerium sollte möglich sein (bisher händisch zu ma-chen).
• 2gether wird die Aufnahme mit Auflagen zum Studium (z.B. Fachhoc h-schulabsolventen zu Doktoratsstudium mit Auflagen) unterstützen müssen.
• Interessant wäre ein Sponsions -Ranking pro Fachbereich als Auswertung.
4.2.2 Institute/Abteilungen
Lehrveranstaltungen
• Anforderung: Warnfunktionalität bei der Hörsaalvergabe, wenn noch keine Reservierung für eine Prüfung etc. stattgefunden hat. (WI)
• Sinnvoll wäre ein Plausibilitätscheck im System, ob zu jeder Lehrveranstal-tung eine Prüfung geplant ist.(WI)
• Anforderung: Die Wartelistenfunktionalitäten sollten umfassend sein - spe-ziell sollten Studenten, die schon in Vorsemestern auf Wartelisten standen, Priorität bei der Zuordnung genießen. (WS2)
• Anforderung: Daten in Anmeldelisten sollten von Instituten/Abteilungen zur Ansicht für den Studenten freigegeben werden können - Freigabe könnte über entsprechendes Ansteuern des Tabellenkopfes erfolgen. (WS2)
• Anforderung: Ein Roll-Back-Verfahren sollte möglich sein - speziell was die Revidierung von Zuteilung zu LV und Prüfungen betrifft. (WS2)
• Anregung: Druck auf die Studenten zur Abmeldung zu LV dadurch, daß nur eine Menge, oder auch Reservoir, von „Credit Points“ pro Student zur An-meldung zur LV existiert. (siehe Universität Konstanz). (WS2)
• Anforderung: Bei der Hörsaalvergabe muß auch die Blockvergabe der Hör-säle berücksichtigt werden (Blockveranstaltung).Diese „blockiert“ andere Lehrveranstaltungen. (WS2)
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.2 Anregungen der verschiedenen Organisationseinheiten
Seite 100 von 163 Erstellt gemeinsam m it 15. April 1998
• Es wird gefordert, daß auf Schleifendurchgänge a priori verzichtet wird. D.h. das System sollte viel stringenter Vorgaben machen. (Bsp.: Budgetsituatio-nen für Lehrveranstaltungen) (WS2)
• Bemerkung: Die Hörsaalverwaltung des Grobkonzeptes ist zu idealistisch. Die geforderten Algorithmen sind nicht machbar (à Endlosschleifen). (WS2)
• Anregung: Die Art des (LV-) Entgeldes sollte auch schon vom System ab-gecheckt werden. (WS2)
• Bedingungslose Optimierung der Hörsaal-Vergabe in jedem Semester wäre sinnvoll - keine Übernahme gewohnter Hörsäle. (PoÖk)
• Bei der Planung der Lehrveranstaltungen wären Schnittstellen zwischen dem System und Text- bzw. Tabellenbearbeitungssystemen sinnvoll. (Po-Ök)
• Verantwortung der Hörsaal-Verwaltungsstelle für die Bekanntgabe eines Ausfalls einer Lehrveranstaltung an den Hörsälen. (BeSt)
• Automatische Erzeugung von E-Mail-Verteiler bzgl. der LV-Teilnehmer und der Gruppenbildung in den Lehrveranstaltungen. (BeSt)
• Interessant wären Diskussionsfora pro LV im System. (BeSt)
• Bei Anforderungen an Hörsäle sollten Equipment-Anforderungen integriert werden. (BeSt)
• Historie aller Lehrveranstaltungen sollte im System ‘2gether’ zum Aufruf („Revitalisierung“) vorliegen. (FI,BeSt)
• Keine Zuordnung von festen Terminen und Hörsälen zu Prüfungen über mehrere Semester hinweg - nur bei Massenprüfungen. Ansonsten Optimie-rung über das System nach Teilnehmerzahlen in der Vergangenheit. (FI)
• Anregung: Vorläufiger Terminkalender (schon in Grobplanungsphase VVZ) zur Planung von Lehrveranstaltungen auf Inst./Abt.-Ebene zur Vermeidung von Überschneidungen. (FI)
• Bei Eingangstest für eine Lehrveranstaltung sollten erfolgreiche Teilnehmer automatisch für die folgende Lehrveranstaltung angemeldet sein. (WA)
• Alle LV-Termine sollten nach Planung im System einzusehen sein. Am bes-ten wäre Anlegung einer Tabelle in der Anmeldeliste mit den Veranstaltungs-terminen als Spaltenköpfe (für Anwesenheitslisten etc.) - alle Feiertage, Rektoratstage etc. sind zu berücksichtigen. (BüRe)
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 101 von 163
• Über die Anmeldeliste müßte die Informationsversendung per E-Mail an die Teilnehmer problemlos über automatisch generierte Verteiler möglich sein.(BüRe)
• 2gether sollte Projekt „Studieren im Team“ unterstützen - Anmeldungen soll-ten sich auch auf Pakete von Lehrveranstaltungen beziehen können.(BüRe)
• In dem im Internet generierten VVZ sollten Links zwischen den Lehrveran-staltungen und den ausführenden Instituten/Abteilungen automatisch vorge-geben werden. (BüRe)
• „Antrag auf bargeldlose Gehaltszahlung“ sollte nicht mehr über die Bank zu bestätigen sein - Kontoadresse als Information sollte ausreichen. (BüRe)
• Anforderung: systemunterstützte Überprüfung, daß Assistenten ihre Mi n-dest- (Lehr-) Stundenzahl erfüllen. (WI)
• Bei Anmeldung zu Proseminaren und Seminaren sollte einen Themenaus-wahl über das System möglich sein.(WI)
• Wünschenswert: Abgleich zwischen Prüfungs- oder LV-Kapazität und der Hörsaalzuordnung, z.B. # LV-Teilnehmer <= # Hörsaalplätze (Anmerkung des Verfassers: Vielleicht wären auch „Überbuchungen“ sinnvoll.) (WI)
• Anmerkung: Es gibt für Professoren, Assistenten und Externe eigene Bud-gets, die nicht gegeneinander aufgerechnet werden können. (WI)
• Anmerkung: Hinweis auf das Problem der externen Lektoren à es sollte an den Instituten eine (interne) Koordinierungsstelle für die LV-Ankündigungen geben. (WI)
• Vorschlag zur LV-Beginnmeldung: der LV-Leiters sollte bei seiner alle-rersten LV ein Papier unterschreiben, in dem daraufhin gewiesen wird, daß er bei LV-Beginn im negativen Fall Meldung zu machen hat. (RoSp)
• Anmeldelisten für Lehrveranstaltungen oder Prüfungen dienen dazu, Vertei-lerlisten für E-Mails automatisch zu erstellen. (z.B. RoSp)
• Anmeldefristen sollten von den Abteilungen/Instituten festzulegen sein. (RoSp)
• Falls LV-Leiter nicht zu erreichen ist (z.B. mit E-Mail), sollten Dokumente automatisch vom System an das Institut geschickt werden - schon mit Ein-trag aller Daten (z.B. Personaldaten). (RoSp)
• Die LV-Beginnmeldungen sollten abgeschafft werden - Information nur im negativen Fall der Nichtaufnahme (RoSp).
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.2 Anregungen der verschiedenen Organisationseinheiten
Seite 102 von 163 Erstellt gemeinsam m it 15. April 1998
• LV-Beginnmeldungen sollten nicht mehr in den Sekretariaten zu bearbeiten sein (direkt vom LV-Leiter und danach in der RO). (RoSp)
• Simulationen verschiedener LV-Szenarien sollten immer möglich sein - und somit die Prüfung der Einhaltung von Budget-Rahmenwerten. (RoSp).
• LV-Leiter sollten bei Ankündigung von Lehrveranstaltungen im System Wunschzeiten und Ausweichzeiten angeben und verändern können (RoSp).
• Planung von Lehrveranstaltungen im Semester von Seiten der Institute soll-te über Genehmigung der Rechts- und Organisationsabteilung und des Stu-diendekanats möglich sein. (WS2)
• Wenn die Rechts- und Organisationsabteilung weiß, daß der LV-Leiter nicht per E-Mail erreichbar ist, dann sollte sie direkt an den LV-Leiter schreiben und umgekehrt (Bsp. Erhebungsbogen).(PeWi)
Prüfungen
• Anforderung: Warnfunktionalität bei der Hörsaalvergabe, wenn noch keine Reservierung für eine Prüfung etc. stattgefunden hat. (WI)
• Sinnvoll wäre ein Plausibilitätscheck im System, ob zu jeder Lehrveranstal-tung eine Prüfung geplant ist.(WI)
• Wünschenswert: Abgleich zwischen Prüfungs- oder LV-Kapazität und der Hörsaalzuordnung, z.B. # LV-Teilnehmer <= # Hörsaalplätze (Anmerkung des Verfassers: Vielleicht wären auch „Überbuchungen“ sinnvoll.) (WI)
• Anforderung: Die Wartelistenfunktionalitäten sollten umfassend sein - spe-ziell sollten Studenten, die schon in Vorsemestern auf Wartelisten standen, Priorität bei der Zuordnung genießen. (WS2)
• Anforderung: Ein Roll-Back-Verfahren sollte möglich sein - speziell was die Revidierung von Zuteilung zu LV und Prüfungen betrifft. (WS2)
• Anforderung: Bei nachträglicher (d.h. nach Freigabe der Daten durch das Institut) Änderung der Teilnehmerdaten zur Prüfung müßte auch die Rechts- und Organisationsabteilung (z.B. bei Änderung der Teilnehmerzahl) infor-miert werden. (WS2)
• Anforderung: Daten in Anmeldelisten sollten von Instituten/Abteilungen zur Ansicht für den Studenten freigegeben werden können - Freigabe könnte über entsprechendes Ansteuern des Tabellenkopfes erfolgen. (WS2)
• Anforderung: Versendung der Noteninformation an die Studenten erfolgt bei Noteneintrag, nicht über Prüfungsanmeldeliste (auch Teilmengen sollten in-formiert werden können). (WS2)
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 103 von 163
• Anforderung: Die Menge der Prüflinge sollten bei mehreren Prüfern entspre-chend den Prüfern im System zugeordnet werden können. (WS2)
• Die freiwerdenden Kapazitäten der Prüfungsabteilung sollten dafür einge-setzt werden, den (zeitlichen) Engpaß, der dadurch entsteht, daß eine LV von der STAB dem Studienplanpunkt zugeordnet werden muß, zu vermei-den. (WS2)
• Bei Spätanmeldungen müssen Prüfer und Student unterschreiben. (FI)
• Hängt die Teilnahme an einer (mündlichen) Prüfung vom Ergebnis einer an-deren (schriftlichen) Prüfung ab, dann sollte diese Teilnahme auch automa-tisch generiert werden. (FI)
• Anforderung: Das Halten von Prüfungsfragen im ‘2gether’ ist strikt optional (Gefahr des Mißbrauchs). (WA)
• Anforderung: Nachrücker für Prüfungen müssen sich explizit anmelden.(WI)
• Anmeldelisten für Lehrveranstaltungen oder Prüfungen dienen dazu, Vertei-lerlisten für E-Mails automatisch zu erstellen. (z.B. RoSp)
• Anmeldefristen sollten von den Abteilungen/Instituten festzulegen sein. (RoSp)
• Killerprüfungen (also 3. Prüfung für den Studenten) sollten mit Warnungen dem Prüfer angezeigt werden. (RoSp)
• Bei Prüfungsanmeldungen sollte aufgeführt werden, der wievielte Antritt des Studenten es ist. (RoSp)
• Layout der Prüfungslisten sollten von Instituten leicht modifizierbar sein. (z.B. mehrere Spalten mit internen Bemerkungen). (RoSp)
• Online sollten Informationen über die Studienjahreinteilung und Prüfungsan-forderungen einsehbar sein. (WS3)
Diplomarbeiten/Dissertationen
• Forderung: Rechtzeitige, zeitnahe Eintragungen in der Themendatenbank, insbes. wenn (d.h. wann) das Thema vergeben worden is t. (WS2)
• Abgegebene Diplomarbeiten sollten von Institutsseite eingesehen werden können. (PoÖk)
• Anregung: Bei Vergabe von Themen in der Abschlußarbeit sollte ein Verweis auf Fördermittel (intern und extern) gegeben werden. (BeSt)
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.2 Anregungen der verschiedenen Organisationseinheiten
Seite 104 von 163 Erstellt gemeinsam m it 15. April 1998
• Einsicht in abgelegte Diplomarbeiten in digitaler Form sollte öffentlich nicht möglich sein. (Gefahr des Plagiats). (WA)
Allgemein
• Anforderung: Interimszeugnisse sollten jederzeit vom Studenten im System ausgedruckt werden können. (WS2)
• Möglichkeit des Ausdrucks von FLAG-Bestätigungen von den Studenten aus dem System. (WS2)
• Alle Vorgänge in System sollten mitprotokolliert werden (z.B. Abmeldungen) - wichtig ist ein einfacher Zugang zu diesen Informationen. (WS2)
• Anforderung: Letztlich muß auch die gesamte Software parametrisierbar sein; denn z.Zt. gibt es einen Lebenszyklus von gesetzlichen Grundlagen von ca. 2 Jahren... (z.B. Einsichtsfristen, Taxenverteilung (bei mehreren LV-Leitern), Modellie-rung der Workflow-Prozesse).(WS2)
• Es gibt einen abgestuften Delegationsmechanismus. Der Delegationsme-chanismus muß parametrisierbar sein. (WS2)
• Anforderung: Personalinformationssystem sollte ins ‘2gether’ aufgenommen werden. (WS2)
• Anforderung: Aus dem im System bestehenden Daten sollten E-Mail-Verteiler erzeugbar sein, also nicht nur bei den LV-Teilnehmern etc. (Bsp. „Alle WU-Angehörigen, die im Sekretariat arbeiten“).(WS1)
• Bei Delegation muß vorher die Frage der Haftung bei stellvertretender elektr. Unterschrift geklärt sein. (WS1)
• Gutachtenabgabe bzgl. Austauschstudenten sollte vom System unterstützt werden - z.B. automatische Unterschriften und elektr. Weitergabe des Gut-achten vom Fachprofessor und Kooperationsprofessor. (EnSp)
• Filter sollten bei der E-Mail-Verwaltung problemlos anwendbar und definier-bar sein. (PoÖk)
• Sommerhochschulkurse brauchen erst einmal nicht im System administ-riert werden. (ZAS)
• Die Vergabe von ECTS-Credits sollte im System berücksichtigt werden - Nachweis von erzielten Credits könnte über maschinell bestätigten Aus-druck vom Studenten möglich sein. (ZAS)
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 105 von 163
• Umfangreiche Informationen über Anmeldeprozeduren etc. sollte im System in versch. Sprachen angeboten werden. (ZAS)
• Bei Austauschstudenten ist es dringend erforderlich, daß Anmeldungen mit höherer Priorität und verändertem Anmeldezeitraum behandelt werden. (ZAS)
• Auf jeden Fall sollte das System mehrere Sprachen unterstützen (Engli-sche und französische Sprache erscheint sinnvoll). (ZAS)
• Antrag auf Zulassung sollte auch ohne Bezahlung eines ÖH-Beitrags bei Austauschstudenten möglich sein - Authentifizierung erfolgt über elektr. Un-terschrift des ZAS. (ZAS)
• Die Hörsaalverteilung sollte immer aktuell abrufbar sein. (BeSt)
• Anforderung: Berücksichtigung von nationalen und WU-internen „Feierta-gen“ im WU-weiten Terminkalender. (BeSt)
• WU sollte als Trust Center für Verschlüsselungs -Verwaltung (Elektr. Unter-schrift) dienen. (BeST)
• Ausblick: Bibliotheksverwaltung sollte in das System integriert werden, ins-besondere bei an die Institute ausgelagerter Literatur. (BeSt)
• Wichtiger Punkt ist der Datenschutz, d.h. das Institut darf nicht alle Daten der Studenten sehen - Beteiligung der ÖH an einem Berechtigungskonzept ist erforderlich. (ÖH)
• Bei Datenexport aus ‘2gether’ in Dateien sollten die Daten in „interessanten“ (sprich gut zu bearbeitenden) Formate vorliegen. (BüRe)
• Befürchtung: Arbeitsumlegungen vom Mittelbau auf Sekretariate könnten ge-fordert werden, wenn neue Medien eingesetzt werden. (WiSoGe)
• VVZ sollte ständig von den Abteilungen bearbeitet werden können. (BüRe)
• Informationsgehalt (also Auswahl der Daten) der vom System autom atisch generierten E-Mails an die Studenten sollte von den Instituten bestimmt werden können. (RoSp)
• Kalender an der WU sollte über versch. Sichten (z.B. Prüfungssicht) anzu-schauen und auszudrucken sein. (RoSp).
• Institutsstundenplan sollte aus dem System zu erstellen sein mit versch. Sichten (auch mit Unterhierarchien - z.B. versch. Sprachbereiche). (RoSp)
• Hörsäle, die einem Fachbereich/Abteilung zugeordnet wurden, sollten auch von diesem im System verwaltet werden können. (RoSp).
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.2 Anregungen der verschiedenen Organisationseinheiten
Seite 106 von 163 Erstellt gemeinsam m it 15. April 1998
• Zu überlegen wäre es in Zukunft Budget-Vorgaben auf Jahresebene zu defi-nieren. (RoSp)
• Anforderung: Serviceschalter sollte es in Zukunft auch für Studenten ohne Anmeldung geben - hier wäre eine Zulassung mit Zahlscheinbezahlung möglich.. Diese Schalter könnten getrennt von den Schaltern für angemel-dete Studenten sein. (ÖH)
• Anforderung: Sichergestellt werden muß, daß LV-Anmeldungen nach einer gewissen Frist, ohne daß eine Zulassung des angemeldeten Studenten er-folgt ist, gestrichen werden. (ÖH)
• Anmerkung: Kritisch wird die kurze Zeit der Ist-Aufnahme im Projekt ‘2gether’ gesehen und daher werden Zweifel am ausreichenden Informati-onsstand für das Projekt gehegt. (WI)
4.2.3 Studiendekanat
• Eine Lehrveranstaltungsbörse - oder besser Hörsaalbörse - sollte es geben im System (besonders bei automatischer Hörsaalvergabe durch das Sys-tem).
• Besser als eine Zuordnung der Veranstaltungen zu den Hörsälen analog der Verteilung wie vor 2 Semestern wäre jedes Semester eine vollautomati-sche Optimierung der Hörsaalverteilung.
• Sollte ‘2gether’ das zur Zeit erstellte Evaluierungsprogramm ablösen, müß-ten die wesentlichsten Funktionalitäten übernommen werden (z.B. die Mög-lichkeit der Definition von individuellen Fragen durch den LV-Leiter).
• Am Semesterende sollte jeder LV-Leiter die Teilnehmerzahl eingeben mit elektr. Unterschrift (wichtige Daten zur Erstellung von Berichten).
Legende:
Kürzel Bedeutung
WI Wirtschaftsinformatik
PoÖk Politische Ökonomie
RoSp Romanische Sprachen
EnSp Englische Sprachen
BüRe Bürgerliches Recht
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 107 von 163
WA Warenhandel
FI Finanzierung
BeSt Betriebswirtschaftliche Steuerlehre
WiSoGe Wirtschafts- und Sozialgeschichte
ZAS Zentrum für Auslandsstudien
PeWi Personalwirtschaft
WS 1 Workshop 1
WS 2 Workshop 2
WS 3 Workshop 3
WS 4 Workshop 4
Tabelle 6: Legende zu den Anmerkungen
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 108 von 163 Erstellt gemeinsam m it 15. April 1998
4.3 Konzeptionelles Datenschema
4.3.1 Intention
Neben der Beschreibung der universitären Abläufe unter Berücksichtigung des neuen Systems ‘2gether’ durch Geschäftsprozeßmodelle, Funktionsbäume und Funkt ionszu-ordnungsdiagramme (vgl. Abschnitt Organisatorische Gestaltung der Studien- und Prü-fungsverwaltung), ist die Erstellung konzeptioneller, semantischer Datenmodelle ein weiterer wichtiger Baustein in der fachlichen Konzeption eines Anwendungssystems.
In diesem Abschnitt werden daher die entsprechenden relationalen Datenmodelle der Studien- und Prüfungsverwaltung vorgestellt. Diese verfolgen nicht den Zweck, fertige Programmiervorlagen zu erzeugen. Dies ist allein schon deshalb nicht angebracht, da es sich bei dieser Projektphase um die Erstellung einer Ausschreibungsgrundlage han-delt. Die technischen „Einzelheiten“, z.B. ob es sich um eine relationale oder eine ob-jektorientierte Datenbank handeln wird, sind somit noch nicht festgelegt.
Nichtsdestotrotz wurden die Datenobjekte mit den zugehörigen, markanten Attributen detailliert. Diese wurden in einer eigenen EXCEL-Datei erfaßt und sind dem Bericht im Anhang beigefügt. Die Datenmodelle entsprechen aus den vorgenannten Gründen nicht in jedem Fall der sogenannten „Dritten Normalform“ und sollten daher intuitiver ver-ständlich sein.
4.3.2 Semantische Datenmodelle
Die folgende Abbildung 49 beinhaltet die Clustersammlung zum Themenbereich und dient somit - auch in der ARIS -Datenbank - als Übersichts- und Navigationsmittel für die Datenmodellierung.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 109 von 163
Studium Lehrver-anstaltung
Prüfung Diplomarbeit/Dissertation
An- undAbmeldung
Anerkennung AbrechnungEvaluierung
Raum-verwaltung
Studienplan
Vorlesungs-verzeichnisAdresse
Abbildung 49: Clustersammlung zur Studien- und Prüfungsverwaltung
Im folgenden sollen nun die einzelnen Cluster weiter detailliert werden. Dabei deuten die neben den Objekten befindlichen Sterne („*“) auf die Existenz weiterer Attribute hin. Ein-gegraute Objekte dienen zu Erhöhung des Veständnisses und sind an anderer Stelle definiert (und somit redundant dargestellt).
4.3.2.1 Studium
Abbildung 50: Semantisches Datenmodell ‘Studium’
siehe nächste Seite.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 110 von 163 Erstellt gemeinsam m it 15. April 1998
Dip
lom
-st
udiu
mD
okto
rats
-st
udiu
mU
nive
rsitä
ts-
lehr
gang
Fern
-st
udiu
m
1
[Ges
amts
tund
enza
hl] e
tc.
Stu
dium
*
Reg
el-
stud
ium
Aus
taus
ch-
prog
ram
m
1
Stu
dium
*
[Nam
e][A
dres
se]
[WU
-Mat
rikel
-nu
mm
er] e
tc.
Stu
dier
ende
/-r *
Stu
dium
der
Zul
assu
ng[lf
d. N
r.][S
tatu
s] e
tc.*
[Vor
lage
term
in]
[Anm
elde
num
mer
] etc
.
Zul
assu
ngzu
m S
tudi
um
*
bean
tragt
Ver
wal
tung
s-m
itarb
eite
r
Ter
min
Term
in(-
liste
)de
s V
MA
's
(Vor
lage
-)T
erm
inlis
te
*
defin
iert
gibt
Vor
-la
gete
rmin
für
Vor
lage
-te
rmin
Stu
dent
en-
ausw
eis
*
erhä
lt
Wec
hsel
,
Auf
nahm
e,
Bee
ndig
ung
Stu
dium
s-än
deru
ng
*
nim
mt
auf
erfo
lgt
für
been
det
Stu
dium
des
Stu
dier
ende
n *
Stu
dium
*
Stu
dier
ende
/-r *
sow
ohl S
tudi
um
regu
lare
als
auc
h
irreg
ular
e
Stu
dium
*
Stu
dier
ende
/-r *
Stu
dium
des
Stu
dier
ende
n *
Sem
este
r
*
gilt
für
Rüc
k-m
eldu
ng
*
Sem
este
r
*
gilt
für
cn
1 1
n
cn cn
1
n
cn1
cn
1
111
cn
cn
cn
cn
cn
cn
c
1
cn
1
cn
cn n
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 111 von 163
4.3.2.2 Studienplan
Abbildung 51: Semantisches Datenmodell ‘Studienplan’
siehe nächste Seite.
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 112 von 163 Erstellt gemeinsam m it 15. April 1998
*
Stu
dien
-pl
an
*
Stu
dien
-pl
anpu
nkt
*
Stu
dier
ende
/-r
defin
iert
Leis
tung
für
Fac
h
*
Prü
fung
[Stu
nden
ausm
aß] e
tc.
Stu
dien
-pl
anpu
nkt
(Fac
h)
Stu
dien
-pl
anpu
nkt
(Prü
fung
)
Vor
aus-
setz
ung
benö
tigt
*
Stu
dien
-pl
an
*
Stu
dien
-pl
anbe
nötig
t
Stu
dien
-ko
mm
issi
on
legt
fest
Fac
h-ka
tego
rie
Wah
l- od
er
Pfli
chtfa
ch e
tc.
[Bed
ingu
ng]
etc.
wird
real
isie
rtdu
rch
Stu
nden
-au
smaß
Prü
fung
s-or
dnun
g
ist B
a-si
s fü
r
1
Fer
nstu
dium
-ei
nhei
tbe
steh
ta
us
wird
erse
tzt
durc
h
*
Lehr
ver-
anst
altu
ng
*
Stu
dien
-pl
an
Fac
h-ka
tego
rie
Fer
n-st
udiu
m
Stu
dien
-pl
anpu
nkt
(Fac
h)
Stu
dien
-pl
anpu
nkt
(Prü
fung
)
Vor
aus-
setz
ung
1
Vor
kenn
tnis
Pra
xis
*
Abs
chlu
ß-
arbe
it
[The
ma]
[Zie
le]
[Vor
kenn
tnis
se]
[Met
hode
n] e
tc.
[gle
ichw
ertig
erN
achw
eis]
etc
.
defin
iert
Ers
atz
für
Fäc
her-
kom
bina
tion
Fach
best
eht
au
s
*
Stu
dien
-pl
an
*
Lehr
ver-
anst
altu
ng
Vor
aus-
setz
ung
benö
tigt
*
Stu
dien
-pl
an
auch
indi
vidu
elle
r S
tudi
enpl
an
[Bed
ingu
ng]
etc.
regl
emen
tiert
Stu
dien
-pl
anpu
nkt
(Abs
chlu
ßar
beit)
benö
tigt
Typ
Abs
chlu
ß-
arbe
it
Stu
dien
-pl
anpu
nkt
(Abs
chlu
ßar
beit)
*
Stu
dien
-pl
anle
gt A
ufba
ufe
st v
on
Stu
dien
-ab
schn
ittS
tudi
en-
zwei
g
*
Stu
dien
ab-
schn
itt d
esS
tudi
ums
[Stu
nden
zahl
] etc
.
ist u
nter
-gl
iede
rt in
*[Ges
amts
tund
enza
hl] e
tc.
Stu
dium
*
Stu
dium
*
Stu
dium
*
Stu
dium
Lehr
ver-
anst
altu
ngP
rüfu
ng
cn
cncn
cn
cn
cncn
cc
cncn
cnn
cncn
cn1
cn
cn
ccn
ncn
c
cn
cnn
cncn
cn
c
cn
1
cn
1
cn
1
nn
1
n
cn
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 113 von 163
4.3.2.3 Lehrveranstaltung
Abbildung 52: Semantisches Datenmodell ‘Lehrveranstaltung’
*
Organisations-einheit
*
istbeteiligt
an
Verwaltungs-mitarbeiter
wissenschaftl.Mitarbeiter
*
Mitarbeiter
1
*
LV-Leitung
*
LV-Beteiligung *
Lehrver-anstaltung
Fachbereich
wirddurchgeführt
im
*
Lehrver-anstaltung
Lehrauftrags-rahmen
* *
Semester
Wochen-stunden-zuteilung
cn
Professor AssistentStudiendekan L1-Lehrer
genehmigt beantragt
Lehrver-anstaltungs-
raum
*
Semester
*Felder s.
"2gether - Grobkonzept", S. 57f
Lehrver-anstaltung
*
Zuteilung
[@Belegungszeit] etc.
*
Studierende/-r
[Name][Adresse][WU-Matrikel-nummer] etc.
*
Lehrver-anstaltung
*[Plazierung in der
Anmeldungsreihenfolge]etc.
Lehrver-anstaltungs-anmeldung
Teilnehmer-gruppe
z.B. als Basis für E-Mail-Verteilerlisten
bildet
*
Lehrver-anstaltungs-
termin
[Teilnehmerzahl] etc.
findetstatt an
Anwesenheit
*
Lehrver-anstaltungs-
teilnahme
[(Zwischen-) Ergebnis] etc.
generiert
externeOrganisations-
einheit
interneOrganisations-
einheit
1
ProSeminar
Seminar
Vorlesung
Übung
c
*
Mitarbeiterwird
geleitetvon
Organisations-struktur
AbteilungFachbereich Institut
c
cn 1cn
cn
1
cn cn
cn
cn cn
c 1
cn cn
cn
cn
n
cn
1
cn
cn
1
c
cn
cn
cn
cn
cn
c
cnist übergeordnet
c ist untergeordnet
cn
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 114 von 163 Erstellt gemeinsam m it 15. April 1998
4.3.2.4 Vorlesungsverzeichnis
LV-Ankündigung
SemesterVorlesungs-verzeichnis
enthält
istgültig
für
Lehrver-anstaltung
LV-Ankündigung
wirdgeplantmittels
istzugeordnet
benötigt
Ankün-digungs-bereich
Fach-bezug
Programm
CEMS,
JOSZEF,
English Track
etc.
gehörtzu
LV-Änderungs-ankündigung
wirdgeändert
durchc
LV-Ankündigung
Studien-plan
auch individueller
Studienplan
Voraus-setzung
Fachbereich
Fach-kategorie
FachBildung von- Parallelveranstaltungen- LV-Gruppierungen
LV-Gruppe
istTeilvon
1
n
1
1 c
n
cn
cn
1
cn
cn
cn
cn
cncn
cn
1
1
cn
n
cn
Abbildung 53: Semantisches Datenmodell ‘Vorlesungsverzeichnis’
4.3.2.5 Prüfungen
Abbildung 54: Semantisches Datenmodell ‘Prüfungen’
siehe nächste Seite.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 115 von 163
Stu
dien
-le
istu
ng
Dip
lom
-ar
beit
c
Prü
fung
*
Abs
chlu
ß-
arbe
it
*
cnP
rüfu
ngsa
rt
Dis
sert
atio
nE
rgän
zung
s-pr
üfun
gA
bsch
luß
-pr
üfun
gD
iplo
m-
prüf
ung
Rig
oros
umLe
hrve
r-an
stal
tung
s-pr
üfun
g
Fac
h-pr
üfun
gG
esam
t-pr
üfun
g
Fac
hLe
hrve
r-an
stal
tung
*
über
prüf
tLe
hrin
halte
von
über
prüf
tLe
hrin
halte
von
Ter
min
(-lis
te)
des
wis
s.M
A's *
(Prü
fung
s-)
Ter
min
liste
*
defin
iert
Prü
fung
s-an
mel
dung
gibt
Prü
-fu
ngst
erm
infü
r
[Prü
fung
szei
t] et
c.
Prü
fung
s-te
rmin
*
Sem
este
r
*
Term
in
Stu
dier
ende
/-r *
Prü
fung
*
wis
sens
chaf
tl.M
itarb
eite
r
Prü
fung
*
Sem
este
r
*
Prü
fung
ende
s w
iss.
MA
'sim
Sem
este
r
[Anm
eldu
ngsz
eitr
aum
][T
eiln
ehm
erza
hlen
][Z
utei
lung
ssys
tem
] et
c.
*
Res
ervi
erun
g *
Prü
fung
s-ko
mbi
natio
n
[Beu
rtei
lung
][S
tatu
s] e
tc.
Prü
fung
des
Stu
dier
ende
n *
gene
rier
t
erfo
rder
tW
arte
liste
[Pos
ition
] et
c.
War
telis
ten-
posi
tion
*
Ra
um
*
wis
sens
chaf
tl.M
itarb
eite
r
Prü
fung
s-be
teili
gung
[# T
eiln
ehm
er]
Prü
fung
s-le
itung
tlw. v
omS
tude
nten
gew
ählt
Prü
fung
s-th
emen
-be
reic
h
n cn
1 cn
cn
1cn
1
ncn
cn
1
cn cn
cncn
cn c
cn
setz
t si
ch z
usam
men
aus
geht
ein
in
cn
c
1
c
1n
c
n
cn1
cn
cncn
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 116 von 163 Erstellt gemeinsam m it 15. April 1998
4.3.2.6 An- und Abmeldung
Lehrver-anstaltungs-anmeldung
Anmeldung
Prüfungs-anmeldung
1
giltfür
Studiumdes
Studierenden
1 cn
Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 117 von 163
4.3.2.7 Diplomarbeiten und Dissertationen
*[Thema][Ziele]
[Vorkenntnisse][Methoden] etc.
Abschluß-arbeit
[Thema][Ziele]
[Vorkenntnisse][Methoden] etc.
Abschluß-arbeit
WU-Ab-schlußarbeit-
datenbank
bestehtaus
Fachwissenschaftl.Mitarbeiter
Studierende/-r
Abschluß-arbeitbe-treuung
*
[Status]Vergabe
*
[Fachrolle]- Erstfach
- Nebenfach
gehörtzu
[Beurteilung] etc.
Abschluß-arbeitbe-
gutachtung
1
WU-Themen-datenbank
WU-Dipl./Diss.-Datenbank
Diplom-arbeit
1
Dissertation
TypAbschluß-
arbeit
typisiertdurch
n
1
n cn
cn
cn
1
cncn cn
1
cn
Abbildung 56: Semantisches Datenmodell ‘Abschlußarbeiten’
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 118 von 163 Erstellt gemeinsam m it 15. April 1998
4.3.2.8 Anerkennung
Abbildung 57: Semantisches Datenmodell ‘Anerkennung’
Ane
rken
nung
s-an
trag
Ane
rken
nung
s-be
sche
id
*
Stu
dier
ende
/-r *
veru
rsac
ht
stel
lt
bein
halte
tA
nerk
ennu
ngs-
gege
nsta
nd
Nos
trifi
zier
ung
etc.
*
c
Wis
s. T
ätig
-ke
it de
sS
tudi
eren
den
Wis
s. A
rbei
tde
sS
tudi
eren
den
ausl
ändi
sche
rS
tudi
enab
schl
ußde
s S
tude
nten
Prü
fung
des
Stu
dier
ende
n *
Ver
wal
tung
s-m
itarb
eite
r
Term
in
Ter
min
(-lis
te)
des
VM
A's
(Vor
lage
-)Te
rmin
liste
*
defin
iert
gibt
Vor
-la
gete
rmin
für
Vor
lage
-te
rmin
bear
beite
t
Stu
dien
-pl
anpu
nkt
*
bezi
eht
sich
auf
cn1c1
n
1
cn
cn
11
cn cn
1
n
cn1
c
cn
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 119 von 163
4.3.2.9 Abrechnung
wissenschaftl.Mitarbeiter
s. "2gether - Grobkonzept", S. 90
1
internerMitarbeiter
externerMitarbeiter
Prüfungs-beteiligung
s. "2gether - Grobkonzept", S. 91
Leistung
Abgeltung
c
erfolgtnach
[Regelwerk] etc.
Lehrauftrag, remuneriert
Lehrauftrag, nicht remuneriert
Kollegiengeld
Tutorengeld
Prüfungstaxe
Abgeltungs-art
*
Abrechnung Abrechnungs-position
LV-Leitung
LV-Beteiligung
Prüfungs-leitung
Abschluß-arbeitbe-treuung
Abschluß-arbeitbe-
gutachtung
cn
1
1 cnn cn
Abbildung 58: Semantisches Datenmodell ‘Abrechnung’
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 120 von 163 Erstellt gemeinsam m it 15. April 1998
4.3.2.10 Hörsaalverwaltung
[Größe][Ausstattung] etc.
Raum
1
zweck-gebundener
Raum
instituts-eigenerRaum
EDV-Schulungs-
raum
c
1
internerRaum
z.B. Austria CenterexternerRaum
Mitarbeiter
[@Belegungszeit] etc.
Reservierung
persönlicherRaum
Raum-anrecht
(Prüfungen)
Termin(-liste)des wiss.MA's Reservierung
Raum fürsonstige
Veranstaltung
Lehrver-anstaltungs-
raum
Hörsaal Seminar-raum
LV-Ankündigung
1
Zuteilung
[@Belegungszeit] etc.
Reservierung
Semester Abteilung
Raum-anrecht
Mitarbeiter
c
cn cn
cn
cncn
1
cn
cn
cn
1
cn
cn
Abbildung 59: Semantisches Datenmodell ‘Hörsaalverwaltung’
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 121 von 163
4.3.2.11 Evaluierung
Abbildung 60: Semantisches Datenmodell ‘Evaluierung’
[Tei
lnah
mef
requ
enz]
[Beu
rtei
lung
] etc
.
Lehr
ver-
anst
altu
ngs-
beur
teilu
ng
wird
beur
teilt
durc
h
Lehr
ver-
anst
altu
ng
[Zie
lerf
üllu
ng]
[Did
aktik
][L
ernb
ehel
fe]
[Bet
reuu
ng] e
tc.
Erh
ebun
gs-
boge
n
faßt
zusa
mm
en
Eva
luie
rung
1
inte
rne
Org
anis
atio
ns-
einh
eit
Arb
eits
-be
richt
Anz
ahl v
on:
[wis
s. In
stitu
tspe
rson
al]
[abg
ehal
tene
Leh
rver
anst
altu
ngen
][d
urch
gefü
hrte
Beu
rtei
lung
en] e
tc.
sow
ie B
elas
tung
sana
lyse
Stu
dien
-ja
hr
Win
ter-
sem
este
r
Sem
este
r
Som
mer
-se
mes
ter
1
Stu
dien
-ja
hr
1c
n c
cn
cn
1 1
4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“ 4.3 Konzeptionelles Datenschema
Seite 122 von 163 Erstellt gemeinsam m it 15. April 1998
4.3.2.12 Adresse
Adresse
Studierende/-r
Mitarbeiter
Organisations-einheit
Anschriftder Org.-Einh.
Anschriftdes MA's
Heimatan-schrift des
Studierenden
Studienan-schrift des
Studierenden
cccc
1
n
11
Abbildung 61: Semantisches Datenmodell ‘Adresse’
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 123 von 163
5 MENGEN- UND WERTGERÜST
Die folgende Tabelle 7 enthält eine Auflistung des Mengengerüstes, das für das zukünf-tige System ‘2gether’ von Bedeutung ist. Dabei wurden im wesentlichen drei Quellen berücksichtigt: das ‘Grobkonzept 2gether’, die Diplomarbeit von Mag. S. Schmidt sowie eine Auswertung zur Belastung der Institute im Studienjahr 1996/97 (vgl. Literaturliste im Anhang).
Unter der Spalte ‘Objekttyp’ erfolgt eine Klassifizierung der beschriebenen Größen in Form einer Einstufung einerseits als reine Benutzung des Systems, d.h. als Funktionali-tät („Fkt.“), andererseits als daten- (satz-) erzeugend („Ds.“). Letztere Größe hat (zu-nächst) Auswirkung auf den Speicherbedarf, erstere auf die Zugriffshäufigkeit.
Bereich Häufigkeit Bemerkung Objekttyp Jahr
(Erst-)Zulassung 4.500 - 8.000 p.a. Schwerpunkt 1. Zulas-sungswoche
Fkt., Ds. 1997
(pers.) Stundenplan 15.000 p.sem. zeitliche Spitzen Fkt. 1997
(weitere) Zulassung, Wech-sel
3.000 - 5.500 p.a. Fristen Fkt., Ds. 1997
Abmeldung v. Studienrich-tung
1.000 p.a. Fkt. 1997
Abmeldung v. Studium 60 % d. Stud. aufwendig, zeitintensiv Fkt. 1997
Abmeldung von LV 30.000 p.a. zeitliche Spitzen Fkt. 1997
Abmeldung von Teildiplom-prüfung
6.000 p.a. Fristen Fkt. 1997
Abrechnungen 5.000 LV’s, 144.000 Prüf., 1.100 wiss. Arb.
Fkt., Ds. 1997
Änderung PIN 30.000 p.a. Fkt. 1997
Anerkennungsanträge 5 - 6.000 p.a. große Belastung Fkt., Ds. 1997
Anerkennungsbescheide 16.000 p.a. Fkt., Ds. 1997
Anmeldung zu LV 122 - 144.000 p.a. zeitliche Spitzen Fkt., Ds. 1997
Anmeldung zu Teildiplom-prüfung
23.000 p.a. zeitliche Spitzen Fkt., Ds. 1997
5 MENGEN- UND WERTGERÜST
Seite 124 von 163 Erstellt gemeinsam m it 15. April 1998
Bereich Häufigkeit Bemerkung Objekttyp Jahr
Aufnahme LV’s 2 p.a. à 2.500 Fkt. 1997
Auskunft 100.000 p.sem. Fkt. 1997
Erstellung/Wartung Stu-dienpläne
4-20 ohne individuelle Fkt., Ds. 1997
Evalierung LV 122 - 144.000 p.a. Fkt., Ds. 1997
Generierung IDFile 30.000 p.a. Fkt. (Ds.) 1997
Generierung TAN’s 15.000 p.sem. Fkt. 1997
Leistungsfeststellung 100.000 LV’s 10.000 Dipl.
Fkt., Ds. 1997
Planung LV’s 2 p.a. à 2.500 Fkt., Ds. 1997
Planung Prüfungen 2 p.a. Fkt., Ds. 1997
Planung Studienjahr-einteilung
1 p.a. Fkt. , Ds.
Prüfungsanmel dungen 12.750 Dipl. 125.000 Prüf.
Fkt., Ds. 1997
Raumverwaltung 3.700 p.a. Fkt., Ds. 1997
Rückmeldung 52 - 65.000 p.a. großer Aufwand Fkt., Ds. 1997
Standard-Ausdrücke z.B. 2.700 Diplome p.a.
Fkt. 1997
Studienabschluß 1.300 - 1.600p.a. Fkt. 1997
VVZ-Zugriff 75.000 p.sem. zeitliche Spitzen Fkt. 1997
Wartelisteeinträge Teildip-lomprüfung
30.000 p.a. Fristen Fkt., Ds. 1997
Wiss. Arbeiten 1.000 Dipl., 100 Diss.
Fkt., Ds. 1997
Tabelle 7: Mengengerüst der Studien- und Prüfungsverwaltung i.w.S.
Darüber hinaus ist dieses Mengengerüst in die Abschätzung des Nutzenpotentials ein-geflossen (siehe Kapitel 8).
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 125 von 163
6 DATENSCHUTZ UND DATENSICHERHEIT
6.1 Schutzbedarfsermittlung
Durch eine angemessene IT -Sicherheitsstrategie soll die Datensicherheit zur Gewähr-leistung einer ordnungsgemäßen Informationsverarbeitung (im Interesse der datenver-arbeitenden Stellen) und der Datenschutz bei der Verarbeitung personenbezogener Da-ten (im Interesse der betroffenen Studenten und Mitarbeiter) gewährleistet werden.
Da bei der Studien- und Prüfungsverwaltung personenbezogene Daten verarbeitet wer-den, ist das dargestellte Schutzstufenkonzept bei der Beurteilung der einzelnen Funkti-onalitäten zu Grunde gelegt, wobei auch der Verwendungszusammenhang der zu ver-arbeitenden Informationen berücksichtigt ist. Der Schutzbedarf der 2gether-Teilsysteme richtet sich nach dem Schutzbedarf seiner bedürftigsten Anwendung.
Ergibt sich ein niedriger oder mittlerer Schutzbedarf, ist ein standardisiertes IT -Sicherheitskonzept zu erstellen, wie es beispielsweise das IT-Grundschutzhandbuch des BSI, „Bundesamt für Sicherheit in der Informationsverarbeitung“ (Deutschland) zur Risikoanalyse und zur Auswahl der erforderlichen Maßnahmen bereitstellt.
Ergibt sich ein hoher oder sehr hoher Schutzbedarf, so ist ein individuelles Sicherheits-konzept – basierend auf weiterführenden individuellen Sicherheitsuntersuchungen – zu erstellen. Dazu gehören eine ausführliche Schutzbedarfsfeststellung für alle Objekte, eine Bedrohungs - und Risikoanalyse und ein IT-Sicherheitskonzept, das eine Auswahl und Bewertung der Maßnahmen, eine Kosten-/Nutzen-Betrachtung und eine Restrisiko-analyse enthält.
Das IT-Sicherheitskonzept ist umzusetzen durch: Abgleich vorhandener Maßnahmen mit dem Sollkonzept, Realisierung der offenen Maßnahmen, Realisierung der daten-schutzrechtlichen Anforderungen, Beteiligung des Beauftragten für Datenschutz, Frei-gabe des Verfahrens, Schulung der Anwender, Inbetriebnahme des Verfahrens.
6.1.1 Schutzstufenkonzept
6.1.1.1 Stufe I
Niedriger/geringer Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung keine besondere Beeinträchtigung des informationellen Selbstbestim-mungsrechts erwarten läßt.
Beispiele:
6 DATENSCHUTZ UND DATENSICHERHEIT 6.1 Schutzbedarfsermittlung
Seite 126 von 163 Erstellt gemeinsam m it 15. April 1998
Name, Anschrift, Beruf, Geburtsjahr, Tel.-Nr., Titel, Telefonverzeichnis, Adreßangaben, Bankverbindungen, Adreßdaten von Funktionsträgern an der Wirtschaftsuniversität
Mittlerer Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbei-tung eine besondere Beeinträchtigung des informationellen Selbstbestimmungsrechts insofern erwarten läßt, als der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen beeinträchtigt werden kann.
Beispiele:
Kontenstände, Familienstand, Zeugnisse, Prüfungsergebnisse, Versicherungsdaten, Wehrdienstzeit, Grad der Behinderung, Personalverwaltungsdaten aus dem Beschäfti-gungsverhältnis (mit Ausnahme von dienstlichen Beurteilungen, berufliche Laufbahn, nähere Angaben über Behinderung u. dgl.), Studentendaten.
Die einzelnen Maßnahmen für die Sicherstellung des Schutzbedarfs der Stufe I können dem IT-Grundschutz (für mittleren Schutzbedarf) entnommen werden.
6.1.1.2 Stufe II
Hoher Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung eine erhebliche Beeinträchtigung des informationellen Selbstbestimmungsrechts inso-fern erwarten läßt, als der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt werden kann oder die Daten auf-grund ihrer besonderen Sensibilität bzw. ihres Verwendungszusammenhangs einen höheren Schutzbedarf als Stufe I erfordern.
Beispiele:
besonders sensible Sozialdaten, Steuerdaten, Daten, die einem Berufs-, Geschäfts-, Fernmelde- oder Mandantengeheimnis unterliegen, Personalverwaltungsdaten (dienstli-che Beurteilungen, berufliche Laufbahn u. dgl.) soweit nicht Stufe I, als „streng vertrau-lich“ eingestufte Verwaltungsdaten.
Sehr hoher Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbei-tung eine sehr hohe Gefährdung des informationellen Selbstbestimmungsrechts ins o-fern erwarten läßt, als eine Gefahr für Leib und Leben oder die persönliche Freiheit des Betroffenen gegeben ist.
Beispiele:
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 127 von 163
Adressen von polizeilichen V-Leuten, Adressen von Zeugen in bestimmten Strafverfah-ren.
Als Maßnahme für die Sicherstellung des Schutzbedarfs der Stufe II ist ein maßge-schneidertes Sicherheitskonzept nach individueller Bedrohungs - und Risikoanalyse („IT -Grundschutz + X“) zu erstellen.
Ausgehend von der oben dargestellten Schutzbedarfsermittlung sind zur Realisierung des IT-Grundschutzes bei IT -Vorhaben – wie dem Projekt „2gether“ – für folgende Be-reiche entsprechende Maßnahmen zu treffen:
• Organisation,
• Personal,
• Notfallsvorsorgekonzept,
• Datensicherungskonzept,
• Datenschutzkonzept,
• Gebäude,
• Verkabelung,
• Büroräume,
• Serverräume/Rechnerraum,
• Datenträgerarchiv,
• Räume für technische Infrastruktur,
• lokales Netzwerk,
• TK-Anlage,
• vernetzte PCs.
6.1.2 Schutzbedarf im Projekt „2gether“
Es wird empfohlen, im Rahmen des Projekts „2gether“ folgende Schutzbedarfszuord-nung vorzunehmen:
Gruppe Modul Schutzbedarf Stufe
6 DATENSCHUTZ UND DATENSICHERHEIT 6.1 Schutzbedarfsermittlung
Seite 128 von 163 Erstellt gemeinsam m it 15. April 1998
Lehrveranstaltungen Administration Lehrveranstaltung mittel I
Aufnahme Lehrveranstaltung mittel I
Planung Lehrveranstaltung kein I
Prüfungen Leistungsfeststellung mittel I
Planung Prüfungstermin niedrig/gering I
Studien Beendigung Studium mittel I
Rückmeldung Studium niedrig/gering I
Wechsel Studium/Aufnahme Zusatzstudi-um
mittel I
Zulassung Studium mittel I
Einreichung, Beurteilung & Veröffentl ichung mittel I Diplomarbeiten & Dis-sertationen
Laufende Betreuung niedrig/gering I
Themenvereinbarung niedrig/gering I
Anerkennungen Anerkennung durchführen mittel I
Anerkennung vorbereiten mittel I
Bescheide der Anerkennung ausfert igen mittel I
Abrechnungen Abrechnung mittel I
Evaluierungen Arbeitsbericht Institutsvorstände kein I
Beurteilung Lehrveranstaltung niedrig/gering I
An- und Abmeldungen Lehrveranstaltungsanmeldung durchführen mittel I
Prüfungsabmeldung durchführen mittel I
Prüfungsanmeldung durchführen mittel I
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 129 von 163
Gruppe Modul Schutzbedarf Stufe
Allgemeine Module Hörsaaladministration kein I
Chipkartenverwaltung hoch II
Tabelle 8: Zuordnung des Schutzbedarfes
6.2 Chipkarten
Wichtige Funktionalitäten der Chipkarten sind:
• Chipkarten als Speicher von Daten, die hinsichtlich ihrer Vertraulichkeit und/oder Integrität hohen Schutzbedarf aufweisen (z. B. Kontodaten, Per-sonalverwaltungsdaten, Sozialdaten);
• Chipkarten als Mittel zur Authentisierung ihres Trägers für die Gewährung des Zugriffs auf sicherheitsrelevante Daten und Funktionen (Kontoverfügun-gen, Änderung prüfungsrelevanter Individualdaten);
• Chipkarten als Mittel zur Signatur von Dokumenten (Anerkennungsbeschei-de, Willenserklärungen [Lehrveranstaltungs- und Prüfungsanmeldungen], Prüfungsergebnisse etc.);
• Chipkarten als Träger elektronischer Geldbörsen.
Für den datenschutzgerechten Einsatz von Chipkarten ist eine konsequente und über-zeugende Sicherungstechnologie erforderlich. Datensicherungsmaßnahmen müssen in ihrer Gesamtheit einen hinreichenden Schutz der Daten vor Mißbrauch gewährleisten. Dabei ist von folgenden Gefahren auszugehen:
• unbefugte Preisgabe von Informationen (Verlust der Vertraulic hkeit);
• unbefugte Veränderung von Informationen (Verlust der Integrität);
• unbefugte Vorenthaltung von Informationen oder Betriebsmitteln (Verlust der Verfügbarkeit);
• unbefugte Änderung identifizierender Angaben (Verlust der Authentität).
Diese Gefahren sind sowohl dann zu betrachten, wenn die Daten auf der Chipkarte ge-speichert werden, als auch dann, wenn sie in einer externen Datenbank gespeichert werden, die durch Chipkarten erschlossen wird.
Das Sicherungskonzept für Chipkarten sollte folgende Mindestanforderungen erfüllen:
6 DATENSCHUTZ UND DATENSICHERHEIT 6.2 Chipkarten
Seite 130 von 163 Erstellt gemeinsam m it 15. April 1998
• Ausstattung des Kartenkörpers mit fälschungssicheren Authentisierungs-merkmalen wie z.B. Unterschrift, Foto, Hologramme.
• Steuerung der Zugriffs- und Nutzungsberechtigungen durch die Chipkarte selbst.
• Realisierung aktiver und passiver Sicherheitsmechanismen gegen eine un-befugte Analyse der Chip-Inhalte sowie der chipintegrierten Sicherheitsfunk-tionen.
• Benutzung allgemein anerkannter, veröffentlichter Algorithmen für Ver-schlüsselungs- und Signaturfunktionen sowie zur Generierung von Zufalls-zahlen.
• Sicherung der Kommunikation zwischen der Chipkarte, dem Chipkartenba-sierten Dienstleistungssystem (CDLS) und dem ggf. im Hintergrund wir-kenden System durch kryptographische Maßnahmen.
• Sicherung unterschiedlicher Chipkartenanwendungen auf einer Chipkarte durch gegenseitige Abschottung.
• Durchführung einer gegenseitigen Authentisierung von Chipkarte und CDLS mit dem Challenge-Response-Verfahren.
Grundsätzlich sollte zunächst die Möglichkeit in Betracht gezogen werden, daß bei der Chipkartenbenutzung Anonymität gewahrt bleiben kann. Ist dies nicht möglich, sollten Wahlmöglichkeiten anonymer Alternativen geschaffen werden.
Der Chipkarteninhaber bzw. die Betroffenen sollten die Möglichkeit erhalten, auf neutra-len, zertifizierten Systemumgebungen die Dateninhalte und Funktionalitäten ihrer Chip-karten einzusehen (Gebot der Transparenz).
Die gesamte Infrastruktur ist zu dokumentieren und die Produktion, die Initialisierung und der Versand der Chipkarten zu überwachen.
Wie in der Einleitung kurz dargestellt, sind Chipkarten nicht als isolierte Träger von Ris i-ken zu betrachten, wenn es um Fragen ihrer IT -Sicherheit geht. Aufwendige sicherheits-technische Maßnahmen an und in der Chipkarte können durch unsichere Systemumge-bungen bei der weiteren Verwendung der Daten konterkariert werden.
Wenn zum Beispiel das System der Studien- und Prüfungsabteilung nicht den erforder-lichen Schutz bietet, können die Schutzmaßnahmen der Karte umgangen werden. Der Schutz der Chipkarte gegen unbefugte Manipulationen ist weitgehend wertlos, wenn beim elektronischen Zahlungsverkehr das POS-Terminal leicht manipuliert werden kann. Jedoch sieht ISO/IEC 7816 Schutzmechanismen vor, die bei richtiger Anwendung mit vertretbarem Aufwand nicht umgangen werden können.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 131 von 163
Allgemein sind an die Sicherheitsfunktionen folgende Anforderungen zu stellen:
• Zugriffs- und Nutzungsberechtigungen sollten soweit möglich von der Chip-karte selbst geprüft und gesteuert werden.
• In Anwendungen sollten sich alle beteiligten Rechner (inkl. Chipkarten) ge-genseitig authentifizieren. Die Authentifizierung des Benutzers hat gegen-über der Chipkarte zu erfolgen.
Sicherheitserwägungen greifen bereits bei der Herstellung, Initialisierung und dem Ver-sand von Chipkarten. Dabei müssen
• die Produktion der Prozessoren und Chipkarten,
• die Produktion und das Laden von Software,
• das Erzeugen der Schlüssel,
• das Laden der Schlüssel in die Sicherheitsmodule (Internal Elemetary Fi-les),
• das Laden von Hersteller- und Transportschlüssel für die spätere Initialisie-rung und
• die Ausgabe der Chipkarten und Transportschlüssel an den Empfänger, insbesondere der Versand an die Studierenden
durch entsprechende technische und organisatorische Maßnahmen abgesichert wer-den.
Zunächst sollte sichergestellt sein, daß sich nicht alle Teile des Betriebssystems im ROM befinden, damit der Chiphersteller nicht über das ganze Wissen über die Siche-rung der Chipkarte verfügt. Wesentliche Teile des Betriebssystems können bei der spä-teren Initialisierung über entsprechend authentisierte CDLS dynamisch aus Tabellen ge-laden werden (siehe auch Grobkonzepts 2gether, Kapitel 6.2, „Chipkartenverwaltung“).
Darüber hinaus sollte das Betriebssystem in folgender Weise Sicherheit „erzeugen“:
• Die Identifizierung und Authentifizierung des Benutzers erfolgt mittels PIN oder mit biometrischen Verfahren.
• Üblicherweise erfolgt die Prüfung einer PIN. Zwar können die normale For-derungen zur Paßwortverwaltung bei Rechnern nicht voll auf Chipkarten ü-bertragen werden, jedoch sollte die PIN-Länge je nach Sensibilität mindes-tens 4 oder mehr Stellen betragen, die Anzahl der Fehlversuche begrenzt sein, die Möglichkeit bestehen, die PIN zu ändern und eine Freischaltung der Karte auch mittels Personal Unblocking Key (PUK) in Abhängigkeit von der Anwendung ermöglicht werden.
6 DATENSCHUTZ UND DATENSICHERHEIT 6.3 Internet
Seite 132 von 163 Erstellt gemeinsam m it 15. April 1998
• Es erfolgt eine Zugriffskontrolle mit einer Rechteverwaltung, wobei die Zugriffsrechte an die einzelnen Dateien geknüpft werden. Den Dateien sind Sicherheitsattribute zugeordnet, mit denen festgelegt wird, ob die Dateien (Daten) gelesen, kopiert, beschrieben, gelöscht, gesperrt oder freigegeben werden dürfen.
• Wenn anderen Personen als dem Karteninhaber Zugriffsmöglichkeiten auf die Chipkarte gewährt werden sollen, erfolgt dies im Rahmen einer Pro-gramm-Programm-Kommunikation mit einem anderen Rechner oder einer anderen Karte (z.B. mit einer Professional Card). Der Rechner bzw. die an-dere Karte muß authentifiziert werden.
Zwar bilden – wie oben festgestellt – Chipkarten und CDLS erst zusammen ein vollwer-tiges Rechensystem, jedoch befinden sich beide Komponenten in der Regel in unter-schiedlicher Verfügungsgewalt, die Karte in der des Inhabers und das CDLS in der von Anwendern.
Wenn eine Chipkarte in ein CDLS eingeführt wird, gibt der Inhaber, d. h. z. B. der Stu-dent/die Studentin, die Verfügungsgewalt über die Software auf der Karte und die ihn betreffenden Datenbestände auf. Eine unbefugte Veränderung der Software muß daher technisch verhindert werden.
Der Karteninhaber sollte daher nicht nur die Möglichkeit haben, sich den Inhalt der ge-speicherten Daten anzeigen zu lassen, sondern die tatsächlichen Funktionen z. B. auf neutralen CDLS testen zu können. Wegen der u. U. unterschiedlichen Interessenlagen (z. B. bei der Anmelde- und Prüfungsadministration) ist die Prüfung der korrekten Funk-tion der Software sowie umgekehrt des Ausschlusses ungewollter Funktionen im reali-sierbaren Rahmen zu ermöglichen.
Als besonders angriffsgefährdet sind CDLS vom Typ „PC mit Kartenterminal“ anzuse-hen, sofern sie nicht in manipulationsgeschützten Umgebungen eingesetzt werden. Er-höhte Schutzfunktionen werden hier als notwendig angesehen.
6.3 Internet
Mit dem Zugang zum Internet sind Risiken verbunden, die größtenteils daraus resul-tieren, daß dieses Datennetz nicht unter Sicherheitsaspekten entwickelt wurde und his-torisch gewachsen ist. Schwächen finden sich in den Protokollen für die Datenübertra-gung, in den Implementierungen und Installationen der Programme für die Internet-Dienste und in den angeschlossenen Übertragungswegen und Rechnersystemen.
Dies ist besonders gravierend, weil aufgrund der riesigen Zahl von Internet-Teilnehmern auch die Zahl der potentiellen Angreifer, die diese Sicherheitslücken ausnützen und so-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 133 von 163
mit die am Internet angeschlossenen Verwaltungsrechner und -netze bedrohen können, sehr groß ist.
Sensible Daten, insbesondere personenbezogene Daten, sind bei entsprechendem Schutzbedarf mit Hilfe hinreichend sicherer, kryptographischer Verfahren zu verschlüs-seln; hierzu gehören auch Paßwörter und sonstige Authentifikationsdaten. Es sollte an-gestrebt werden, generell alle Transport- und Verkehrsdaten auf möglichst niedriger Protokollebene zu verschlüsseln und sichere Authentisierungsverfahren einzusetzen. Bei asymmetrischen Verschlüsselungsverfahren sollte eine vertrauenswürdige, zentrale Stelle mit der Funktion der Schlüsselerzeugung und -verwaltung (Trust-Center) beauf-tragt werden.
Übernommene Programme und Dokumente sind vorab mit einem aktuellen Viren-scanner auf Virenfreiheit zu testen. Wenn möglich, sollte auch die Integrität der Daten überprüft werden, wozu z. B. Verfahren der elektronischen Unterschrift und/oder Prüf-summenverfahren genutzt werden können.
Da ein Netzanschluß der Rechner im Rahmen der Studien- und Prüfungsadministration unbedingt erforderlich ist, sollte die Sicherheit der Verwaltungsnetze und der Schutz von personenbezogenen Daten, die auf vernetzten Systemen verarbeitet werden, durch den Einsatz geeigneter Schutzkonzepte mit Hilfe einer zwischengeschalteten Prüf- und Fil-terfunktion (Firewall) gewährleistet werden.
Der ausschließliche Einsatz einer zentralen Firewall-Lösung ist nur dann vertretbar, wenn sich die Sicherheitsmaßnahmen an den Daten orientieren, die den höchsten Schutzbedarf haben.
Da jedoch das WU-Netz aus einer Vielzahl verschiedener Teilnetze besteht, in denen Daten unterschiedlicher Sensibilität verarbeitet werden, empfiehlt es sich, das Konzept gestufter Firewalls anzuwenden. Die Anbindung an das Internet sollte allerdings nur ü-ber einen zentralen Zugang (Gateway) erfolgen.
Werden in den anzuschließenden Netzen sensible personenbezogene Daten verar -beitet, ist der hohe personelle und sachliche Aufwand für Firewall-Lösungen gerecht-fertigt und geboten. Firewall-Konzepte stellen erhöhte Anforderungen an die lokale Sys-temverwaltung, da Administrationsfehler in diesem Bereich ungleich schwerwiegendere Konsequenzen haben können als bei isoliert betriebenen Rechnern.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 135 von 163
7 MIGRATIONSKONZEPT
7.1 Allgemeines
Den folgenden Ausführungen zum Migrationsplan (wie auch den Wirtschaftlichkeitsbe-trachtungen in Kapitel 1) liegen die Aufwandsschätzungen der Firma Alper & Pesch Ges.m.b.H. zugrunde, die diese auf Grundlage des „Grobkonzepts 2gether“ im Juni 1997 vorgenommen hat.
Aufgrund des geschätzten Gesamtaufwandes für die Realisierung des „2gether“-Projekts von ca. 36 Personenjahren ist ein Realisierungszeitraum von 3 Jahren als rea-listisch und machbar anzusehen und wird in diesem Ausmaß auch von uns em pfohlen.
Basierend auf den derzeitigen Gegebenheiten bietet sich eine stufenweise Einführung des neuen Systems an (siehe Punkt 7.6). Der Stufenplan sieht eine vorrangige Ablöse der BS2000-Anwendungen vor; die Übernahme der Funktionalität der WUFIS -Anwendungen erfolgt erst in einer oder mehreren nachfolgenden Stufen.
Der empfohlene Projektablauf orientiert sich an folgenden Basis -Terminen:
1998 1999 2000 2001 2002
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Implementierung Stufe I Echtbetrieb Stufe I ð
Implementierung Stufe II Echtbetrieb St. II ð
Tabelle 9: Empfohlene Basistermine
Der vorgeschlagene Terminplan beruht auf den in den folgenden Punkten ausgeführten Überlegungen.
7 MIGRATIONSKONZEPT 7.2 Ablöse STEPDB und INSTDB
Seite 136 von 163 Erstellt gemeinsam m it 15. April 1998
7.2 Ablöse STEPDB und INSTDB
Bei der Ablöse der alten Datenbankanwendungen durch die neue Software im Rahmen des 2gether-Projektes sind folgende Kriterien zu beachten:
7.2.1 Datenübernahme
Sobald – wie im gegenständlichen Fall – sich die geplante neue Datenbankstruktur we-sentlich von der alten unterscheidet und es gleichzeitig unmöglich ist, die neuen An-wendungen ohne „Altdaten“ zu starten, stellt die Datenübernahme eine erhebliche Er-schwernis für die Betriebsaufnahme dar. Erfahrungsgemäß treten hierbei Probleme der folgenden Arten auf:
• Die Altdaten entsprechen nicht den Konsistenzbedingungen der neuen Da-tenbank.
• Die Altdaten können nicht sämtliche notwendigen Felder der neuen Daten-bank beschicken.
• Die Umschlüsselung bestimmter Felder ist nicht eindeutig geklärt.
• Die Altdaten weisen Datenfehler auf, die bis dato nicht erkannt oder einfach hingenommen wurden.
• Die Normalisierung bringt nicht den gewünschten Erfolg, weil durch – meist geringfügige – Abweichungen in der Schreibweise Daten nicht zusammen-finden.
Erschwerend tritt hinzu, daß sich im – bis zuletzt lebenden – Altbestand auch noch zwi-schen dem letzten Test und der realen Übernahme derartige Problemfälle ergeben kön-nen. In dieser Hinsicht kann die stichtagsgenaue fehlerfreie Datenübernahme überhaupt nur nach Festlegung eines Änderungsstops der Altanwendung garantiert werden.
Der Umfang allfällig erforderlicher manueller Eingriffe nach der Datenübernahme kann in bezug auf neu hinzukommende Felder frühzeitig geschätzt werden, nicht aber in bezug auf erst bei der Überleitung auftretende Datenfehler und Inkonsistenzen.
Im Detail können konkrete Aussagen über die Datenübernahme erst nach endgültiger Festlegung der neuen Datenbankstruktur gemacht werden.
7.2.2 Anmerkungen zur Synchronisation von Datenbanken
Eine permanente Online -Synchronisation großer Datenbanken ist praktisch ausge-schlossen. So lange der Altdatenbank die Führung des aktuellen Standes obliegt, muß von der Altanwendung aus nach jeder Datenbankveränderung eine analoge Verände-
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 137 von 163
rung der neuen Datenbank angestoßen und anschließend ein gemeinsames Commit abgesetzt werden. Dies erscheint im gegenständlichen Fall aus folgenden Gründen nicht realisierbar:
• Zu hoher Änderungsaufwand in den Altanwendungen.
• Notwendigkeit eines 2-Phasen-Commit über zwei Datenbanken unter-schiedlicher Technologie.
Hat die Neudatenbank die Führung inne, so stellt sich das umgekehrte Problem, näm-lich daß in den Neuanwendungen die Datenbankveränderungen im Altsystem mitbetreut werden müssen. Komplizierte Eingriffe in die Logik der Altprogramme wären somit auf alle Fälle erforderlich.
Eine regelmäßige Batch-Synchronisation ist grundsätzlich möglich. Der Nachteil die-ser Methode liegt allerdings in den zu erwartenden hohen Laufzeiten für den regelmäßig notwendigen Datenabgleich, der zumindest die Tagfertigkeit der Datenbanken sicher-stellen sollte. Bei dem derzeitigen hohen Änderungsaufkommen kann davon ausgegan-gen werden, daß im vorliegenden Falle Tagfertigkeit nicht erreicht werden kann.
Eine schrittweise Übernahme der derzeitigen STEPDB- und INSTDB-Anwendungen ist daher – allein wegen der aufgezeigten unzureichenden Synchronisationsmöglichkeiten – nicht als sinnvoll anzusehen. Es muß somit von der Notwendigkeit ausgegangen wer-den, beide Datenbanken an einem gemeinsamen Stichtag umzustellen.
7.3 Zeitlicher Aspekt
Nach Aussagen des Herstellers SNI ist die derzeitige Version des Betriebssystems BS2000 und des Datenbanksystems UDS im Jahre 2000 nicht mehr lauffähig. Als Kon-sequenz muß
• entweder auf die neuen Releases von BS2000 und UDS umgestiegen wer-den
• oder die Datenbanken STEPDB und INSTDB werden noch vor dem Jahr 2000 außer Betrieb genommen.
Seitens der ADV wird glaubwürdig versichert, daß die Datenbankanwendungen STEPDB und INSTDB selber kein Problem im Zusammenhang mit dem Jahrhundert-wechsel bereiten. Die Weiterverwendung der alten Anwendung verursacht demnach ausschließlich aufgrund notwendiger Systemadaptierungen (bei Hardware und Soft-ware) zusätzliche Kosten, und zwar in Höhe von fast 3 Mio. öS.
Die Alternative, die BS2000-Systeme mit Ende 1999 außer Betrieb zu nehmen, kann nur unter enormem Zeitdruck realisiert werden. Da über STEPDB und INSTDB vor al-
7 MIGRATIONSKONZEPT 7.4 Schnittstellen
Seite 138 von 163 Erstellt gemeinsam m it 15. April 1998
lem der Massenbetrieb zu Semesterbeginn abgewickelt wird (Immatrikulation, In skrip-tion, Rückmeldung, Anmeldungen) und diese Aktivitäten Auswirkungen auf das ganze Semester haben, wäre der einzige realistische Zeitpunkt der Umsetzung der Sommer 1999, sodaß zu Beginn der Inskriptionsfrist zum Wintersemester 1999/2000 die neuen Datenbankanwendungen bereitstehen müssen. Da der angesprochene Zeitdruck jedoch unweigerlich auch qualitative Probleme mit sich bringt, die nicht nur Unzufriedenheit, sondern auch Mehrkosten in derzeit nicht abschätzbarer Höhe verursachen können, kann diese Variante (sofortige Ablösung der BS2000-Systeme) unsererseits nicht emp-fohlen werden.
Bezüglich der Oracle-Anwendungen sind Jahr -2000-Einschränkungen nicht bekannt, al-lerdings sind hier noch entsprechende Garantien des Herstellers einzuholen.
7.4 Schnittstellen
Zwar sind die STEP-Anwendungen zu einem gemeinsamen Stichtag zu ersetzen, es kann jedoch davon ausgegangen werden, daß – um den dadurch entstehenden Zeit-druck abzuschwächen – die Umstellung der übrigen Anwendungen zu einem späteren Termin erfolgen kann.
Solange die derzeitigen WUFIS-Anwendungen jedoch nicht in das neue System integ-riert sind, sind entsprechende Schnittstellen vorzusehen. Als wichtigste Schnittstellen sind hier anzuführen:
7.4.1 Vorlesungsverzeichnis
Es empfiehlt sich, die Anwendungen zur Erstellung des Vorlesungsverzeichnisses und zu dessen Publikation zunächst in WUFIS beizubehalten. Für den Studienbetrieb im neuen 2gether-System ist lediglich die Kenntnis der angebotenen Lehrveranstaltungen notwendig.
Es ist somit eine Schnittstelle erforderlich, die entweder – analog zur heutigen WUFIS-STEP-Schnittstelle – die Daten der angebotenen Lehrveranstaltungen in 2gether ein-spielt oder einen Zugriff von 2gether aus auf die WUFIS -Datenbank erlaubt. In diesem Zusammenhang soll auf die Komplexität der Schnittstelle hingewiesen werden; nach Angaben der ADV war zur Implementierung der derzeit verwendeten Schnittstelle ein Programm mit ca. 9.000 Statements erforderlich.
Es ist des weiteren zu beachten, daß nicht nur alle Lehrveranstaltungen des betreffen-den Semesters überzuleiten sind, sondern auch alle jene aus früheren Semestern, zu denen noch Prüfungen abgehalten werden.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 139 von 163
7.4.2 Hörsaalbelegung
Die aktuelle Hörsaalbelegung hat ausschließlich Informationswert und beeinflußt nicht den Studienbetrieb im neuen 2gether -System. Auch diese Anwendung kann zu einem späteren Termin umgestellt werden.
Dennoch ist zu empfehlen, die Hörsaalbelegung generell zu Semesterbeginn und dann bei Bedarf in 2gether überzuleiten, um den Studierenden ein Maximum an Information unter einer einheitlichen Oberfläche anzubieten.
7.5 Übergangszeitraum
Wie in den vorstehenden Abschnitten ausgeführt, können es verschiedene Umstände zweckmäßig erscheinen lassen, bei der Einführung von 2gether nicht mit der vollen Funktionalität zu starten. Als mögliche Gründe hierfür können folgende angeführt wer-den:
• Reduzierung des Zeitdrucks;
• Möglichkeit zur Erstellung eines praktikablen Umstellungszeitplanes;
• Verteilung der Entwicklungskosten auf einen längeren Zeitraum, ohne bis zur Fertigstellung auf jeden Nutzen aus der Neuentwicklung verzic hten zu müssen.
Eine Verschiebung von Teilbereichen wirkt sich nicht nur im Hinblick auf den Zeitraum für die Softwareentwicklung aus, sondern auch im Hinblick auf Datenbestände, die nicht unmittelbar aus den alten Datenbanken übergeleitet werden können, sondern einer Nachbearbeitung oder Nacherfassung bedürfen. Ansatzpunkte in dieser Richtung sind in nachstehenden Punkten angeführt.
7.5.1 Historische Daten der Studenten
Für die Zulassung zu bestimmten Lehrveranstaltungen oder Prüfungen sind bestimmte Vorbedingungen zu erfüllen – das sind in der Regel absolvierte Prüfungen oder be-scheidmäßig festgestellte Anrechnungen. Ob eine lückenlose Übernahme dieser Daten aus der STEPDB nach 2gether möglich ist, kann erst nach endgültiger Festlegung der neuen Datenstruktur untersucht werden. Es ist jedoch schon zum jetzigen Zeitpunkt damit zu rechnen, daß sich diese Datenüberleitung als äußerst erweisen wird. Sollte sie überhaupt undurchführbar sein, würde die Notwendigkeit entstehen, ohne Prüfungshis-torie zu beginnen. Dazu muß der Studienabteilung jedoch eine einfache Möglichkeit ge-boten werden, für Studierende, die den Nachweis einer Voraussetzung benötigen, die-sen direkt am Schalter nachzuerfassen. Um manuelle Tätigkeiten dieser Art so gering
7 MIGRATIONSKONZEPT 7.6 Zeitlicher Ablauf
Seite 140 von 163 Erstellt gemeinsam m it 15. April 1998
wie möglich zu halten, ist danach zu trachten, einen möglichst hohen Anteil an Prü-fungshistorien und Anrechnungen automatisiert aus dem Altsystem zu übernehmen.
7.5.2 Selbstbedienungsfunktionen
Die vorgesehenen Selbstbedienungsfunktionen für die Studierenden führen zu einer um-fassenden Entlastung der angestellten Verwaltungskräfte. Aus Gründen der Ausfallssi-cherheit sollte dennoch die Möglichkeit beibehalten werden, an den Schaltern der Stu-dienabteilung die an sich für die Selbstbedienung vorgesehenen Tätigkeiten vorzuneh-men.
7.6 Zeitlicher Ablauf
Wird aus den genannten Gründen entschieden, das 2gether-Projekt stufenweise einz u-führen, so erscheint folgende Reihenfolge des Einsatzes der neuen Anwendungen zweckmäßig:
Stufe Gruppe Modul Funktionalität
1 2 3 4 5 6
Administration LV X
Aufnahme LV X
Planung LV X Lehrveranstaltun-gen
Anmerkung: durch Schnittstellen ist sicherzustellen, daß bereits in Stufe 1 die Inskription möglich ist.
Planung Prüfungstermin X Prüfungen
Leistungsfeststellung X
Studienpläne X
Zulassung Studium X X4
Zusatzstudium X
Studienwechsel
Rückmeldung Studium X
Studien
Beendigung Studium X X5
4 Eine allfällige Unterstützung des Aktenlaufes in solchen Fällen, wo Inskriptionsvoraussetzungen zu erfüllen sind, kann in einer späteren Phase erfolgen.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 141 von 163
Stufe Gruppe Modul Funktionalität
1 2 3 4 5 6
Themenvere inbarung X
Laufende Betreuung X
Beurteilung, soweit für Zeugnis erforderlich
X Diplomarbeiten und Dissertati onen Einreichung, Beurteilung
und Veröffentl ichung Volle Funktionalität X
Anerkennung vorbereiten X
Anerkennung durchführen X Anerkennungen
Bescheide ausfert igen X X6
Basisfunktionalität X Abrechnungen Abrechnung
Volle Funktionalität X
Arbeitsbericht Institut X Evaluierung
Beurteilung Lehrveranst. X
Lehrveranst. Anmeldung X
Prüfungsanmeldung X An- und Abmeldun-gen
Prüfungsabmeldung X
Hörsaaladministration X
Benutzeradministration X Allgemeine Module
Chipkartenverwaltung Unabhängig vom Zeit-
plan
Tabelle 10: Definition möglicher Umstellungsstufen
Die Zuordnung zur ersten Realisierungsstufe ergibt sich primär aus der Notwendigkeit, zum Zeitpunkt ihrer Implementierung die UDS-Datenbanken abzulösen, ergänzt um wei-tere Funktionalitäten, die zur Abrundung eines provisorisch verwendbaren Gesamtsys-tems erforderlich sind. Die Stufen 2 bis 6 können unabhängig voneinander implementiert und auch beliebig kombiniert werden.
Es wird empfohlen, die Migration in den nachfolgend angeführten Schritten abz uwickeln.
5 Eine allfäl lige Unterstützung von Nebensystemen wie Bibliothek, Leihgeräte etc. kann in einer späte-ren Phase erfolgen.
6 Eine allfällige Unterstützung des Aktenlaufes vor der eigentlichen Bescheiderstellung kann in einer späteren Phase erfolgen.
7 MIGRATIONSKONZEPT 7.6 Zeitlicher Ablauf
Seite 142 von 163 Erstellt gemeinsam m it 15. April 1998
7.6.1 Datenüberleitung
Das Datenmodell muß in jenen Teilen, die für die Realisierung in Phase 1 vorges ehen sind, bis auf Attributsebene herunter festgelegt sein. Die Beziehungen zwischen den Tabellen müssen feststehen und die vorgesehen Foreign Keys definiert sein. Es ist der Übernahmeweg der Daten insbesondere der Alt-Datenbanken STEPDB und INSTDB festzulegen, wobei für Datenarten, die nicht 1:1 überzuleiten sind, entspr echende Um-setztabellen zu definieren sind.
Wie auch die Erfahrungen mit dem Projekt STEP2000 zeigen, ist die Überleitung der Daten aus Codasyl-basierten Datenbank in relationale Datenbanken nicht immer prob-lemlos, vor allem wenn das Datenbankdesign auf das jeweilige Datenbanksystem ab-gestimmt ist – was schon allein aus Performance-Gründen fast immer der Fall ist. Es hat sich deshalb als günstig erwiesen, einen Zwischenschritt in Form einer UDS-Datenbank einzuführen, die im Aufbau bereits an die relationale Ziel-Datenbank ange-paßt ist.
Im Anschluß daran ist erstmalig eine Datenübernahme aus den Alt-Datenbanken STEPDB und INSTDB vorzunehmen. Bei Notwendigkeit sind die Umsetztabellen solan-ge zu ergänzen, bis eine vollständige fehlerlose Datenübernahme möglich ist.
Die endgültige Datenüberleitung erfolgt anläßlich der Aufnahme des Echtbetriebes.
In analoger Weise ist auch die Übernahme von Daten aus den WUFIS-Anwendungen vorzubereiten, nur mit der Besonderheit, daß diese Überleitungen als Schnittstellen auch noch während des Echtbetriebes der bereits implementierten 1. Stufe stattfinden müssen, weshalb festzulegen ist, welche Daten jedesmal überschrieben und welche fortgeschrieben werden.
7.6.2 Stammdatenerfassung
Daten, die nicht durch Überleitung aus den Altsystemen gewonnen werden können, a-ber für ein funktionierendes System wesentlich sind (in der Regel Stammdaten), sind manuell zu erstellen. Dies hat derart zweigleisig zu erfolgen, daß die für den Echtbetrieb notwendigen Daten von den reinen Testdaten separiert bleiben.
7.6.3 Phase 1
In Phase 1 sind die Funktionalitäten
• Benutzeradministration
• Stammdaten Studierende
• Studien (mit geringfügigen Abstrichen)
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 143 von 163
• Prüfungen
• An-/Abmeldungen
erforderlich.
Zu den Funktionalitäten
• Lehrveranstaltungen
• Studienwechsel
• Beurteilung der Diplomarbeiten/Dissertation
• Anerkennungsbescheid
• Abrechnung
• Hörsaaladministration
sind insoweit Basisfunktionalitäten vorzubereiten, daß das Gesamtsystem funktionsfä-hig ist.
7.6.4 Weitere Phasen
Die nachgelagerten Phasen 2 bis 6 können, was ihre Funktionalität betrifft, ohne Zeit-druck in Angriff genommen werden.
7.7 Zuordnungen alte/neue Datenbank
Die folgende Tabelle 11 zeigt eine grobe Zuordnung zwischen den alten Datenbanken STEPDB und INSTDB zu den neuen Objekten. Die zweibuchstabigen Codes der Spal-ten STEPDB und INSTDB entsprechen den Tabellennamen, gefolgt von der Anzahl der Einträge im März 1998.
Objektname StepDB InstDB Anmerkungen
Abgeltungsart PQ (6634) Kollegiengeld etc.
Abschlußarbeit Diplomarbeit etc.; Titel, Termine, Methoden, Kurz-fassung, Förderungsmöglichkeiten
Abschlußarbeitsbe-gutachtung
Beurteilung, Begründung
Adresse PE (2383) ST (92072)
7 MIGRATIONSKONZEPT 7.7 Zuordnungen alte/neue Datenbank
Seite 144 von 163 Erstellt gemeinsam m it 15. April 1998
Objektname StepDB InstDB Anmerkungen
Anerkennungsbe-scheid
BD (38325) BB (112821) BL (222)
Aktenzeichen, Datum, Inhalt, Anrechnungsver-merk
Anerkennungsge-genstand
AN (81284) Behörde, Datum, evtl. Note, Art, Semesterzahl
Anmeldung LM (1029897) LV oder Prüfung; Datum, Status, Num mer
Arbeitsbericht
Erhebungsbogen
Lehrauftragsrahmen Lehrauftragstyp, Versteuerungsart
Lehrveransta ltung LV (8718) LV (5720) Typ, Bezeichnung, Daten aus der Ankündigung
Lehrveranstaltungs-anmeldung
LS (689688) Anmeldungsreihenfolge
Lehrveranstaltungs-beurteilung
LP (36568) LT (103266)
Teilnahmefrequenz, Beurteilung
Lehrveranstaltungs-rahmen
Kontingente, Rahmenwerte
Lehrveranstaltungs-teilnahme
LS (689688) Ergebnisse
Lehrveranstaltungs-termin
MT (18674) Teilnehmerzahl
LV-Ankündigung IL (26556) AH (13) AR (74)
Nummer, Zeitraum, Bezeichnung, Typ, Wochen-stunden, Termine, letztes Semester, Lehrziele, Lehrinhalte, Sprache, Anforderungen, Literatur, Teilnehmerzahl
LV-Beteiligung v. Org.-Einh.
Funktion, Art der Beteiligung, Remunerat ion
LV-Beteiligung Mitar-beiter
ER (972) MI (49069) MS (33173) MB (20714)
MI (39223) MT (18674)
rechtl. Grundlage, Art der Beteiligung, Abrech-nungsdaten
Leistung PQ (6634) MQ (32585) MA (31815) LQ (23695)
QP (20244) Leistungsart (Prüfung, Begutachtung, ...)
Mitarbeiter PE (2383) PE (2135) Pers. Daten, Dienstverhältnis, Funktion, SV-Nr.
Nostrifizierung verl. Grad
Organisationseinheit IN (234) IN (80) Bezeichnung, Art, Typ, ..., Öffnungszeiten
Prüfung AB (2607) Bezeichnung, Art, Beschreibung, Code
Prüfungen des wiss. MA
TT (31143) TK (29615)
Anmeldezeitraum, Teilnehmerzahlen, Zute i-lungssystem
Prüfung des Studen- BS (488439) Beurteilung, Status, Einsichtsfrist
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 145 von 163
Objektname StepDB InstDB Anmerkungen ten PR (325313)
ET (3263)
Prüfungstermin TE (1609) Position
Raum Größe, Ausstattung
Reservierung Belegungszeit, Status
Rückmeldung SI (746161) Datum, Typ, Bemerkung
Semester Anfang, Ende, Bezeichnung, 1. Und letzte U nter-richtswoche, lehrveranstaltungsfreie Zeiten, Fris-ten, Termine
Studium Typ, Gesamtstundenzahl
Studium des Studen-ten
BS (488439) Anfangs - und Enddatum, Status, Erfüllungssta-tus, Abgabestatus
Student ST (92072) SH (127163)
Name, Matrikelnummer, Zahlweise, Gebühren-status, absolvierte Schule, Stammhochschule, Rückgabestatus, Salden
Studentenausweis Status, Gültigkeitszeitraum, Kontonummer WU
Studienplan PL (36) Bezeichnung, Inkrafttreten, Ablaufdatum, Versi-onsnummer, zu verleihender Titel
Studienabschnitt eines Studiums
Anzahl Semester, Nachlaßsemester, Stunden-zahl
Studium der Zulas-sung
lfd. Nr., Status
Studiumsänderung Wechsel, Aufnahme, Beendigung
Studienplanpunkt BP (7129) Bezeichnung, Typ, Stundenausmaß
Termin des wiss. MA Anmeldekapazität
Terminliste TE (1609) Art der Termine, Gültigkeitszeitraum
Wartelistenposition LS (689688)
Zuteilung Belegungszeit
Zulassung zum Stu-dium
Datum, Termine, Anmeldenummer, Status, Kennwort, Bemerkung
Tabelle 11: Zuordnung der neuen Objekte
Die nachstehende Abbildung 62 gibt die Zusammenhänge innerhalb der STEPDB wie-der. Die Pfeile sind grundsätzlich vom Owner in Richtung Member gezeichnet, stric h-lierte Pfeile sind Beziehungen, die nicht durch Sets, sondern mittels Foreign Keys reali-siert sind (in der Regel die Matrikelnummer). Die dunkel hinterlegten Recordarten ent-halten keine Daten.
7 MIGRATIONSKONZEPT 7.7 Zuordnungen alte/neue Datenbank
Seite 146 von 163 Erstellt gemeinsam m it 15. April 1998
Abbildung 62: Struktur der Datenbank STEPDB
HSHochschule
FAFakultät
FPStudienplan an Fakultät
INInstitut,
Abteilung, Fachgruppe
SOSonder-
FunktionenIO
Instituts- Organisation
PEPersonal
PQPersonalinfo quästurrelev.
ABAbhaltung
Prüfung
BDBescheide zur
Anrechnung
ERErlaubnis zum
Prüfen
LSLehrv.
Inskription und Note
M BMitwirkung
LV Beantragung
MIMitwirkung
LV
PRMitwirkung
als Prüfer
TKTermin mit
Kandidaten- Aufteilung
TTTermin
temporär
ASAnmeldung
des Studenten
BSErfüllte
Beding. des Studenten
BBBedingungen pro Bescheid
BLLehrv. pro Bescheid
M QMitwirkung
Abrech.daten
MSMitwirkungStunden -
Ausmaß
ETTemporäre Prüfungs- Ergebnisse
M AMitwirkung
Abrech.Daten
BEBedingungen
in Studien
KOPrüfungs-
Komm.
TETermine
Prüfungen
PLStudienplan
ANAnrechenbar.
LV
BPBedingungenStudienplan-
Punkt
LVLehrveranst.
BOOveflow BP
LFLehrveranstalt
Fachbereich Semester
LQLehrveranst.
quästurrel.
NUNummen-
Verwaltung
SHStudent an
HS
SISemesterinfo
STStudent
TXTexte
TX
SI,ST,SH,BS
TX
HS,FA,PL,IN
SO
SO
SO
TX
TX
SO
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 147 von 163
Es folgt eine analoge Graphik über die INSTDB (Abbildung 63). Auch hier enthalten die dunkel hinterlegten Recordarten entweder gar keine Daten oder nur ganz wenige (AB enthält 8 Records). PA enthält zwar 2183 Records, wird seitens des ZID als überholt bezeichnet, demnach ist PA nur mehr aus historischen Gründen in der Datenbank ent-halten.
7 MIGRATIONSKONZEPT 7.7 Zuordnungen alte/neue Datenbank
Seite 148 von 163 Erstellt gemeinsam m it 15. April 1998
Abbildung 63: Struktur der Datenbank INSTDB
A BLehrveranst. Beschreib.
ARLehrveranst. Beschr. Rumpf
ILLehrveranst. eines Instituts
LMLehrveranst. Anmeldungen
LNLerveranst. Nummernn Hilfsrecord
LPLehrveranst. Ergebnis Prot.
LQsemesterspez. LV-Daten für Q
LTLehrversnst.
Test, Zwisch.Erg.
LVLerveranst.
MIMitwirkung
bei LV
MTMitwirkung
Termine
NKNummernkreis
LV-Anmeld.
PAPersonal Abstract
PEPersonal
PLProfil
Lehrveranst.
QPVerbindung LP
mit PE für Quäst.
SHStudent-
Hochschule
SIStudent- Inskript.
STStudent
THThemen von Lehrveranst.
VRVorlesungsvz.
Reihung
VTVorlesungsvz.
Themen
INInstitut
AHAbstact Header
5 x
2 x
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 149 von 163
8 WIRTSCHAFTLICHKEITSBETRACHTUNG
Wirtschaftlichkeitsbetrachtungen werden üblicherweise dann angestellt, wenn es zu entscheiden gilt, ob ein bestehendes System durch ein neues ersetzt werden soll, oder auch dann, wenn eine Entscheidung zwischen mehreren Varianten getroffen werden muß.
Das Anstellen von Wirtschaftlichkeitsbetrachtungen ist dann problematisch, wenn es zur Ablöse eines Altsystems keine wirkliche Alternative gibt, wenn das Altsystem also aus zwingenden Gründen auf alle Fälle abgelöst werden muß, wie dies im Falle des STEP-Systems an der WU-Wien gegeben ist. Folgende Gründe, die eine rasche Ablö-sung des STEP-Systems unausweichlich machen, sind hier anzuführen:
• Das System hat das Ende seines Lebenszyklus erreicht.
• Es ist zu erwarten, daß das Betriebssystem BS2000 in absehbarer Zeit vom Hersteller nicht mehr unterstützt wird.
• Die angewendeten informationstechnologischen Methoden sind überholt und nicht mehr wirtschaftlich; sie lassen wenig bis gar keinen Spielraum für die Integration neuer, moderner IT-Verfahren.
8.1 Anmerkungen zum Nutzen des neuen Systems
Die Ermittlung des durch die Einführung des neuen Systems „2gether“ zu erzielenden Nutzens erfordert die Differenzierung nach zwei wesentlichen Aspekten:
• Zum einen besteht ein quantitativer Nutzen, der es den WU-Mitarbeitern ermöglicht, dieselbe bisherige Tätigkeit in kürzerer Zeit zu erledigen, um so die gewonnene Zeit in höherwertige Tätigkeiten zu investieren (Effizienz), bzw. in derselben Zeiteinheit ein höheres Arbeitspensum zu leisten (Effek-tivität). Als Beispiele zur Effizienz seien insbesondere die administrative Entlastung des Mittelbaus an den Instituten zugunsten einer mehr inhaltlich gewichteten Arbeit oder beispielsweise die Entlastung der STAB-Mitarbeiter von Prüfroutinen zugunsten der ausgiebigeren Beratung von Studierenden genannt.
• Zum anderen ein qualitativer Nutzen, der sich beispielsweise aus der Ver-einfachung von Arbeitsabläufen und insbesondere auch aus dem Wegfall
8 WIRTSCHAFTLICHKEITSBETRACHTUNG 8.1 Anmerkungen zum Nutzen des neuen Systems
Seite 150 von 163 Erstellt gemeinsam m it 15. April 1998
monotoner Tätigkeiten ergibt und eine höhere Motivation und einen höheren Einsatz der Mitarbeiter zu Folge hat.
Schematisch lassen sich die Bewertungsmöglichkeiten des zu erzielenden Nutzens ei-nes neuen Systems wie folgt darstellen:
Verbesserungspotential
quantitativ bewertbar qualitativ bewertbar
Effizienz (ca. 50%):
Die Arbeitsleistung je Zeiteinheitwird erhöht.
Effektivität (ca. 50%):
Die eingesparte Zeit wird fürhöherwertige Tätigkeitenverwendet
Kriterien:
• Ergonomie
• Motivation
• Servicegrad
• ...
Abbildung 64: Bewertbarkeit des Verbesserungspotentials
Es ist darauf hinzuweisen, daß im vorliegenden Projekt lediglich die Steigerung der Effi-zienz bewertet werden konnte. Die damit verbundene Steigerung der Effektivität wird in der Literatur in der gleichen Höhe wie die eigentlich erzielten Einsparungen angesetzt.
8.1.1 Qualitative Verbesserungen
Die mit der Einführung des neuen Systems „2gether“ in Verbindung stehende qualitative Verbesserung läßt sich in erster Linie aus den allgemeinen Zielen des Projektes herlei-ten. Hierbei seien besonders erwähnt:
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 151 von 163
• Eine integrierte, redundanzfreie Datenbasis Dieses Ziel verkörpert die Grundlage aller weiteren Punkte. Unmittelbar be-wirkt es eine höhere Fehlersicherheit bei der Bearbeitung.
• Ein einheitliches, homogenes DV-System Hier entfällt das mühsame Umschalten zwischen verschiedenen Anwen-dungen, was nicht zuletzt eine größere Vertrautheit mit den Funktionalitäten des Systems bewirken wird.
• Optimale Auswertungsmöglichkeiten Durch die wegfallenden Medienbrüche und Insellösungen ist es möglich, WU-weite Auswertungen zu fahren, was insbesondere für das angestrebte Universitätscontrolling (Stichwort „Evaluierung“) von großer Bedeutung ist.
• Keine Mehrfachdatenerfassung Ein Grundsatz des neuen Systems ist es, Daten dort zu erfassen, wo sie anfallen. Dies beschleunigt die Dateneingabe und bewirkt zudem eine bes-sere Qualität der Daten. (Das „Stille-Post-Prinzip“ fällt weg.)
• Ein erhöhter Informationsfluß Für die Institute, aber auch insbesondere für die Studenten, stehen Informa-tionen erheblich zeitnaher zur Verfügung. Als Beispiel seien hier nur die No-tenauskunft für Prüfungsnoten oder die zeitnahe Einsicht in aktuelle Pla-nungsstände des Vorlesungsverzeic hnisses genannt.
Diese qualitativen Verbesserungen können somit auch zu kürzeren Studienzeiten füh-ren. Im genannten Beispiel der Prüfungsnoten können beispielsweise die nur befristet gültigen Interimszeugnisse wegfallen und somit unter Umständen Anmeldefristen über-haupt erst eingehalten werden.
Die im Zusammenhang der Prozeßbeschreibung angeführte Argumenten- oder Nutzen-bilanz stellt desweiteren eine detaillierte Auflistung auch qualitativ zu verstehender Ver-besserungen dar. An dieser Stelle soll jedoch nicht weiter explizit hierauf eingegangen werden (vgl. Abschnitt Organisatorische Gestaltung der Studien- und Prüfungsverwal-tung).
8.1.2 Quantitativ meßbare Verbesserungen
Die exakte Herleitung des quantitativen Nutzens – der Verringerung des benötigten Ar-beitsaufwandes zur Durchführung geringer bewerteter Tätigkeiten ausgedrückt in Per-sonenarbeitsleistungen (PAL)7 – ist nicht unproblematisch. Dies gilt insbesondere vor
7 Als Personenarbeitsleistung soll hier die Gesamtheit an Leistungen bezeichnet werden, die von einer fulltime beschäftigten Person erbracht wird (= Arbeitsleistung einer Person). Diese Bezeichnung wur-
8 WIRTSCHAFTLICHKEITSBETRACHTUNG 8.1 Anmerkungen zum Nutzen des neuen Systems
Seite 152 von 163 Erstellt gemeinsam m it 15. April 1998
dem Hintergrund des Projektes, eine Ausschreibungsgrundlage zu erstellen. Dadurch muß eine Abschätzung in diesem Rahmen zwangsläufig von einer optimalen Umset-zung der in diesem Fachkonzept beschriebenen Anforderungen, bei denen es sich ja auch um Maximalanforderungen handelt, an das System aus gehen.
Um eine fundiertere Basis für unsere Abschätzungen zu erhalten, wurden die Organisa-tionseinheiten des Untersuchungsbereichs gebeten, Erhebungsbögen zum Mengen- und Wertegerüst auszufüllen, die auch eine (subjektive) Einschätzung der zu erwar -tenden Verbesserungen in Form von Zeitersparnis beinhaltet haben. Der Rücklauf die-ser Bögen betrug beispielsweise aus den Instituten 50%, wobei zudem der Aussagege-halt sehr heterogen war. Diese Umstände führen dazu, daß sich aus den Ergebnissen der Befragung keine einwandfrei gesicherten Aussagen herleiten lassen.
Nichtsdestotrotz dienen die Ergebnisse in jedem Fall dazu, fundierte Trendaussagen tätigen zu können. Diese münden letztlich auch in einer Anzahl von Personenarbeits-leistungen, die umgeschichtet und in Zukunft effizienter und höherwertiger eingesetzt werden kann.
Die Untersuchung wurde im wesentlichen in zwei getrennten Bereichen mit eigenen, zugeschnittenen Erhebungsbögen durchgeführt. Dies sind zum einen die Verwaltungs-bereiche, bestehend aus der Studien- und Prüfungsabteilung (STAB), der Quästur und der Rechts- und Organisationsabteilung (RO) sowie des Zentrums für Auslandsstudien (ZAS) und des Studiendekanats. Hierbei ergibt sich ein Nutzenpotential in der Größen-ordnung von Personenarbeitsleistungen nur in der STAB, so daß die Quästur, die RO, das ZAS und das Studiendekanat im folgenden nicht eingehender betrachtet werden. Dies bedeutet nicht, daß nicht auch in diesen Bereichen punktuelle, qualitative Verbes-serungen zu erwarten sind (vgl. Argumentenbilanz, Abschnitt Organisatorische Gestal-tung der Studien- und Prüfungsverwaltung).
Zum anderen wurden die zehn Institute und Abteilungen des (erweiterten) Untersu-chungsbereichs um das spezifische Mengen- und Wertegerüst einschließlich einer Stellungnahme gebeten.
8.1.2.1 Studien- und Prüfungsabteilung
Zusammenfassend ergibt sich für die Studien- und Prüfungsabteilung ein Potential von
11 - 15 PAL8.
de deshalb gewählt, weil der erzielbare Nutzen in einer Verringerung der benötigten Arbeitsleistung liegt, nicht jedoch in der Verringerung der Mitarbeiteranzahl.
8 Personenarbeitsleistung = Arbeitsleistung einer Person.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 153 von 163
Dabei geht der maximale Wert vom Idealfall der optimalen Umsetzung der Anforderun-gen aus und beinhaltet zudem 1 PAL aus der BW-Servicestelle.
Die folgende Abbildung 65 gibt einen Eindruck, wie sich das Nutzenpotential qualitativ auf die einzelnen Prozeßbereiche verteilen.
0,00
200,00
400,00
600,00
800,00
1000,00
1200,00
1400,00
1600,00
[PT]
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
Prozeßbereich
Maximales Nutzenpotential der STAB
Abbildung 65: Qualitative Verteilung des Nutzenpotentials in der STAB
Die Nummern auf der horizontalen Achse stehen stellvertretend für die ermittelten Pro-zesse. Eine Zuordnung wird in Tabelle 12 vorgenommen.
Lfd. Nr. Prozeßbereich
1. Erstellung/ Wartung Studienplan
2. Planung Studienjahreinteilung
3. Zulassung
4. Rückmeldung Studium
5. Wechsel Studium/ Aufnahme Zusatzstudium
6. Beendigung Studium
8 WIRTSCHAFTLICHKEITSBETRACHTUNG 8.1 Anmerkungen zum Nutzen des neuen Systems
Seite 154 von 163 Erstellt gemeinsam m it 15. April 1998
Lfd. Nr. Prozeßbereich
7. Verleihung akadem. Grad/akadem. Feier
8. Planung Prüfungstermin
9. Leistungsfeststellung
10. Notenabfrage
11. Diplomarbeiten
12. Dissertationen
13. LV-Anmeldungen
14. Prüfungsanmeldungen
15. Abmeldungen
16. Vormerkungen / Warteliste
17. Anmeldeauskunft
18. Anerkennungen
19. Nostrifizierung
Tabelle 12: Numerierung der Prozeßbereiche (Verwaltung)
Die Grafik bestätigt die Bereiche, in denen sich das größte Potential erwarten läßt. Dies sind die Bereiche
• Zulassung und Rückmeldung von Studierenden,
• Leistungsfeststellungen,
• Anerkennungen (insbesondere WU-intern),
• Abschlußarbeiten sowie insbesondere
• Prüfungsanmeldungen.
Diese Bereiche verfügen über das höchste Automatisierungspotential.
8.1.2.2 Institute/Abteilungen
Analog erfolgt die Bewertung des Nutzenpotentials bei den Instituten. Hier ist jedoch eine „Hochrechnung“ der Daten aus der Befragung auf die gesamte WU erforderlich.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 155 von 163
Diese Hochrechnung geschieht nach folgendem Prinzip:
Normierung der einzelnen Werte mit Bezug auf eine spezifische Basisgröße.
Bildung des arithmetischen Mittels der normierten Werte.
Hochrechnung dieser Mittelwerte anhand der entsprechenden WU-weiten Kennzahlen auf die gesamte WU.
Beim ersten Schritt wurden dabei folgende Basisgrößen verwendet:
Bezugsgröße Prozeßbereich
#9 Lehrveranstaltungen Planung Lehrveranstaltung (inkl. VVZ)
# Lehrveranstaltungen Aufnahme Lehrveranstaltung
# LV-Anmeldungen Administration Lehrveranstaltung
# Prüfungsanmeldungen10 Planung Prüfungstermin
# Prüfungsanmeldungen Leistungsfeststellung
# Prüfungsanmeldungen Notenabfrage
# Abschlußarbeiten Themenvereinbarung
# Abschlußarbeiten Laufende Betreuung
# Abschlußarbeiten Einreichung, Beurteilung & Veröffentlichung
# LV-Anmeldungen LV-Anmeldungen
# Prüfungsanmeldungen Prüfungsanmeldungen
# LV-Anmeldungen Abmeldungen
# LV-Anmeldungen Vormerkungen / Warteliste
# LV-Anmeldungen Anmeldeauskunft
# Lehrveranstaltungen (Anträge zur) Hörsaaladministration
9 „#“ := Anzahl
10 Logisch korrekter wäre hier die Anzahl der Prüfungen. Diese ist zum einen sehr schwer definierbar und auch nicht bekannt gewesen. Da nicht unrealistisch ist, daß die Anzahl der Prüfungsanmeldun-gen in etwa mit der Anzahl der Prüfungen korreliert, wurde auf diese zurückgegriffen.
8 WIRTSCHAFTLICHKEITSBETRACHTUNG 8.1 Anmerkungen zum Nutzen des neuen Systems
Seite 156 von 163 Erstellt gemeinsam m it 15. April 1998
Bezugsgröße Prozeßbereich
# Lehrveranstaltungen Beurteilung Lehrveranstaltung
1 Arbeitsbericht Institutsvorstände
Tabelle 13: Bezugsgrößen der Prozeßbereiche
Somit ergibt sich die folgende Formel zur Berechnung des Nutzeffekts:
PT
x
bn
bj
ij
iji
n
j:= •=∑ 1
Dabei ist
PTj := (WU-weiter) Nutzen des Prozeßbereichs j in Personentagen
n := Anzahl der befragten Institute/Abteilungen
bij := Wert der Bezugsgröße des Prozeßbereichs j für das Institut i
xij := Nutzenpotential des Instituts i im Prozeßbereich j
b j := WU-weiter Wert der Bezugsgröße des Prozeßbereichs j
Als Ergebnis läßt sich feststellen, daß sich eine WU-weite Effizienzsteigerung im Ge-genwert von
ca. 20 - 23 PAL11
erwarten läßt, allerdings ohne daß einzelne Stellen als solche unmittelbar freigesetzt werden können.
Betonenswert an diesem Ergebnis ist wohl in erste Linie die Tatsache, daß auch von den Instituten selber unter dem Strich keine Mehrbelastung erwartet wird. Die in den Instituten durchgeführten reinen Verwaltungstätigkeiten im Umfeld der Studien- und Prü-
11 Personenarbeitsleistung = Arbeitsleistung einer Person.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 157 von 163
fungsverwaltung können somit merklich reduziert und als zusätzliche Potentiale zur Un-terstützung der Kernaktivitäten in Forschung und Lehre genutzt werden.
In der folgenden Abbildung 66 wird – analog zur Studien- und Prüfungsabteilung – die qualitative Verteilung des Nutzens aufgezeigt.
0,00
200,00
400,00
600,00
800,00
1000,00
1200,00
1400,00
1600,00
1800,00
[PT]
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Prozeßbereich
WU-weites mittleres Nutzenpotential der Institute
Abbildung 66: Qualitative Verteilung des Nutzenpotentials in den Instituten
Hierbei ist anzumerken, daß – nach unserer Auffassung – tatsächlich ein größeres Nut-zenpotential realistisch ist. Dies ist insbesondere damit begründet, daß teilweise von einzelnen Instituten keine Aussage hinsichtlich des Potentials getroffen wurde, obwohl eine Erleichterung der administrativen Arbeit offensichtlich ist – es handelt sich also um eine eher konservative Einschätzung.
Die Legende zur Numerierung der Prozeßbereiche können der folgenden Tabelle 14 entnommen werden.
8 WIRTSCHAFTLICHKEITSBETRACHTUNG 8.1 Anmerkungen zum Nutzen des neuen Systems
Seite 158 von 163 Erstellt gemeinsam m it 15. April 1998
Lfd. Nr. Prozeß
1. Planung Lehrveranstaltung (inkl. VVZ)
2. Aufnahme Lehrveranstaltung
3. Administration Lehrveranstaltung
4. Planung Prüfungstermin
5. Leistungsfeststellung
6. Notenabfrage
7. Abschlußarbeiten (Dipl.+Diss.), Summe
8. Themenvereinbarung (Dipl.+Diss.)
9. Laufende Betreuung (Dipl.+Diss.)
10. Einreichung, Beurteilung & Veröffentlichung (Dipl.+Diss.)
11. LV-Anmeldungen
12. Prüfungsanmeldungen
13. Abmeldungen
14. Vormerkungen / Warteliste
15. Anmeldeauskunft
16. (Anträge zur)Hörsaaladministration
17. Beurteilung Lehrveranstaltung
18. Arbeitsbericht Institutsvorstände
Tabelle 14: Numerierung der Prozeßbereiche (Institute)
Zum Bereich der „LV-Anmeldungen“ ist noch zu vermerken, daß bereits heute die An-meldung mittels System erfolgen kann – aber offensichtlich nicht umfassend eingesetzt wird. Dieses Beispiel macht ein generelles Problem an der WU Wien deutlich: Die weit verbreitete Freistellung der Nutzung von DV-Unterstützung sowohl durch WU-Mitarbeiter selbst als auch durch die Studierenden bewirkt, daß in vielen Bereichen Parallelabläufe existieren, die direkt zu Mehraufwendungen führen. Soll das avisierte Nutzenpotential auch wirklich umgesetzt werden, ist ein Umdenken – ggf. erreichbar nur durch striktere organisatorische Vorgaben bzw. bessere und intensivere Schulungen – erforderlich: In Zukunft müssen sich beispielsweise die Studierenden über das System anmelden, an-dernfalls können sie nicht an der Lehrveranstaltung teilnehmen.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 159 von 163
8.2 Kosten-/Nutzenrechnung
Da die Anwendung des Hedonistischen Modells auf die Quantifizierung der Einsparun-gen nicht möglich war12, wurde teils auf die Ergebnisse der Fragebogenaktion, teils auf eigene Schätzungen der zu erwartenden Verringerung des Verwaltungsaufwandes zu-rückgegriffen (zur Qualität der getroffenen Annahmen siehe Kapitel 8.1.2 ). Wie anläß-lich der 3. Sitzung des Lenkungsausschusses vorgegeben, wurde davon ausgegangen, daß die eingesparten Zeiten nicht für Tätigkeiten verwendet werden, deren Wert gerin-ger als die eingesparten Tätigkeiten einzustufen ist. Die Steigerung der Effektivität, die üblicherweise gleich hoch wie der Effizienzgewinn eingestuft wird (siehe dazu auch Sei-te 150, Abbildung 64), bleibt jedoch aus kaufmännischer Vorsicht bei der Quantifizierung des Verbesserungspotentials unberücksichtigt.
Als Basis für die Aufwandsschätzungen wurde auf die bereits vom ZID erhobenen Wer-te zurückgegriffen. Die vom ZID erstellte Kostenschätzung, deren Ansätze uns als durchaus plausibel erscheinen, ist in Anhang F beigefügt. Es wurden folgende Adaptie-rungen vorgenommen (siehe Tabelle 15 auf Seite 162):
• Es wurden die vom ZID angesetzten Eigenleistungen kostenmäßig bewertet und in die Kalkulation aufgenommen.
• Die Kosten für einen internen Mitarbeiter der erforderlichen Qualifikation wurden mit 600.000 öS p.a. inklusive Dienstgeberanteil angenommen (Ba-sis: ZID Gehaltskostenanteil 1997).
• Die bislang unberücksichtigt gebliebenen notwendigen laufenden Adaptie-rungsarbeiten am Neusystem 2gether wurden aufwandsmäßig in die Kalku-lation aufgenommen (1 Mitarbeiter fulltime).
12 Da seitens des Lenkungsausschusses (3. Sitzung am 5. März 1998) massiver Widerstand bei der Erhebung der benötigten Daten erwartet wurde, wurde beschlossen, das Ausmaß der zu erzielenden Einsparungen beim Verwaltungsaufwand mittels Fragebogen bei den bereits im Projekt involvierten Organisationseinheiten zu erheben.
8 WIRTSCHAFTLICHKEITSBETRACHTUNG 8.2 Kosten-/Nutzenrechnung
Seite 160 von 163 Erstellt gemeinsam m it 15. April 1998
• Die Entwicklungszeit für die Realisierung des „2gether“-Projektes wurde mit drei Jahren angenommen (siehe dazu das in Kapitel 7 ausgeführte Migrati-onskonzept).
• Der Durchrechnungszeitraum wurde auf 10 Jahre reduziert.
Gegenüberstellung der Kosten STEP vs. 2gether (alle Werte in Mio. öS inkl. USt.)
Erhaltung des derzeitigen Systems STEP 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 Total
Hardware, Systemsoftware (inkl. Wartung) 10,8 0,9 0,9 0,9 11,5 0,9 0,9 0,9 13,2 1,0 41,9
Anwendungs-SW (notwendige Adaptierungen) 2,6 4,4 4,5 1,9 2,0 2,0 2,1 2,1 2,2 2,2 26,0
� Kosten STEP pro Jahr 13,4 5,3 5,4 2,8 13,5 2,9 3,0 3,0 15,4 3,2 67,9
� Kosten STEP kumuliert 13,4 18,7 24,1 26,9 40,4 43,3 46,3 49,3 64,7 67,9
Neuentwicklung 2gether 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
Hardware, System-SW (inkl. Wartung) 10,4 0,4 0,4 0,4 10,5 0,4 0,4 0,4 10,9 0,4 34,6
Anwendungs-SW (Entwicklung) 19,2 19,2 19,2 0,0 0,0 0,0 0,0 0,0 0,0 0,0 57,6
Eigenleistung (Entw. + lfd. Adaptierung) 1,2 1,2 1,2 0,6 0,6 0,7 0,7 0,7 0,7 0,7 8,3
Schulung pro (Jahr) 1,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 3,0
� Kosten 2gether pro Jahr 32,0 21,0 21,0 1,2 11,3 1,3 1,3 1,3 11,8 1,3 103,5
Kosten 2gether kumuliert 32,0 53,0 74,0 75,2 86,5 87,8 89,1 90,4 102,2 103,5
Quantifizierbare Einsparungen durch 2gether 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
Werkverträge (Erfassungsarbeiten STAB) 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 2,0
Material (Formulare) 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 2,0
Porto 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 5,0
Reduktion Verwaltungsstellen -9,0 -13,0 -34,0 -34,0 -34,0 -34,0 -34,0 -34,0
Reduktion Personalkosten 3,8 5,6 15,0 15,4 15,8 16,2 16,6 17,0 105,4
� Einsparungen 2gether pro Jahr 0,9 0,9 4,7 6,5 15,9 16,3 16,7 17,1 17,5 17,9 114,4
Einsparungen 2gether kumuliert 0,9 1,8 6,5 13,0 28,9 45,2 61,9 79,0 96,5 114,4
Berichtigte Kosten 2gether 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008
Aufwand abzügl. Einsparungen (�–�) 31,1 20,1 16,3 -5,3 -4,6 -15,0 -15,4 -15,8 -5,7 -16,6 -10,9
� Berichtigte Kosten kumuliert 31,1 51,2 67,5 62,2 57,6 42,6 27,2 11,4 5,7 -10,9
Aufwendungen Altsystem im Vergleich zu 2gether (�/�∗100)
43% 37% 36% 43% 70% 102% 170% 432% 1135% –
8.2 Kosten-/Nutzenrechnung
Seite 162 von 163 Erstellt gemeinsam m it 15. April 1998
Tabelle 15: Gegenüberstellung der geschätzten Kosten
Aus der vorstehenden Kostenübersicht kann folgendes abgeleitet werden:
• Die vergleichbaren Gesamtkosten sind nach 6 Jahren ausgeglichen (Break Even im Jahre 2004).
• Am Ende des Durchrechnungszeitraumes betragen die von 2gether erwirk-ten Gesamteinsparungen 78,8 Mio. öS.
• In den Zahlen sind weder der qualitative Nutzen noch die zu erwartende Steigerung der Effektivität berücksichtigt.
• Die Vornahme einer dynamischen Investitionsrechnung, wobei wir uns der in der betrieblichen Praxis häufig verwendeten Internen-Zinsfuß-Methode bedienten, ergibt einen internen Zinsfuß von 12%.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 8
ABBILDUNGSVERZEICHNIS
Abbildung 1: Ist-Situation und Ziele des Projektes „2gether“
Abbildung 2: Aspekte der Studien- und Prüfungsverwaltung in „2gether“
Abbildung 3: Partner im Projekt „2gether“
Abbildung 4: Projektaufbauorganisation
Abbildung 5: Phasen des Projektes ‘2gether’
Abbildung 6: Die Instanzen eines Universitätsprozesses
Abbildung 7: Werkzeuggestütztes Vorgehen im Projekt ‘2gether’
Abbildung 8: Das ARIS -Haus im Gesamtüberblick
Abbildung 9: Ebenenkonzept des ARIS
Abbildung 10: Beispiel eines Organigramms (Ausschnitt)
Abbildung 11: Beispiel eines Funktionsbaums
Abbildung 12: Beispiel Entity-Relationship-Modell
Abbildung 13: Beispiel einer Ereignisgesteuerten Prozeßkette (Ausschnitt)
Abbildung 14: Legende der verwendeten Objekttypen
Abbildung 15: Bestandteile der Methodik
Abbildung 16: WU Wien Aufbauorganisation nach UOG 93, Überblick
Abbildung 17: Funktionsbaum „Studien- und Prüfungsverwaltung“
Abbildung 18: PAM „Studium“
Abbildung 19: Funktionszuordnungsdiagramm „Zulassung Studium“
Abbildung 20: Funktionszuordnungsdiagramm „Rückmeldung Studium“
Abbildung 21: Funktionszuordnungsdiagramm „Wechsel Studium/Aufnahme Zusatzstudium“
Abbildung 22: Funktionszuordnungsdiagramm „Beendigung Studium“
Abbildung 23: Funktionszuordnungsdiagramm „Erstellung Diplomzeugnis“
Abbildung 24: Funktionsbaum „Lehrveranstaltung“
Abbildung 25: Funktionszuordnungsdiagramm „Planung Lehrveranstaltung“
Abbildung 26: Funktionszuordnungsdiagramm „Aufnahme Lehrveranstaltung“
Anhang A Verzeichnisse
Seite 2 von 8 Erstellt gemeinsam m it 15. April 1998
Abbildung 27: Funktionszuordnungsdiagramm „Administration Lehrveranstaltung“
Abbildung 28: Funktionsbaum „Prüfung“
Abbildung 29: Funktionszuordnungsdiagramm „Planung Prüfungstermin“
Abbildung 30: Funktionszuordnungsdiagramm „Leistungsfeststellung“
Abbildung 31: Funktionsbaum „Diplomarbeit/Dissertation“
Abbildung 32: Funktionszuordnungsdiagramm „Themenvereinbarung“
Abbildung 33: Funktionszuordnungsdiagramm „Laufende Betreuung“
Abbildung 34: Funktionszuordnungsdiagramm „Einreichung, Beurteilung und Veröffentlichung“
Abbildung 35: PAM „An- und Abmeldung“
Abbildung 36: Funktionszuordnungsdiagramm „Lehrveranstaltungsanmeldung durchführen“
Abbildung 37: Funktionszuordnungsdiagramm „Prüfungsanmeldung durchführen“
Abbildung 38: Funktionszuordnungsdiagramm „Abmeldung durchführen“
Abbildung 39: Funktionsbaum „Anerkennung“
Abbildung 40: Funktionszuordnungsdiagramm „Erzielen von Anerkennungen“
Abbildung 41: Funktionszuordnungsdiagramm „Erzielen von Nostrifikationen“
Abbildung 42: Funktionszuordnungsdiagramm „Abrechnung“
Abbildung 43: PAM „Evaluierung der Lehre“
Abbildung 44: Funktionszuordnungsdiagramm „Beurteilung Lehrveranstaltung“
Abbildung 45: Funktionszuordnungsdiagramm „Arbeitsbericht Institutsvorstände“
Abbildung 46: Funktionsbaum „allgemeine Funktionen“
Abbildung 47: Funktionszuordnungsdiagramm „Hörsaaladministration“
Abbildung 48: Funktionsbaum „allgemeine Systemfunktionen“
Abbildung 49: Clustersammlung zur Studien- und Prüfungsverwaltung
Abbildung 50: Semantisches Datenmodell ‘Studium’
Abbildung 51: Semantisches Datenmodell ‘Studienplan’
Abbildung 52: Semantisches Datenmodell ‘Lehrveranstaltung’
Abbildung 53: Semantisches Datenmodell ‘Vorlesungsverzeichnis’
Abbildung 54: Semantisches Datenmodell ‘Prüfungen’
Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’
Abbildung 56: Semantisches Datenmodell ‘Abschlußarbeiten’
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 8
Abbildung 57: Semantisches Datenmodell ‘Anerkennung’
Abbildung 58: Semantisches Datenmodell ‘Abrechnung’
Abbildung 59: Semantisches Datenmodell ‘Hörsaalverwaltung’
Abbildung 60: Semantisches Datenmodell ‘Evaluierung’
Abbildung 61: Semantisches Datenmodell ‘Adresse’
Abbildung 62: Struktur der Datenbank STEPDB
Abbildung 63: Struktur der Datenbank INSTDB
Abbildung 64: Bewertbarkeit des Verbesserungspotentials
Abbildung 65: Qualitative Verteilung des Nutzenpotentials in der STAB
Abbildung 66: Qualitative Verteilung des Nutzenpotentials in den Instituten
Anhang A Verzeichnisse
Seite 4 von 8 Erstellt gemeinsam m it 15. April 1998
TABELLENVERZEICHNIS
Tabelle 1: Interviews und Abstimmungsgespräche
Tabelle 2: Workshops – Termine und Teilnehmer
Tabelle 3: Modelltypverwendung
Tabelle 4: Modell-/Objekttypzuordnung
Tabelle 5: Objekt-/Attributtypzuordnung
Tabelle 6: Legende zu den Anmerkungen
Tabelle 7: Mengengerüst der Studien- und Prüfungsverwaltung i.w.S.
Tabelle 8: Zuordnung des Schutzbedarfes
Tabelle 9: Empfohlene Basistermine
Tabelle 10: Definition möglicher Umstellungsstufen
Tabelle 11: Zuordnung der neuen Objekte
Tabelle 12: Numerierung der Prozeßbereiche (Verwaltung)
Tabelle 13: Bezugsgrößen der Prozeßbereiche
Tabelle 14: Numerierung der Prozeßbereiche (Institute)
Tabelle 15: Gegenüberstellung der geschätzten Kosten
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 8
VERZEICHNIS DER ABKÜRZUNGEN
ARIS Architektur Integrierter InformationsSysteme
BeSt Betriebswirtschaftliche Steuerlehre
BüRe Bürgerliches Recht
CDLS Chipkartenbasiertes Dienstleistungssystem
EEPK Erweiterte Ereignisgesteuerte Prozeßkette
EnSp Englische Sprachen
FI Finanzierung
InstDB Datenbank auf UDS-Basis, Teil des Altsystems
ISO/IEC International festgelegter Standard
IT Informationstechnologie
LV Lehrveranstaltung
PAL Personenarbeitsleistung (Arbeitsleistung einer Person)
PAM Prozeßauswahlmatrix
PeWi Personalwirtschaft
PIN Personal Identification Number
PoÖk Politische Ökonomie
POS Point of Sale
PUK Personal Unblocking Key
RO Rechts- und Organisationisabteilung
RoSp Romanische Sprachen
STAB Studien- und Prüfungsabteilung
StepDB Datenbank auf UDS-Basis, Teil des Altsystems
UDS Codasyl-basiertes Datenbanksystem der Firma SNI
WA Warenhandel
WI Wirtschaftsinformatik
WiSoGe Wirtschafts- und Sozialgeschichte
Anhang A Verzeichnisse
Seite 6 von 8 Erstellt gemeinsam m it 15. April 1998
WS 1 Workshop 1
WS 2 Workshop 2
WS 3 Workshop 3
WS 4 Workshop 4
ZAS Zentrum für Auslandsstudien
ZID Zentrum für Informatikdienste
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 8
VERZEICHNIS DER DOKUMENTE
[BeRoSchü95] Becker, J., Rosemann, M., Schütte, R.: Grundsätze ordnungsmäßiger Modellierung, Wirtschaftsinformatik, 37 (1995) 5
[FeSi94] Ferstl, O.K., Sinz, E.J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschäftsprozessen, Bamberger Beiträge zur Wirtschaftsinformatik, Nr . 21, 1994
[Fla90] Flatscher, R.G.: Entwicklung eines PC-basierten Lehrveranstal-tungsadministrationssystems für die Abteilungen an der Wirt-schaftsuniversität Wien, Service Fachverlag, Wien, 1990
[Kru97] Krumbiegel, J.: Integrale Gestaltung von Geschäftsprozessen und An-wendungssystemen in Dienstleistungsbetrieben, Deutscher Uni-versitätsverlag, Wiesbaden, 1997
[KruOeSiVa95] Krumbiegel, J., Oechsler, W.A., Sinz, E.J., Vaanholt, S.: Business Pro-cess Reengineering an der Universität, Personal, Heft 10/1995
[Mi86] Miksch, G.: Strategische Informationssystemplanung - dargestellt am Beispiel der zentralen Verwaltung der Wirtschaftsuniversität Wien, Service Fachverlag, 1986
[PiSchwa97] Piller, E., Schwarzinger, M.: WU-PowerCard - Einsatzmöglichkeiten von Chipkarten an der WU, Wien, 1997
[Pö88] Pönighaus, R.: Der Nutzen von Informations - und Kommunikations-systemen an Forschungs - u. Lehrarbeitsplätzen - Theoretische Analy-se und empirische Ergebnisse, Hansen/Janko (Hrsg.), WU Wien, 1988
[ProSo93] Prosser, A., Sommer, B.: EDV-unterstützte Lehrveranstaltungsad-ministration an der Wirtschaftsuniversität Wien, Handbuch für In -formationsanbieter im WU-BTX-System, 2. Aufl., WU Wien, 1993
[Scheer95] Scheer, A.-W.: Wirtschaftsinformatik - Referenzmodelle für industrielle Geschäftsprozesse, 6. Aufl., Berlin et al. 1995
[Scheer98] Scheer, A.-W.: ARIS - Vom Geschäftsprozeß zum Anwendungssys-tem, 3. Aufl., Berlin et al. 1998
[Schmi97] Schmidt, S.: WU Informationssystem 2000 - Neue Ansätze der Stu-dentenverwaltung, Diplomarbeit, WU Wien, 1997
Anhang A Verzeichnisse
Seite 8 von 8 Erstellt gemeinsam m it 15. April 1998
[Si95] Sinz, E.J.: Serviceorientierung der Hochschulverwaltung und ihre Un-terstützung durch workflow-orientierte Anwendungssysteme, Bamber-ger Beiträge zur Wirtschaftsinformatik, Nr. 35, 1995
[Si96] Sinz, E. et al.: WU IS 2000 – Geschäftsprozeß- & Anwendungssys-temarchitektur der WU Wien, Bamberg, 1996
[Si97] Sinz, E.J.: Analsyse und Gestaltung universitärer Geschäftsprozesse und Anwendungssysteme, Bamberger Beiträge zur Wirt-schaftsinformatik, Nr. 41, 1997
[WI94] Organisationshandbuch der Abteilung für Wirtschaftsinformatik an der WU Wien, 1994
[WUWi97] WU Wien: Bericht der Studiendekane, Wien, 1997
[ZID97] WU Wien, Zentrum für Informatikdienste: Grobkonzept 2gether, Anlage zum Offenen Verfahren, WU Wien, 1997
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 12
Anhang B enthält eine Auflistung markanter Datenfelder, alphabetisch geordnet nach dem jeweils übergeordneten Datenobjekt (Entitytyp oder Beziehungstyp).
Objektname
Feldname Bemerkung
Abgeltungsart
Bezeichnung z.B. Kollegiengeld, Tutorengeld
Regelwerk
Abschlußarbeit
Titel Ggf. auch englisch
Typ der Arbeit Diplomarbeit, Dissertation etc.
Abgabedatum
Seitenzahl
Textsprache
Kurzfassung Abstract
Schlagwörter ggf. auch englisch
Vorkenntnisse Erforderliche Vorkenntnisse
Methoden benötigte Methoden
Fristen z.B. für Themeabgrenzung, Vorlage einer Grob-fassung
Bemerkungen z.B. Ablaufplanung, Benotung
Literaturliste
Web-Link-Liste
Förderungs-möglichkeiten
<sonstige Felder> s. 'Grobkonzept 2gether', S. 77ff
Abschlußarbeitbegutachtung
Beurteilung
Begründung
Anhang B Datenfelder
Seite 2 von 12 Erstellt gemeinsam m it 15. April 1998
Objektname
Feldname Bemerkung
AA-Fach-ZUO
Fachrolle Erstfach, Nebenfach
Adresse
PLZ Postleitzahl
Ort
Land
Strasse
Telefon
Anerkennungsbescheid
Aktenzeichen
Ablehnung? Kennzeichen, ob der Bescheid ablehnend ist
Datum der Bescheidung
Ausfolgedatum
Datum der Anrechnung
Anerkennungsgegenstand
Art der Anerkennung
Nummer lfd. Nummer der Anerkennung
Semesteranzahl Anzahl der angerechneten Semester
Note Note, falls nicht aus dem Ergebnis angerechnet wird
Bemerkung
Behörde Bezeichnung der ausstellenden Behörde, z.B.der ausl. Universität
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 12
Objektname
Feldname Bemerkung
Staat
Stadt
Ausstellungsdatum Ausstellungsdatum der Urkunde
Anmeldung
Datum
Typ z.B. LV, Prüfung
Status z.B. aktuell, zurückgenommen
Nummer lfd. Nummer der Anmeldung
Arbeitsbericht
# wiss. Institutspersonal Anzahl wiss. Institutspersonal
# abgehaltene Lehrveranstal-tungen
Anzahl abgehaltene Lehrveranstaltungen
# durchgeführte Beurteilun-gen
Anzahl durchgeführte Beurteilungen
Belastungsanalysen s. 'Grobkonzept 2gether', S. 95 f
Erhebungsbogen
Zielerfüllung
Didaktik
Lernbehelfe
Betreuung
Lehrauftragsrahmen
Lehrauftragstyp Funktion der beteiligten Org.-Einheit
Versteuerungsart
Anhang B Datenfelder
Seite 4 von 12 Erstellt gemeinsam m it 15. April 1998
Objektname
Feldname Bemerkung
Lehrveranstaltung
Bezeichnung
LV-Typ
<Felder aus der LV-Ankündigung>
Daten, die schließlich für die LV gelten und rele-vant sind
Lehrveranstaltungsanmeldung
Plazierung in der Anmel-dungsreihenfolge
Lehrveranstaltungsbeurteilung
Teilnahmefrequenz
Beurteilung
Öffentlichkeitsgrad
Globalurteile (Zufriedenheit, Empfehlung)
Durchfallquoten
Allgemeine Fragen
Individuelle Fragen
Lehrveranstaltungsrahmen
Kontingent, remuneriert Schlüsselattribut
Kontingent, nicht remuneriert
Rahmenwerte
Lehrveranstaltungsteilnahme
Ergebnisse auch Zwischenergebnisse
Lehrveranstaltungstermin
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 12
Objektname
Feldname Bemerkung
Teilnehmerzahl
LV-Ankündigung
LV-Beginn
LV-Ende
Nummer lfd. Nummer im Abhaltungsplan
Bezeichnung
Typ z.B. Vorlesung, Seminar, Lehrgang
Wochenstunden
LV-Termine Wochentage, Uhrzeiten
Letztes Semester Semester, in dem die LV zuletzt abgehalten wurde
Status Status der Ankündigung, z.B. vorläufig, entgültig
Modus Abhaltungsmodus
Anmeldeart
ECTS-Anerkennungspunkte European Credit Transfer System-Credits
Reihenfolgeverfahren
Lehrinhalte
Lehrziele
Unterrichtssprache
Anforderungen
Verwendete Literatur
# Teilnehmer max. Anzahl der Teilnehmer
<sonstige Abhaltungsinfor-mationen>
s. 'Grobkonzept 2gether', S. 58
LV-Beteiligung v. Org.-Einheit
Anhang B Datenfelder
Seite 6 von 12 Erstellt gemeinsam m it 15. April 1998
Objektname
Feldname Bemerkung
Funktion Funktion der beteiligten Org.-Einheit
Remunerationstyp
Art der Beteiligung
LV-Beteiligung Mitarbeiter
Rechtliche Grundlage z.B. Venia, Gastprofessur etc.
Abrechnungsdaten
Art der Beteiligung z.B. Leitung etc.
Leistung
Leistungsart s. 'Grobkonzept 2gether', S. 91
Mitarbeiter/-in
Vorname
Zuname
Akad. Grad
Anrede
Telefonklappe
Familienstand
Geburtsdatum
Geburtsort
Geschlecht
Sozialversicherungsnummer
Art der Person
Funktion
Staatsbürgerschaft
Dienstverhältnis
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 12
Objektname
Feldname Bemerkung
Nostrifizierung
Grad Bezeichnung des verl. Grades
Organisationseinheit
Bezeichnung
Art der Org.-Einheit z.B. extern/intern
Typ der Org.-Einheit z.B. Abteilung, Fachbereich, Institut
Hochschulcode lt. Ministeriumsentwurf
Fachgruppe
Öffnungszeiten
Prüfung
Bezeichnung
Prüfungsart
Beschreibung
Prüfungscode lt. Ministerium
Prüfungen des wiss. MA
Anmeldezeitraum
Teilnehmerzahlen
Zuteilungssystem
Prüfung des Studenten
Beurteilung Endnote/Ergebnis
Status
Einsichtsfrist
Zwischenergebnis 1-n
Punkte
Anhang B Datenfelder
Seite 8 von 12 Erstellt gemeinsam m it 15. April 1998
Objektname
Feldname Bemerkung
Prüfungstermin
Position
Raum
Größe
Ausstattung
Reservierung
Belegungszeit Schlüsselattribut
Status
Rückmeldung
Datum
Typ
Bemerkung
Semester
Semesteranfang
Semesterende
Jahr
Bezeichnung
Typ Sommer-, Wintersemester
1. Unterrichtswoche mind. 14 Wochen
Letzte Unterrichtswoche
Lehrveranstaltungsfreie Ze i-ten
Immatrikulationsfrist
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 9 von 12
Objektname
Feldname Bemerkung
Rückmeldungsfrist
Prüfungszeiträume
Sponsionstermine
Promotionstermine
Studium
Studientyp Kennzahl, Bezeichnung
Gesamt-stundenzahl
Studium des Studenten
Anfangsdatum
Enddatum
Status z.B. "aufgenommenes ordentliches Studium", "aufgenommenes Studium irregulare"
Erfüllungsstatus Bei Beendigung des Studiums: Sind alle Stu-dienplanpunkte erfüllt?
Abgabestatus Bei Beendigung des Studiums: Sind die erfoder-lichen Exemplare der Abschlußarbeit abgeben?
Student/-in
Name
WU-Matrikelnummer
Vermerk Zahlweise
Gebührenstatus
Immatrikulationsstatus
Schule absolvierte Schule
Schulform Form der absolvierten Schule
Anhang B Datenfelder
Seite 10 von 12 Erstellt gemeinsam m it 15. April 1998
Objektname
Feldname Bemerkung
Aufnahmedatum
Exmatrikulationsdatum
Reifeprüfungsdatum
Stammhochschule
Rückgabestatus I Bei Beendigung des Studiums: Sind die entlie-henen Bücher abgeben?
Rückgabestatus II analog: Geräte
Rückgabestatus III analog: Schlüssel
Saldenstatus Salden auf diversen Konten?
Studentenausweis
Gültigkeitszeitraum
Status
Kontonummer der WU Zwecks Bezahlung vom Bankomat-Terminal
Studienplan
Bezeichnung
Datum des Inkrafttretens
Ablaufdatum
Versionsnummer
Titel Titel, der durch die Absolvierung des Studienab-schnitts verliehen wird
Studienabschnitt des Studiums
Anzahl der Semester Anzahl der Semester, die inskribiert sein müssen
Nummer lfd. nummer des Abschnitts
Nachlaßsemester Anzahl der Semester, die nachgelassen werden
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 11 von 12
Objektname
Feldname Bemerkung können
Stundenzahl
Studium der Zulassung
Lfd. Nr.
Status
Studiumsänderung
Typ z.B. Wechsel, Aufnahme, Beendigung
Studienplanpunkt
Bezeichnung
Typ
Stundenausmaß
Termin des wiss. MA
Anmeldekapazität
Terminliste
Gültigkeitszeitraum
Art der Termine z.B. Prüfungstermin, Vorlagetermine
Vergabe
Status Interesse, Bearbeitung
Wartelistenposition
Position
Anhang B Datenfelder
Seite 12 von 12 Erstellt gemeinsam m it 15. April 1998
Objektname
Feldname Bemerkung
Zuteilung
Belegungszeit Schlüsselattribut
Zulassung zum Studium
Datum der Zulassung
Vorlagetermin
Anmeldenummer
Status
<Ersterfassungsfelder> s. 'Grobkonzept 2gether', S. 42 ff
Hochschulstatistik Felder des Formulars des Statistischen Ze ntral-amts
Kennwort
Kennwort (Wdh.)
Bemerkung z.B. Begründung für Stornierung
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 7
Struktur und Modelliste
Die Struktur der ARIS -Datenbank13 läßt sich der ersten Spalte der folgenden Tabelle ent-nehmen, die insbesondere eine Liste aller relevanten, im Rahmen des Projektes erstellten Modelle enthält.
Gruppe Modell Typ
\ROOT Legende EEPK
\ROOT\2gether WU Wien Organigramm
\ROOT\2gether\Soll-Konzept 2gether, Grobkonzept Funktionsbaum
Studien- und Prüfungsverwaltung Funktionsbaum
Studien- und Prüfungsverwaltung EERM
Anwendungen WU-Wien Soll Anwendungssystemtypdiagr.
\ROOT\2gether\Soll-Kon-zept\Lehrveranstaltungen
Lehrveranstaltungen administrieren Funktionsbaum
Aufnahme von Lehrveranstaltungen EEPK
Planung von Lehrveranstaltungen EEPK
Lehrveranstaltung EERM
Vorlesungsverzeichnis EERM
Administration Lehrveranstaltung Funktionszuordnungsdiagr.
Aufnahme Lehrveranstaltung Funktionszuordnungsdiagr.
Planung Lehrveranstaltung Funktionszuordnungsdiagr.
Lehrveranstaltung Prozeßauswahlmatrix
\ROOT\2gether\Soll-Kon-
Anwesenheitslisten führen Funktionszuordnungsdiagr.
13 Nicht zu verwechseln mit der Struktur der ARIS -Methodik.
Anhang C ARIS-Datenbank/Modell-Liste
Seite 2 von 7 Erstellt gemeinsam m it 15. April 1998
Gruppe Modell Typ
zept\Lehrveranstaltungen\Detailfunktionen
Datenfelder freigeben zur Ansicht Funktionszuordnungsdiagr.
Endnoten eingeben Funktionszuordnungsdiagr.
Layout der Anmeldeliste festlegen Funktionszuordnungsdiagr.
Lehrveranstaltungen mit eigener Beteili-gung auflisten
Funktionszuordnungsdiagr.
Nachmeldungen eingeben Funktionszuordnungsdiagr.
Studierende zu Gruppen zusammenfas-sen
Funktionszuordnungsdiagr.
Studierendenlisten pro LV ausgeben Funktionszuordnungsdiagr.
Teilnehmerlisten & Anwesenheitslisten ausdrucken
Funktionszuordnungsdiagr.
Zwischenergebnisse & Mitarbeitsnoten eingeben
Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\Prüfungen
Leistungsfeststellung EEPK
Planung von Prüfungen EEPK
Prüfung EERM
Leistungsfeststellung Funktionszuordnungsdiagr.
Planung Prüfungstermin Funktionszuordnungsdiagr.
Prüfung Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Diplomarbeiten & Dissertationen
Diplomarbeiten/Dissertationen betreuen Funktionsbaum
Diplomarbeiten/Dissertationen vereinba-ren
Funktionsbaum
Diplomarbeiten/Dissertationen abschlie-ßen
EEPK
Diplomarbeit/ Dissertation EERM
Einreichung, Beurteilung & Veröffentli- Funktionszuordnungsdiagr.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 7
Gruppe Modell Typ
chung
Laufende Betreuung Funktionszuordnungsdiagr.
Themenvereinbarung Funktionszuordnungsdiagr.
Diplomarbeit/ Dissertation Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Diplomarbeiten & Dissertatio-nen\Detailfunktionen
Abgabetermine festsetzen Funktionszuordnungsdiagr.
Betreuer wechseln Funktionszuordnungsdiagr.
Dokumententransfers durchführen Funktionszuordnungsdiagr.
Erinnerungen bei Fristüberschreitungen verschicken
Funktionszuordnungsdiagr.
Interessenten- Daten eintragen Funktionszuordnungsdiagr.
Mustervorlagen für Arbeit erstellen Funktionszuordnungsdiagr.
Statusveränderungen der Arbeit durchfüh-ren
Funktionszuordnungsdiagr.
Stichwortkatalog erstellen Funktionszuordnungsdiagr.
Termine abstimmen Funktionszuordnungsdiagr.
Themen eintragen Funktionszuordnungsdiagr.
Voraussetzungen prüfen Funktionszuordnungsdiagr.
Zweitgutachter festlegen Funktionszuordnungsdiagr.
über Thema, Bearbeiter und Erstbetreuer informieren
Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\An- und Abmel-dungen
Abmeldungen Funktionsbaum
LV-Anmeldungen Funktionsbaum
Prüfungsanmeldungen Funktionsbaum
An- und Abmeldung EERM
Abmeldung durchführen Funktionszuordnungsdiagr.
Anhang C ARIS-Datenbank/Modell-Liste
Seite 4 von 7 Erstellt gemeinsam m it 15. April 1998
Gruppe Modell Typ
Lehrveranstaltungsanmeldung durchfüh-ren
Funktionszuordnungsdiagr.
Prüfungsanmeldung durchführen Funktionszuordnungsdiagr.
An-und Abmeldung Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\An- und Abmel-dungen\Detailfunktionen
Abmeldung überprüfen Funktionszuordnungsdiagr.
Anmelde-Berechtigungen überprüfen Funktionszuordnungsdiagr.
Informationen weitergeben Funktionszuordnungsdiagr.
Kapazitätsanalysen durchführen Funktionszuordnungsdiagr.
LV/Prüfung auswählen Funktionszuordnungsdiagr.
Lehrveranstaltung auswählen Funktionszuordnungsdiagr.
Lehrveranstaltungsanmeldung prüfen Funktionszuordnungsdiagr.
Prüfung auswählen Funktionszuordnungsdiagr.
Prüfungsanmeldung überprüfen Funktionszuordnungsdiagr.
Sicherheitsvorkehrungen durchführen Funktionszuordnungsdiagr.
Zuteilungsalgorithmen entwerfen Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\Anerkennungen
Anerkennungen erzielen EEPK
Nostrifikationen erzielen EEPK
Anerkennung EERM
Erzielen von Anerkennungen Funktionszuordnungsdiagr.
Erzielen von Nostrifikationen Funktionszuordnungsdiagr.
Anerkennung Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Abrechnungen
Abrechnungen mit PAV und PTKG EEPK
Abrechnungen mit PAV und ohne PTKG EEPK
Abrechnungen ohne PAV und PTKG EEPK
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 5 von 7
Gruppe Modell Typ
Abrechnung EERM
Abrechnung Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\Evaluierungen
Arbeitsberichte erstellen Funktionsbaum
Beurteilung von Lehrveranstaltungen EEPK
Evaluierung EERM
Arbeitsbericht Institutsvorstände Funktionszuordnungsdiagr.
Beurteilung Lehrveranstaltung Funktionszuordnungsdiagr.
Evaluierung der Lehre Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\Studien
Beendigung des Sonderstudiums EEPK
Beendigung des Studiums EEPK
Erstellung Diplomzeugnis EEPK
Rückmeldung Studierende mit Zahlschein EEPK
Rückmeldung Studierende ohne Zahl-schein
EEPK
Zulassung Studierende mit Nostrifikation-sauflagen
EEPK
Zulassung Studierende mit Studienbe-rechtigungsprüfung
EEPK
Zulassung Studierende mit allg. Voraus-setzungen
EEPK
Zulassung Studierende mit bes. Voraus-setzungen
EEPK
Zulassung Studierende mit indiv. Diplom-studiengang
EEPK
Zusatzstudium/Wechsel des Studiums EEPK
Studienplan EERM
Studium EERM
Beendigung Studium Funktionszuordnungsdiagr.
Anhang C ARIS-Datenbank/Modell-Liste
Seite 6 von 7 Erstellt gemeinsam m it 15. April 1998
Gruppe Modell Typ
Diplomzeugniserstellung Funktionszuordnungsdiagr.
Rückmeldung Studium Funktionszuordnungsdiagr.
Wechsel Studium/Aufnahme Zusatzstu-dium
Funktionszuordnungsdiagr.
Zulassung Studium Funktionszuordnungsdiagr.
Zulassung Studium mit Auflagen Funktionszuordnungsdiagr.
Zulassung Studium mit Berechtigungs-prüfung
Funktionszuordnungsdiagr.
Zulassung Studium mit allg. Vorausset-zung
Funktionszuordnungsdiagr.
Zulassung Studium mit bes. Vorausset-zung
Funktionszuordnungsdiagr.
Zulassung Studium mit ind. Studiengang Funktionszuordnungsdiagr.
Studium Prozeßauswahlmatrix
\ROOT\2gether\Soll-Konzept\allgemeine Funkti-onen
Hörsaaladministration Funktionsbaum
PowerCard Funktionsbaum
allgemeine Funktionen Funktionsbaum
Adresse EERM
Raumverwaltung EERM
Hörsaaladministration Funktionszuordnungsdiagr.
\ROOT\2gether\Soll-Konzept\allgemeine Funkti-onen\Detailfunktionen
Chipkartenfunkionen Funktionszuordnungsdiagr.
Chipkartenverwaltung Funktionszuordnungsdiagr.
Hörsaal reservieren Funktionszuordnungsdiagr.
Hörsaal verwalten Funktionszuordnungsdiagr.
Hörsaal zurückgeben Funktionszuordnungsdiagr.
Hörsaalreservierungs-Info versenden Funktionszuordnungsdiagr.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 7 von 7
Gruppe Modell Typ
Hörsäle tauschen Funktionszuordnungsdiagr.
Institutshörsaal verwalten Funktionszuordnungsdiagr.
Kollisionsprüfung durchführen Funktionszuordnungsdiagr.
Reservierung freigeben Funktionszuordnungsdiagr.
Reservierungssituation abfragen Funktionszuordnungsdiagr.
autom. Hörsaalplanung durchführen Funktionszuordnungsdiagr.
man. Hörsaalzuteilung durchführen Funktionszuordnungsdiagr.
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 2
Anhang D enthält die wichtigsten Modelle der ARIS -Datenbank, u. zw.:
Gruppe Modell Typ
Soll-Konzept 2gether, Grobkonzept Funktionsbaum
Studien- und Prüfungsverwaltung Funktionsbaum
Lehrveranstaltungen administrieren Funktionsbaum Lehrveranstaltungen
Aufnahme von Lehrveranstaltungen EEPK
Planung von Lehrveranstaltungen EEPK
Prüfungen Leistungsfeststellung EEPK
Planung von Prüfungen EEPK
Diplomarbeiten/Dissertationen betreuen Funktionsbaum Diplomarbeiten &
Dissertationen Diplomarbeiten/Dissertationen vereinbaren Funktionsbaum
Diplomarbeiten/Dissertationen abschließen EEPK
Abmeldungen Funktionsbaum An- und Abmeldun-
gen LV-Anmeldungen Funktionsbaum
Prüfungsanmeldungen Funktionsbaum
Anerkennungen Anerkennungen erzielen EEPK
Nostrifikationen erzielen EEPK
Abrechnungen Abrechnungen mit PAV und PTKG EEPK
Abrechnungen mit PAV und ohne PTKG EEPK
Abrechnungen ohne PAV und PTKG EEPK
Evaluierungen Arbeitsberichte erstellen Funktionsbaum
Beurteilung von Lehrveranstaltungen EEPK
Studien Beendigung des Sonderstudiums EEPK
Beendigung des Studiums EEPK
Erstellung Diplomzeugnis EEPK
Anhang D ARIS-Datenbank/wichtigste Modelle
Seite 2 von 2 Erstellt gemeinsam m it 15. April 1998
Gruppe Modell Typ
Rückmeldung Studierende mit Zahlschein EEPK
Rückmeldung Studierende ohne Zahlschein EEPK
Zulassung Studierende mit Nostrifikationsauflagen EEPK
Zulassung Studierende mit Studienberechtigungsprüfung EEPK
Zulassung Studierende mit allg. Voraussetzungen EEPK
Zulassung Studierende mit bes. Voraussetzungen EEPK
Zulassung Studierende mit indiv. Diplomstudiengang EEPK
Zusatzstudium/Wechsel des Studiums EEPK
Hörsaaladministration Funktionsbaum Allgemeine Funktio-
nen PowerCard Funktionsbaum
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 1 von 3
Das ARIS-Toolset stellt als datenbankbasiertes System zur Modellierung betrieblicher Informationssysteme ein Reporting-Tool zur Verfügung, daß es ermöglicht, Ad-Hoc-Auswertungen der ARIS -Datenbank zu erhalten.
Die folgende Tabelle zeigt beispielhaft eine Auflistung der vom System ‘2gether’ auto-matisiert, d.h. etwa in einem Batch-Lauf durchzuführende Funktionen, sortiert nach den zugehörigen Prozessen.
Modell Funktion Automa-tisiert
Aufnahme von Lehrveranstal-tungen
Beauftragungsbescheide verschicken X
Planung von Lehrveranstal-tungen
Erinnerung bzgl. Erhebungsbogen an LV -Leiter verschi-cken
X
Erinnerung bzgl. LV-Beschreibung verschicken X
Historie v. LV -Leiter und LV überprüfen X
Leistungsfeststellung Anmeldedaten anzeigen X
Auswahlliste aller Prüfungen ohne Noteneingabe gene-rieren
X
Daten an Rechts- und Organisationsabteilung weiterlei-ten
X
Studierenden über Einsichtstermine benachrichtigen X
Studierenden über Noteneintrag benachrichtigen X
Planung von Prüfungen Prüfung anzeigen X
über Terminierungsprobleme informieren X
Auswahlliste der möglichen Prüfungen generieren X
Prüfungstermin in Kalender eintragen X
Anerkennungen erzielen Antragsteller über Anerkennung informieren X
Abrechnungen mit PAV und PTKG
Datenabgleich vornehmen (2gether,PIS -> PTKG) X
Abrechnungen mit PAV und ohne PTKG
Daten übermitteln (2gether->PAV) X
Datenabgleich vornehmen (PIS->2gether) X
Abrechnungen ohne PAV und PTKG
Abrechnungsbelege erstellen X
Anhang E ARIS-Datenbank/Auswertungen
Seite 2 von 3 Erstellt gemeinsam m it 15. April 1998
Modell Funktion Automa-tisiert
Adressenangaben der Fehlläufer angeben X
Anweisungen an Postsparkasse übermitteln X
Daten an Bundesrechenzentrum schicken X
Datenabgleich vornehmen (PIS->2gether) X
Fehlläufer informieren X
Leistungsempfänger benachrichtigen X
Beendigung des Sonderstu-diums
Abmeldung bewirken X
Bescheid erstellen X
Information der Abmeldung versenden X
Kartenfunkionen deaktivieren X
Saldo der Abrechnungskonten prüfen X
Studienblatt zur Beendigung generieren X
Studierenden über Negativsalden informieren X
Studierendenstammsatz deaktivieren X
Beendigung des Studiums Abmeldung bewirken X
Information der Abmeldung versenden X
Kartenfunkionen deaktivieren X
Saldo der Abrechnungskonten prüfen X
Studienblatt zur Beendigung generieren X
Studierenden über Negativsalden informieren X
Studierendenstammsatz deaktivieren X
Erstellung Diplomzeugnis Sponsionsbescheid versenden X
Rückmeldung Studierende mit Zahlschein
Bezahlungen bzgl. Rückmeldung überprüfen X
an Rückmeldungsbezahlung erinnern X
Rückmeldung Studierende ohne Zahlschein
Erinnerung an Rückmeldung versenden X
Zulassung Studierende mit Studienberechtigungsprüfung
Prüfungsbescheid zur Studienberechtigungsprüfung konfigurieren
X
Zulassung Studierende mit Zulassungsvoraussetzungen prüfen X
Grobkonzept Projekt
Erstellt gemeinsam mit 15. April 1998 Seite 3 von 3
Modell Funktion Automa-tisiert
allg. Voraussetzungen
ÖH-Beitrag zurückerstatten X
Zulassung Studierende mit bes. Voraussetzungen
Dokumente zur Zulassung anfordern X
Zulassungsvoraussetzungen prüfen X
ÖH-Beitrag zurückerstatten X
Zusatzstudium/Wechsel des Studiums
Ergebnis des Studienwunsches anzeigen X
Möglichkeit der Leistungsanerkennung überprüfen X
Möglichkeit zur Aufnahme des Zusatzstudiums über-prüfen
X
Neue Studienwahl bestätigen X
Wechselmöglichkeit überprüfen X
bisherige Leistungen anerkennen X