Sollspezifikation Projekt der …michael.hahsler.net/INFWI2/together/Bericht.pdf · daß solche...

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


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


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


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


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


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


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


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


Abbildung 3: Partner im Projekt „2gether“

2.3 Projektorganisation

Die Aufbauorganisation des Projekts ist in Abbildung 4 dargestellt.

Grobkonzept Projekt


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


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


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


• 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



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






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


10.3.1998 ÖH Hysek

10.3.1998 Englische Sprache Prof. W. Obenaus, D. Schleihs


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


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



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:




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


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


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


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


ßVereinfachte Materialbestellung undAufmaßerstellung mit anschließender

Rechnungserstellung der Baufirmen




ß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


ßVereinfachte Materialbestellung undAufmaßerstellung mit anschließenderRechnungserstellung der Baufirmen




ß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


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


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



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


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.



Studien- undPrüfungs-verwaltung

allgemeineFunktionenStudium

*

Lehrver-anstaltung

*

Prüfung

*

Abschluß-arbeiten

*

An-undAbmeldung

*

Anerkennung

*

Abrechnung

*


*

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


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.



Semester-beginn

eingetreten

automatische Generationvom System

Beauftragungs-Bescheidegenerieren

LV-Leiterelektronischerreichbar

Normalfall

2gether

Beaufragungs-bescheide

verschicken

automatisch

LV-Leiterbenachrichtigt

E-Mail

Beauftragungs-bescheidedrucken

Beauftragungs-bescheide

2gether 2gether

Beauftragungs-bescheidegedruckt

absoluterAusnahmefall

LV-Leiterbenachrichtigen

LV-Leiterelektronisch

nicht erreichbar

absoluterAusnahmefall


abteilungBeauftragungs-bescheide


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


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



Abbildung 14: Legende der verwendeten Objekttypen

Grobkonzept Projekt


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


• 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


• 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


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


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


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



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


Objekt-/Symboltyp

Attributtyp Kann Muß Inhalt

Informationsträger --


--

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


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


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


4.1.1 Übersicht

Studien- undPrüfungs-verwaltung

allgemeineFunktionenStudium

*

Lehrver-anstaltung

*

Prüfung

*

Abschluß-arbeiten

*

An-undAbmeldung

*

Anerkennung

*

Abrechnung

*


*

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



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


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


Studien-wechsel

BeendigungStudium

P


*Zusatzstudium/

Wechsel desStudiums

P*

BeendigungStudium

P*

P


P


*

* P


Studiums

P*

BeendigungStudium


P


P*Zusatzstudium/

Wechsel desStudiums

P*

P

BeendigungStudium

*

P


P


*

P


Studiums*

P

BeendigungStudium

*

P


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


(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


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




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



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*



(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-



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.


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


4.1.2.3 Zusatzstudium/Wechsel des Studiums

P*


StudiumsStudent/-in


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


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



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


(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


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



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




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


StudiumStudiendekan/

Vizestudiendekan


(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


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.




4.1.3.1 Planung von Lehrveranstaltungen

P*

Planung vonLehrver-

anstaltungen

Institut/Abteilung

LV-Leiter/-in

Büro desStudiendekans


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


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.




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



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




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


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


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.


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.


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



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


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.


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-



ten umgelegt werden. Hinzukommen sollte die Mitarbeit der Prüfer an den Abteilun-gen/Instituten, die die relevanten Daten direkt in das System eingeben.


4.1.4.1 Planung von Prüfungen

P*

Planung von

Prüfungen

LV-Leiter/-in

Büro des

Studiendekans


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


Grobkonzept Projekt


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


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.



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


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




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


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.


Nutzenpotential: Diplomarbeiten/Dissertationen

Institute/Mittelbau

Plus Studenten geben Daten direkt in das System ein.

Themendatenbank informiert übersichtlich alle Studenten.




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.


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



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


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-



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


4.1.5.2 Diplomarbeiten/Dissertationen betreuen

F*


betreuen


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.


Grobkonzept Projekt


4.1.5.3 Diplomarbeiten/Dissertationen abschließen

P*


abschließen

Studiendekan/Vizestudiendekan

Betreuer/-in

Student/-inStudium


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.


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



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.


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


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.1.6.2 Prüfungsanmeldungen

F

Prüfungs-anmeldungen

Student/-in

An- undAbmeldung

Studium


(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


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.



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



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


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


(STAB)

Studien-dekanat

Prüfung

Fachbereich

Lehrver-anstaltung

Grobkonzept Projekt


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


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.



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


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.


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



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


4.1.7.2 Nostrifikationen erzielen

P

Nostrifi-kationenerzielen

Studium

Anerkennung

Studienplan


(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.1.8 Abrechnungen

P*

Ab-rechnungen


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


dest die Personaldaten aus WUFIS) integrieren und Schnittstellen zu dem System „PIS“ aufzeigen - alle notwendigen Informationen zur Abrechnung liefern.


4.1.9 Evaluierung der Lehre

*

Beurteilung

von Lehrver-anstaltungen

P

*

Arbeitsberichte

erstellen

F


*

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.


Nutzenpotential: Evaluierung der Lehre

Institute/Mittelbau und Sekretariate



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


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.




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.


Grobkonzept Projekt


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.



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.


Grobkonzept Projekt


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


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.


4.1.10.3 Stammdatenverwaltung

Die Stammdatenverwaltung sollte je nach Datenbereich klar definierte Zuständigkeiten aufweisen.




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


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“



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


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


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


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



• 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


• Ü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).



• 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


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


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



• 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


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



• 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


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


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


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.



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


4.3.2.2 Studienplan

Abbildung 51: Semantisches Datenmodell ‘Studienplan’




*

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


4.3.2.3 Lehrveranstaltung

Abbildung 52: Semantisches Datenmodell ‘Lehrveranstaltung’

*


*

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


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.


Teilnehmer-gruppe

z.B. als Basis für E-Mail-Verteilerlisten

bildet

*


termin

[Teilnehmerzahl] etc.

findetstatt an

Anwesenheit

*


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


Grobkonzept Projekt


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.3.2.6 An- und Abmeldung


Anmeldung

Prüfungs-anmeldung

1

giltfür

Studiumdes

Studierenden

1 cn

Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’

Grobkonzept Projekt


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


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


Reservierung

persönlicherRaum

Raum-anrecht

(Prüfungen)

Termin(-liste)des wiss.MA's Reservierung

Raum fürsonstige

Veranstaltung


raum

Hörsaal Seminar-raum

LV-Ankündigung

1

Zuteilung


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


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.3.2.12 Adresse

Adresse

Studierende/-r

Mitarbeiter


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


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


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


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


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


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


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


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


• 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


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


• 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


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


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


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


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


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


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


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


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


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


• 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


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


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.



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


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.



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


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


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


• 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-



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


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



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


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.



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


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.



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


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


• 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


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

Anhang A: Verzeichnisse

Grobkonzept Projekt


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


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


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



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


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



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


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



[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

Anhang B: Datenfelder

Grobkonzept Projekt


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


Objektname

Feldname Bemerkung

AA-Fach-ZUO

Fachrolle Erstfach, Nebenfach

Adresse

PLZ Postleitzahl

Ort

Land

Strasse

Telefon

E-Mail

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


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



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


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



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


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



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


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



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


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



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

Anhang C: ARIS-Datenbank/Modell-Liste

Grobkonzept Projekt


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


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


Studierendenlisten pro LV ausgeben Funktionszuordnungsdiagr.

Teilnehmerlisten & Anwesenheitslisten ausdrucken


Zwischenergebnisse & Mitarbeitsnoten eingeben


\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


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


Interessenten- Daten eintragen Funktionszuordnungsdiagr.

Mustervorlagen für Arbeit erstellen Funktionszuordnungsdiagr.

Statusveränderungen der Arbeit durchfüh-ren


Stichwortkatalog erstellen Funktionszuordnungsdiagr.

Termine abstimmen Funktionszuordnungsdiagr.

Themen eintragen Funktionszuordnungsdiagr.

Voraussetzungen prüfen Funktionszuordnungsdiagr.

Zweitgutachter festlegen Funktionszuordnungsdiagr.

über Thema, Bearbeiter und Erstbetreuer informieren


\ROOT\2gether\Soll-Konzept\An- und Abmel-dungen

Abmeldungen Funktionsbaum

LV-Anmeldungen Funktionsbaum

Prüfungsanmeldungen Funktionsbaum

An- und Abmeldung EERM

Abmeldung durchführen Funktionszuordnungsdiagr.



Gruppe Modell Typ

Lehrveranstaltungsanmeldung durchfüh-ren


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


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.



Gruppe Modell Typ

Diplomzeugniserstellung Funktionszuordnungsdiagr.

Rückmeldung Studium Funktionszuordnungsdiagr.

Wechsel Studium/Aufnahme Zusatzstu-dium


Zulassung Studium Funktionszuordnungsdiagr.

Zulassung Studium mit Auflagen Funktionszuordnungsdiagr.

Zulassung Studium mit Berechtigungs-prüfung


Zulassung Studium mit allg. Vorausset-zung


Zulassung Studium mit bes. Vorausset-zung


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


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

Anhang D: ARIS-Datenbank/wichtigste Modelle

Grobkonzept Projekt


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


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

Anhang E: ARIS-Datenbank/Auswertungen

Grobkonzept Projekt


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



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



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

Grobkonzept Projekt

Anhang F: Wirtschaftlichkeitsbetrachtungen (ZID)

Sollspezifikation Projekt der …michael.hahsler.net/INFWI2/together/Bericht.pdf · daß solche...

Documents

Transcript of Sollspezifikation Projekt der …michael.hahsler.net/INFWI2/together/Bericht.pdf · daß solche...