Sollspezifikation '2gether' der WU Wien · Web viewSollspezifikation Projekt. der WIRTSCHAFTSUNIVERSITÄT WIEN K:\WU-WIEN\SOLLSPEZ\BERICHT8.DOC INHALTSVERZEICHNIS. 1 Einleitung

$Page 1: Sollspezifikation '2gether' der WU Wien · Web viewSollspezifikation Projekt. der WIRTSCHAFTSUNIVERSITÄT WIEN K:\WU-WIEN\SOLLSPEZ\BERICHT8.DOC INHALTSVERZEICHNIS. 1 Einleitung$
SollspezifikationProjekt

derWIRTSCHAFTSUNIVERSITÄT WIEN

Eugen Klein, 03.01.-1,

Adaptierungsarbeiten unter Word 6.0: Überschriften neu numerieren Nach Einfügung von Querverweisen unter Word 97: Feldfunktionen anzeigen, alle „\n“ auf „\n \h“ ändern. Bei Bedarf Inhaltsverzeichnis neu erstellen. Adaptierung unter Word 97: Alle ” auf ” ändern (damit werden deutsche Anführungszeichen verwendet).

Grobkonzept Projekt

INHALTSVERZEICHNIS

1 EINLEITUNG.....................................................................................71.1 Auftrag........................................................................................................71.2 Warenzeichen..............................................................................................71.3 Redaktionelle Behandlung der Geschlechtlichkeit........................................7

2 PROJEKTDURCHFÜHRUNG.................................................................92.1 Ziele des Projekts........................................................................................92.2 Projektpartner...........................................................................................112.3 Projektorganisation....................................................................................12

2.3.1 Lenkungsausschuß...............................................................................142.3.2 Kernteam.............................................................................................14

2.4 Projektablauf.............................................................................................152.4.1 Sitzungen des Kernteams.....................................................................152.4.2 Sitzungen des Lenkungsausschusses....................................................152.4.3 Einbezogene Organisationseinheiten....................................................15

2.4.3.1 Einbezogene Institute/Abteilungen.................................................152.4.3.2 Einbezogene Verwaltungsstellen und sonstige Stellen....................162.4.3.3 Übersicht über die Interview- und Abstimmungstermine.................16

2.4.4 Präsentationen und Workshops............................................................192.4.5 Plakataktion.........................................................................................20

3 METHODIK UND VORGEHEN............................................................213.1 Die Phasen der Konzeption........................................................................213.2 Architektur integrierter Informationssysteme.............................................23

3.2.1 Hintergrund und Idee...........................................................................243.2.2 Die ARIS-Ebenen..................................................................................253.2.3 Die ARIS-Sichten...................................................................................26

3.3 Grundsätze ordnungsmäßiger Modellierung...............................................33

3.4 Projekt-/Modellierungskonventionen..........................................................363.4.1 Verwendung aufbauorganisatorischer Elemente...................................363.4.2 Aufbau der Modellhierarchie.................................................................36

3.4.2.1 Ablaufbeschreibung versus Funktionalitätsbeschreibung................36

Erstellt gemeinsam mit 15. April 1998 Seite 3 von 171

INHALTSVERZEICHNIS

3.4.2.2 Bildung von Szenarien....................................................................373.4.2.3 Integration von Daten und Funktionalitäten....................................37

3.4.3 Detaillierungsgrad................................................................................373.4.3.1 Datenmodelle.................................................................................373.4.3.2 Prozeßmodelle................................................................................37

3.4.4 Übersicht der Methodenverwendung....................................................38

4 FACHLICHE KONZEPTION DES SYSTEMS „2GETHER“........................434.1 Organisatorische Gestaltung der Studien- und Prüfungsverwaltung...........43

4.1.1 Übersicht..............................................................................................454.1.2 Studien.................................................................................................47

4.1.2.1 Zulassung Studium.........................................................................484.1.2.2 Rückmeldung Studium...................................................................514.1.2.3 Zusatzstudium/Wechsel des Studiums............................................534.1.2.4 Beendigung Studium......................................................................544.1.2.5 Erstellung Diplomzeugnis...............................................................56

4.1.3 Lehrveranstaltungen............................................................................574.1.3.1 Planung von Lehrveranstaltungen..................................................584.1.3.2 Aufnahme von Lehrveranstaltungen...............................................624.1.3.3 Lehrveranstaltungen administrieren...............................................65

4.1.4 Prüfungen............................................................................................664.1.4.1 Planung von Prüfungen...................................................................674.1.4.2 Leistungsfeststellung......................................................................69

4.1.5 Diplomarbeiten/Dissertationen.............................................................724.1.5.1 Diplomarbeiten/Dissertationen vereinbaren....................................744.1.5.2 Diplomarbeiten/Dissertationen betreuen........................................754.1.5.3 Diplomarbeiten/Dissertationen abschließen....................................76

4.1.6 An- und Abmeldungen..........................................................................774.1.6.1 LV-Anmeldungen............................................................................784.1.6.2 Prüfungsanmeldungen....................................................................804.1.6.3 Abmeldungen.................................................................................82

4.1.7 Anerkennungen....................................................................................844.1.7.1 Anerkennungen erzielen.................................................................854.1.7.2 Nostrifikationen erzielen.................................................................87

4.1.8 Abrechnungen......................................................................................884.1.9 Evaluierung der Lehre..........................................................................89

4.1.9.1 Beurteilung von Lehrveranstaltungen.............................................914.1.9.2 Arbeitsberichte erstellen................................................................92

4.1.10 Allgemeine Funktionen.......................................................................934.1.10.1 Chipkartenverwaltung..................................................................934.1.10.2 Hörsaaladministration..................................................................954.1.10.3 Stammdatenverwaltung...............................................................95

Seite 4 von 171 Erstellt gemeinsam mit 15. April 1998

Grobkonzept Projekt

4.1.10.4 Auswertungen/Ausdrucke.............................................................964.1.11 Allgemeine Systemfunktionen – Grundfunktionalitäten.......................97

4.2 Anregungen der verschiedenen Organisationseinheiten...........................1004.2.1 Studien- und Prüfungsabteilung..........................................................1004.2.2 Institute/Abteilungen..........................................................................1014.2.3 Studiendekanat..................................................................................108

4.3 Konzeptionelles Datenschema.................................................................1104.3.1 Intention.............................................................................................1104.3.2 Semantische Datenmodelle................................................................110

4.3.2.1 Studium.......................................................................................1114.3.2.2 Studienplan..................................................................................1134.3.2.3 Lehrveranstaltung........................................................................1154.3.2.4 Vorlesungsverzeichnis..................................................................1164.3.2.5 Prüfungen....................................................................................1164.3.2.6 An- und Abmeldung......................................................................1184.3.2.7 Diplomarbeiten und Dissertationen..............................................1194.3.2.8 Anerkennung................................................................................1204.3.2.9 Abrechnung..................................................................................1214.3.2.10 Hörsaalverwaltung.....................................................................1224.3.2.11 Evaluierung................................................................................1234.3.2.12 Adresse......................................................................................124

5 MENGEN- UND WERTGERÜST........................................................125

6 DATENSCHUTZ UND DATENSICHERHEIT.........................................1276.1 Schutzbedarfsermittlung..........................................................................127

6.1.1 Schutzstufenkonzept..........................................................................1286.1.1.1 Stufe I..........................................................................................1286.1.1.2 Stufe II.........................................................................................128

6.1.2 Schutzbedarf im Projekt „2gether“.....................................................1306.2 Chipkarten...............................................................................................1316.3 Internet...................................................................................................135

7 MIGRATIONSKONZEPT..................................................................1377.1 Allgemeines.............................................................................................1377.2 Ablöse STEPDB und INSTDB.....................................................................138

7.2.1 Datenübernahme...............................................................................1387.2.2 Anmerkungen zur Synchronisation von Datenbanken.........................139

7.3 Zeitlicher Aspekt.....................................................................................1397.4 Schnittstellen..........................................................................................140


INHALTSVERZEICHNIS

7.4.1 Vorlesungsverzeichnis........................................................................1407.4.2 Hörsaalbelegung................................................................................141

7.5 Übergangszeitraum.................................................................................1417.5.1 Historische Daten der Studenten........................................................1417.5.2 Selbstbedienungsfunktionen...............................................................142

7.6 Zeitlicher Ablauf......................................................................................1427.6.1 Datenüberleitung...............................................................................1447.6.2 Stammdatenerfassung.......................................................................1447.6.3 Phase 1..............................................................................................1457.6.4 Weitere Phasen..................................................................................145

7.7 Zuordnungen alte/neue Datenbank..........................................................145

8 WIRTSCHAFTLICHKEITSBETRACHTUNG..........................................1518.1 Anmerkungen zum Nutzen des neuen Systems........................................151

8.1.1 Qualitative Verbesserungen................................................................1528.1.2 Quantitativ meßbare Verbesserungen................................................153

8.1.2.1 Studien- und Prüfungsabteilung....................................................1558.1.2.2 Institute/Abteilungen....................................................................157

8.2 Kosten-/Nutzenrechnung..........................................................................162

Anhang A: VerzeichnisseAnhang B: DatenfelderAnhang C: ARIS-Datenbank/Modell-ListeAnhang D: ARIS-Datenbank/wichtigste ModelleAnhang E: ARIS-Datenbank/AuswertungenAnhang F: Wirtschaftlichkeitsbetrachtungen (ZID)


Grobkonzept Projekt

1 EINLEITUNG

1.1 AuftragAm 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 vereinbarten 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 WarenzeichenDie Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenzeichen u.s.w. in diesem 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.


3 METHODIK UND VORGEHEN3.1 Die Phasen der Konzeption

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 keinem Fall der Gleichbehandlungsgrundsatz, so wie er im UOG ’93 oder auch in der Satzung der Wirtschaftsuniversität Wien (WU Wien) formuliert wird, untergraben werden.


Grobkonzept Projekt

2 PROJEKTDURCHFÜHRUNG

2.1 Ziele des ProjektsZiel des Projekts war die Erstellung einer detaillierten Sollspezifikation auf Basis des Grobkonzepts, das unter Federführung des Zentrums für Informatikdienste der Wirtschaftsuniversität Wien erstellt wurde.

Die Sollspezifikation soll der WU einerseits Entscheidungsgrundlagen über eine schrittweise Implementierung des Systems liefern, andererseits als Leistungsverzeichnis 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 Transparenz 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 netzwerkartigen 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 Anforderungen der Interviewpartner und Workshopteilnehmer in dem in den Bericht integrierten Anforderungskatalog.

Die bei der Wirtschaftsuniversität Wien vorgefundene Ausgangssituation sowie das vom „2gether“-Projekt erwartete Verbesserungspotential ist in Abbildung 1 festgehalten.



Abbildung 1: Ist-Situation und Ziele des Projektes „2gether“

Des weiteren waren folgende Aspekte des Studien- und Prüfungsverwaltung zu berücksichtigen:


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 ProjektpartnerDie Durchführung des Projekts wurde der Firma Secur-Data Betriebsberatungsgesellschaft m.b.H. übertragen, die vornehmlich ihre (auf die Abwicklung komplexer IT-Projekte bezogene) Management-Kompetenz einbrachte, sich jedoch der Modellierungskompetenz des ARIS-Herstellers IDS Prof. Scheer GmbH bediente, der als Subunternehmen beigezogen wurde. Der vorliegende Bericht ist das Produkt dieser engen Partnerschaft sowie der engen Zusammenarbeit mit allen involvierten Stellen der Wirtschaftsuniversität, für deren engagiertes Mitwirken wir an dieser Stelle herzlichen Dank sagen wollen.



Abbildung 3: Partner im Projekt „2gether“

2.3 ProjektorganisationDie Aufbauorganisation des Projekts ist in Abbildung 4 dargestellt.


Grobkonzept Projekt

Abbildung 4: Projektaufbauorganisation

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. Hansen (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 KernteamZur 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 KernteamsDas Kick-off-Meeting des Kernteams fand am 18. November 1997 statt. In weiterer Folge wurden insgesamt 13 Sitzungen des Kernteams mit wechselnder Beteiligung abgehalten.

2.4.2 Sitzungen des LenkungsausschussesDer 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 Lenkungsausschuß zu seiner 5. und letzten Sitzung am 30. April 1998 zusammentreten.

2.4.3 Einbezogene Organisationseinheiten

2.4.3.1 Einbezogene Institute/AbteilungenIm 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 beschlossen, 6 weitere Institute bzw. Abteilungen in die Erhebungs- bzw. Abstimmungsgespräche einzubeziehen. Folgende Institute bzw. Abteilungen wurden ausgewählt:

Englische Sprache/Wirtschaftssprache



Finanzierung & Finanzmärkte Betriebswirtschaftliche Steuerlehre 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 StellenNeben 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 beschlossen, 2 weitere Verwaltungs- bzw. sonstige Stellen verstärkt einzubeziehen:

Hochschülerschaft Zentrum für Auslandsstudien

2.4.3.3 Übersicht über die Interview- und AbstimmungstermineIm Rahmen der Projektdurchführung wurden folgende Interview- und Abstimmungstermine wahrgenommen:

Datum Stelle Interviewpartner26.11.1997

Romanische Sprachen

I. Hubmann, E. Lavric, N. Riehs


Grobkonzept Projekt

Datum Stelle Interviewpartner3.12.1997 Wirtschafts-

informatikM. Fritscher, C. Drimmel, O. Kump

3.12.1997 Wirtschafts-informatik

A. Schüller, M. Kaukal


R. Flatscher, R. Brandtweiner


M. Fritscher


A. Schuster


A. Scharl

4.12.1997 ZID R. Barthauer, J. Langitz4.12.1997 Wirtschafts-

informatikO. Kump, C. Ragacs

9.12.1997 Warenhandel T. Reutterer9.12.1997 Romanische

SprachenI. Hubmann, E. Lavric, N. Riehs


R. Flatscher

10.12.1997

Wirtschafts-informatik

O. Kump

10.12.1997

Wirtschafts-informatik

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



Datum Stelle Interviewpartner18.12.1997

STAB W. Axterer, M. De Pellegrin

18.12.1997

Büro d. Studiendekane

G. Zihr

8.1.1998 Warenhandel H. Kotzab12.1.1998 Bürgerliches Recht W. Martetschläger13.1.1998 ÖH P. Hysek14.1.1998 Büro d.

StudiendekaneH. Gabler, Prof P. Hackl (tw.), G. Sedlacek

27.1.1998 Quästur G. Krotky28.1.1998 Zentrum für

AuslandsstudienF. Brück, T. Friedlmayer

29.1.1998 ÖH S. Schmidt22.1.1998 ZID J. Loibl10.2.1998 Rechts- und

Organisationsabteilung

G. Mautner

11.2.1998 ZID J. Loibl24.2.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer26.2.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer3.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer4.3.1998 Quästur; Rechts-

und Organisationsabteilung

G. Krotky; G. Mautner

4.3.1998 Rechts- und Organisationsabteilung

D. Pouha

4.3.1998 Bürgerliches Recht W. Martetschläger5.3.1998 Warenhandel H. Kotzab5.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer10.3.1998 ÖH Hysek10.3.1998 Englische Sprache Prof. W. Obenaus, D. Schleihs10.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer10.3.1998 Politische Ökonomie H. Klausinger


Grobkonzept Projekt

Datum Stelle Interviewpartner12.3.1998 Wirtschafts- und

SozialgeschichteG. Senft

12.3.1998 Romanische Sprachen

E. Lavric, N. Riehs, I. Hubmann

12.3.1998 STAB W. Axterer, M. De Pellegrin, H. Spitzer16.3.1998 ZID B. Sommer17.3.1998 Studiendekanat G. Zihr17.3.1998 Studiendekanat G. Sedlacek17.3.1998 Dienststellenaussch

ußR. Pieler

18.3.1998 Personalwirtschaft G. Lueger18.3.1998 Betriebswirtschaftlic

he SteuerlehreF. Hörmann

18.3.1998 Wirtschaftsinformatik

O. Kump, A. Schuster


R. G. Flatscher, M. Kaukal, R. Klimesch


S. Feregyhazy, C. Drimmel


M. Fritscher

19.3.1998 Wirtschafts- und Sozialgeschichte

G. Senft, S. Wolf, B. Bauer, R. Lackner, H. Hemetsberger-Koller

19.3.1998 Bürgerliches Recht W. Blocher, W. Martetschläger24.3.1998 Warenhandel H. Kotzab, B. Gasner24.3.1998 Personalwirtschaft Prof. D. Eckardstein, H. Mayerhofer, G. Riedl , G.

Lueger u. a.24.3.1998 Romanische

SprachenE. Lavric, N. Riehs, I. Hubmann

24.3.1998 Finanzierung und Finanzmärkte

S. Schmidt, H. Pichler, P. Hysek

25.3.1998 Betriebswirtschafltiche Steuerlehre

F. Hörmann

25.3.1998 ZAS A. M. Schator, K. Zollner25.3.1998 Studiendekanat H. Haller



Datum Stelle Interviewpartner26.3.1998 Politische Ökonomie Prof. J. H. Pichler, C. Ragacs, S. Holzweber, H.

Klausinger26.3.1998 Englische Sprache Prof. W. Obenaus, R. Markwitz, K. Wenschitz, D.

Schleihs1.4.1998 Wirtschaftsinformati

kO. Kump, A. Schuster

1.4.1998 Personalwirtschaft Prof. D. Eckardstein, H. Mayerhofer, G. Riedl1.4.1998 ADV-Abteilung R. Barthauer2.4.1998 STAB H. Spitzer, Svaljug, Szalay2.4.1998 STAB H. Spitzer, Nagy, Vario2.4.1998 Finanzierung; ÖH S. Schmidt, P. Hysek7.4.1998 ADV-Abteilung R. Barthauer8.4.1998 ZID G. Miksch

Tabelle 1: Interviews und Abstimmungsgespräche

2.4.4 Präsentationen und WorkshopsAm 11. Dezember 1997 wurde eine Präsentation des Projektes durchgeführt, zu der alle 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 beschlossen, 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:

Datum Stelle Interviewpartner30.3.1998 Gewerbe, Klein- und Mittelbetriebe B. Mahel30.3.1998 Arbeit und Sozialrecht C. Münster30.3.1998 Angewandte Informatik R. Franz30.3.1998 Rektorat: Forschungsservice B. Moravec30.3.1998 Finanzwissenschaft S. Brunner30.3.1998 Verfassungs- und Verwaltungsrecht H. Beclin


Grobkonzept Projekt

Datum Stelle Interviewpartner31.3.1998 Industrielle Informationsverarbeitung A. Prosser31.3.1998 Genossenschaftswesen;

StudiendekanatG. Zihr

31.3.1998 Angewandte Informatik; Wirtschaftsstatistik; Studiendekanat

G. Sedlacek

31.3.1998 Studiendekanat H. Gabler31.3.1998 Rechts- und Organisationsabteilung G. Mautner, D. Pouha, A.

Melcsok, H. Gelegs1.4.1998 Raumordnung G. Maier1.4.1998 Außenhandel Y. Fuchs1.4.1998 Organisation und Materialwirtschaft E. Chwosta2.4.1998 Finanzrecht M. Zueger2.4.1998 FBK Rechtswissenschaft I. Berger2.4.1998 Tourismus G. Ullrich

Tabelle 2: Workshops – Termine und Teilnehmer

2.4.5 PlakataktionDie 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 KonzeptionDas 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 detaillieren.

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ätsprozesse“ genannt, gelegt. Ein solcher Universitätsprozeß mit seinen verschiedenen Instanzen 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 ausführlich ausmodellierter ARIS-Modelle.



Daher fokussiert dieser Bericht nahezu ausschließlich auf die Soll-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 erreichen und gleichzeitig eine hohe Wiederverwendbarkeit der Projektergebnisse sicherzustellen, wird im Projekt durchgängig ein computergestütztes Werkzeug - das ARIS-Toolset - eingesetzt.

In allen Phasen des Projektes wurden daher die Interviewergebnisse sowie die Erkenntnisse 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 entsprechenden Kapitel des Anhangs.


Grobkonzept Projekt

Aufgaben- und Tätigkeitsanalyse Controlling VCAnzahl der Mitarbeiter nach Köpfen:

7

Personalkapazität in Mannjahren: 7,00Stunden pro Mannjahr: 1582Arbeitstage pro Jahr: 210Hauptaufgabe Aufgaben

Minim

ale D

FZ (

in h)

für

die e

inmalig

e Du

rchf

ühru

ngM

axim

ale D

FZ (

in h)

für

die e

inmalig

e Du

rchf

ühru

ngG

ewich

tete

, m

ittler

e DF

Z(in

h)

für

die e

in-m

alige

Durc

hfüh

rung

Men

ge p

.a.

Anza

hl de

r be

teiligt

enM

itarb

eiter

an

der

Teilau

fgab

e%

-Ant

eile d

er D

FZ(m

in) a

n M

enge

p.a

.

%-A

nteile

der

DFZ

(max

) an

Men

ge p

.a.

Ges

amta

ufwa

nd(in

h)

p.a.

Teila

ufga

be

Ges

amta

ufwa

nd(in

M

J) p

.a.

Teilau

fgab

e

Ges

amta

ufwa

nd(in

h)

p.a.

Hau

ptau

fgab

eG

esam

tauf

wand

(in M

J) p

.a.

Haup

tauf

gabe

%-A

nteil

der

Teil-

aufg

abe

an

Haup

tauf

gabe

%-A

nteil

der

Haup

tauf

-ga

be a

m

Ges

amta

ufwa

nd

Unternehmenspla-nung (kf., mf., lf.) 1782,2 1,12655 13,72%

Wirtschaftlichkeit einzelner Projekte berechnen 1,52 7,6 4,56 20 50% 50% 91,2 0,0576 5%Haushaltsplan aufstellen u. bearbeiten 1178 1254 1216 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 19 13,3 4 50% 50% 53,2 0,0336 6%

Aufgaben- und Tätigkeitsanalyse Controlling VCAnzahl der Mitarbeiter nach Köpfen:

7Personalkapazität in Mannjahren: 7,00Stunden pro Mannjahr: 1582

Arbeitstage pro Jahr: 210Hauptaufgabe Aufgaben

Minim

ale D

FZ (

in h)

für

die e

inmalig

e Du

rchf

ühru

ngM

axim

ale D

FZ (

in h)

für

die e

inmalig

e Du

rchf

ühru

ngG

ewich

tete

, m

ittler

e DF

Z(in

h)

für

die e

in-m

alige

Durc

hfüh

rung

Men

ge p

.a.

Anza

hl de

r be

teiligt

enM

itarb

eiter

an

der

Teilau

fgab

e%

-Ant

eile d

er D

FZ(m

in) a

n M

enge

p.a

.

%-A

nteile

der

DFZ

(max

) an

Men

ge p

.a.

Ges

amta

ufwa

nd(in

h)

p.a.

Teila

ufga

be

Ges

amta

ufwa

nd(in

M

J) p

.a.

Teilau

fgab

e

Ges

amta

ufwa

nd(in

h)

p.a.

Hau

ptau

fgab

eG

esam

tauf

wand

(in M

J) p

.a.

Haup

tauf

gabe

%-A

nteil

der

Teil-

aufg

abe

an

Haup

tauf

gabe

%-A

nteil

der

Haup

tauf

-ga

be a

m

Ges

amta

ufwa

nd

Unternehmenspla-nung (kf., mf., lf.) 1782,2 1,12655 13,72%

Wirtschaftlichkeit einzelner Projekte berechnen 1,52 7,6 4,56 20 50% 50% 91,2 0,0576 5%Haushaltsplan aufstellen u. bearbeiten 1178 1254 1216 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 19 13,3 4 50% 50% 53,2 0,0336 6%

Instand-haltungs-summeermitteln

Instandhaltungs-summe

istermittelt

Instand-haltungssumme

mitU-planung abgleichen

XOR

XOR

Instandhaltungs-summe istungleich

U-planung

Instandhaltungs-aufwandkürzen

Instandhaltungs-aufwand ist

ermittelt

Instandhaltungs-summe istzu planen

Thema: Neugestaltung der Budgetp lanung und -abwicklung

Rahmenbedingung:

Budget pro KC nach Kennzahlen

Quantitative Verbesserungen:

Abstimmungsgespräche in BST mit

Planungsingenieur (Bewertung der Pro jekte) entfällt

DV-Eingabe der Planungswerte und

Projekteinrichtung in HV entfäll t

Bewertung der HHP-Projekte nach

Planungsrichtlinien in der HV entfällt

Abstimmungsgespräche der Grobplanung im KC mit

KC-Leiter u. Fachbereichen wird reduziert

Budgetgenehm igung und F reigabe an KC wird

reduziert

Manuelle Einkaufsdisposition entfäl lt

Geringeres Volumen der gedruckten Pläne u. des

Erste llungsaufwandes (HHP)

Vereinfachte Materialbestellung und

Aufmaßerstellung mit anschließender

Rechnungserstellung der Baufi rmen

Vereinfachte DV-Erstellung und Fortführung der

Netzp läne in KC

Weniger Pro jektänderungsdienst

Vereinfachte Lohnaufschreibung

Synergieeffekt durch hohe Transparenz und Zugriff

der MA auf gle iche, aktuelle Infos

Abbau dezentraler Control lingtätigkeiten durch

zielgerichtete, qualitative Planungsunterstützung

Thema: Neugestaltung der Budgetp lanung und -abwicklung

Rahmenbedingung:

Budget pro KC nach Kennzahlen

Quantitative Verbesserungen:

Abstimmungsgespräche in BST mit

Planungsingenieur (Bewertung der Pro jekte) entfällt

DV-Eingabe der Planungswerte und

Projekteinrichtung in HV entfäll t

Bewertung der HHP-Projekte nach

Planungsrichtlinien in der HV entfällt

Abstimmungsgespräche der Grobplanung im KC mit

KC-Leiter u. Fachbereichen wird reduziert

Budgetgenehm igung und F reigabe an KC wird

reduziert

Manuelle Einkaufsdisposition entfäl lt







Netzp läne in KC







Grobkonzept‘2gether’

‘Sinz-Studie’ etc.

GraphischeOrganisations-

modelle Reports







Netzp läne in KC







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 InformationssystemeDas ARIS-Toolset ist ein DV-gestütztes Beratungswerkzeug auf Datenbankbasis, insbesondere für folgende Fragestellungen:

Analyse- und Optimierung organisatorischer Abläufe, Geschäfts- bzw. Universitätsprozesse;

Erstellung fachlicher und organisatorischer Sollkonzepte; Erstellung von IV-Strategien und IV-Bebauungsplänen; Einführung von Software, insbesondere Standardsoftware.



Das von der IDS Prof. Scheer GmbH entwickelte ARIS-Toolset ist ein wissenschaftlich fundiertes und in vielen Projekten erprobtes Modellierungs-Werkzeug, welches inzwischen im Bereich der Werkzeuge zur Geschäftsprozeßoptimierung weltweit marktführend ist.

3.2.1 Hintergrund und IdeeWissenschaftliche Grundlage für das Werkzeug ist die Architektur integrierter Informationssysteme (ARIS), ein Methodenrahmen zur Unternehmensmodellierung, der am Institut 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. Diagrammtypen zum Einsatz.

Die Zerlegung des Gesamtsystems erfolgt nach Sichten und Ebenen (vgl. Abbildung 8):


Grobkonzept Projekt

Abbildung 8: Das ARIS-Haus im Gesamtüberblick

3.2.2 Die ARIS-EbenenBei der Unternehmensmodellierung treffen in den Projekten oftmals Mitarbeiter unterschiedlicher Fachrichtungen aufeinander. Dies ist beispielsweise immer dann der Fall, wenn zum Zwecke der Anwendungssystementwicklung Entwickler und Sachbearbeiter zusammenarbeiten. Jede Richtung hat dabei ihren eigene Sprachgebrauch: die Sachbearbeiter reden in fachlichen Termini, während die Entwickler dv-bezogene Ausdrücke und Begriffe verwenden. Dies macht die Verwendung jeweils spezifischer Beschreibungsmethoden naheliegend. ARIS bietet daher Modelltypen in drei verschiedenen Ebenen, die sich durch ihre Nähe einerseits zur fachlichen Seite, andererseits zur implementierungsnahen 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 Fachkonzeptes 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 Fachkonzeptebene beziehen. Grundsätzlich erstreckt sich die im nächsten Abschnitt beschriebene Sichtenbildung natürlich auf alle Ebenen des ARIS-Hauses (Literaturhinweis: [Scheer95|98]).

3.2.3 Die ARIS-SichtenEin weiterer wesentlicher Aspekt der ARIS-Methode ist die Verwendung von vier verschiedenen 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 Organisationseinheiten wie Fachbereichen, Abteilungen oder auch Stellen beschreiben und definiert werden (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 definiert, die in den anderen Modellen verwendet werden können.

In der Funktionssicht wird die statische, hierarchische funktionale Struktur einer Institution 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. Verwendung 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 (statische) Struktur der im Untersuchungsbereich verwendeten Nutzendaten beschrieben. Die Beschreibung der Datenstruktur ist in erster Linie für Projekte im Bereich Anwendungssystementwicklung vonnöten, da aus ihr das notwendige Datenbankschema abgeleitet oder gar (mit Hilfe eines CASE-Tools) generiert werden kann. Bekanntester Modelltyp ist dabei das seit den 70er Jahren verbreitete Entity-Relationship-Modell.

Dieser Modelltyp bildet unter anderem einen Schwerpunkt dieses Projektes. Dabei werden die Datenstrukturen beschrieben, so wie sie im Bereich der Studien- und Prüfungsverwaltung 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. Kardinalitäten eingeführt. Diese beschreiben, wie oft ein Entitytyp in einer Beziehung erscheinen kann. So bedeutet „cn“ beispielsweise, daß der Enti-tytyp keinmal bis beliebig oft in der entsprechenden Beziehung existieren kann.

Darüber hinaus können Beziehungstypen zur Konstruktion eines neuen Objektes, welches 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


Grobkonzept Projekt

diese uminterpretierten Beziehungstypen durch ein um die Raute gelegtes Rechteck dargestellt.

Schließlich sei als wichtiges logisches Mittel noch die Generalisierung/Spe-zialisierung erwähnt. Diese Beziehung, dargestellt in Form eines Dreiecks, beschreibt die hierarchische 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 Zusammenfassung von Attributen, sprich Datenfeldern, welche aus Gründen der Übersichtlichkeit in dieser Arbeit in einer EXCEL-Tabelle erfaßt werden.

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 Aufzeigung der organisatorischen Konsequenzen, die mit



der Einführung eines neuen Anwendungssystems verbunden sind. Im Gegensatz zu den rein statischen Beschreibungen der anderen Sichten werden hier - unter Verwendung der in eben diesen Sichten definierten Organisationseinheiten, Funktionen und auch Anwendungssysteme - Prozesse in ihrer dynamischen Folge dargestellt. Wesentlicher Modelltyp ist die Ereignisgesteuerte Prozeßkette (EPK), wie sie beispielhaft in Abbildung13 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 Ereignisses - löst


Grobkonzept Projekt

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 lassen sich in der EPK auch die mit den einzelnen Tätigkeiten verbundenen Informationsobjekte wie Stellen, Dokumente (Informationsträger), Daten oder Anwendungssysteme aber auch beispielsweise externe Beteiligte etc. darstellen.

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

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 ModellierungDie Grundsätze ordnungsmäßiger Modellierung (GoM) schaffen in begrifflicher Anlehnung 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 Unter-nehmensmodellierung - zu der ja auch die Geschäftsprozeßmodellierung gehört - durchgeführt wird.

Dabei schaffen sie einerseits ein theoretisches Fundament für die Beschreibungsmethoden als solche (‘Meta-Ebene’), andererseits werden aber auch Richtlinien für die eigentliche 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ß „lediglich“ 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 er-scheint aber jedoch auch als ausreichend.



Zur Realisierung der GoM’s in einem GPO-Projekt unter Einsatz eines Modellierungswerkzeugs stellen sich damit konkret folgende Fragen der:

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,


Grobkonzept Projekt

der inhaltlichen Vorgehensweise in der Modellierung, 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 folgenden Abschnitten eingegangen. Insbesondere letztere sind wertvoll zum Verständnis der Modelle und somit letztlich auch zur sinnvollen Weiterverwendung des Erarbeiteten.



3.4 Projekt-/ModellierungskonventionenAn 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 Konventionen, die nur durch Modellierungsdisziplin und manuelle Qualitätssicherung zu realisieren 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“ Konventionen), zur Verwendung von Objekttypen oder bspw. zur Verwendung von Ausprägungskopien etc.

3.4.1 Verwendung aufbauorganisatorischer ElementeZur leichteren Lesbarkeit und Erhöhung der Allgemeingültigkeit wird auf die explizite Verwendung einzelner Instituts- oder Abteilungsbezeichnungen aus den Fachbereichen verzichtet. Statt dessen wird in den Prozeßmodellen das Objekt „Institut/Abteilung" verwendet zum Verweis auf die jeweils betroffenen Organisationseinheit. Dies wird durch die unsymmetrische Struktur der Fachbereiche - Aufgliederung in Institute und/oder Abteilungen - an der WU Wien erforderlich und fördert zudem die allgemeine, übergreifende Verwendung der Ergebnisse.

Entsprechend gilt Analoges für die jeweiligen Leiter/-innen der betreffenden Organisationseinheit.

3.4.2 Aufbau der Modellhierarchie

3.4.2.1 Ablaufbeschreibung versus FunktionalitätsbeschreibungEs 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 Teilaspekte im weitesten


Grobkonzept Projekt

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 Funktionszuordnungsdiagramme, die jeweils den sog. „Level-1-Funktionen“ hinterlegt werden und die sowohl die organisatorische Zuordnung als auch die systemseitige Unterstützung der beschriebenen Funktionalität definieren.

3.4.2.2 Bildung von SzenarienErfordert die Beschreibung der Funktionalitäten, respektive Abläufe, die Bildung von Varianten, sogenannten „Szenarien“, dann erfolgt dies über das Instrument der Prozeß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ätenEntsprechend des Zeitrahmens sowie insbesondere den Zielen dieses Projektes (nämlich eine Ausschreibungsgrundlage zu erzeugen), erfolgt die Spezifikation lesender oder schreibender Datenzugriffe durch Funktionen mit Hilfe von Funktionszuordnungsdiagrammen auf Prozeß- und Clusterebene. Entsprechend wird auf die Zuordnung detaillierter Datenobjekte oder gar -felder zu einzelnen Funktionalitäten verzichtet.

3.4.3 DetaillierungsgradDer 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 DatenmodelleDie 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 Da-tenfelder.



3.4.3.2 ProzeßmodelleDer 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 Prozeßabläufen teilweise als optional einzuordnen sind.

3.4.4 Übersicht der MethodenverwendungIn den folgenden tabellarischen Übersichten werden die im Projekt verwendeten Modell-, Objekt- und Attributtypen beschrieben. Dabei wird spezifiziert, ob es sich jeweils um einen 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ß BeispielOrganigramm X Organigramm WU WienEEPK X Planung von LehrveranstaltungenProzeßauswahlmatrix X An- und AbmeldungEERM X LehrveranstaltungFunktionszuordnungsdiagramm

X Abrechnung

Funktionsbaum X PrüfungsanmeldungTabelle 3: Modelltypverwendung


Grobkonzept Projekt

Modelltyp Objekt-/Symboltyp Kann Muß BeispieleEPK Ereignis X „VVZ ist erstellt“

Funktion X „VVZ drucken“Prozeßwegweiser XPersonentyp X Student/-in (im Sinne

einer Rolle)(externe) Person X DruckereiOrganisationseinheit (-styp)

X Institut

Anwendungssystem (-typ) X ‘2gether’Regel X ‘und’, ‘oder’, ‘exkl. oder’Prozeßwegweiser X folgender ProzeßDokument X BeauftragungsbescheidDatei X VVZ

FZD1 Funktion X AbrechnungPersonentyp X Student/-in (im Sinne

einer Rolle)Organisationseinheit (-styp)

X Institut

Anwendungssystem (-typ) X 2getherCluster X Lehrveranstaltung

Funktionsbaum

Funktion X Chipkarten personalisieren

Organigramm Organisationseinheit (-styp)

X STAB, Institut

Prozeßauswahlmatrix

Szenario X Lehrveranstaltungsan- und -abmeldung

Hauptprozeß X EinzelanmeldungenProzeß X Lehrveranstaltungsanm

eldung eERM Entitytyp X Student/-in

Beziehungstyp X Reservierung; (Terminliste) gibt

1 Funktionszuordnungsdiagramm



Modelltyp Objekt-/Symboltyp Kann Muß BeispielVorlagetermin für (Anerkennungsantrag)

Uminterpretierter Beziehungstyp

X LV-Anmeldung

Generalisierung/ Spezialisierung

X (WU-Angehöriger) kann sein (wiss. MA)

Tabelle 4: Modell-/Objekttypzuordnung

Objekt-/Sym-boltyp Attributtyp Kann Muß Inhalt

<alle> Name X2 --Identifizierer X Ids1.4711Langbezeichnung X Name ohne AbkürzungenBemerkung/Beispiel X ZusatzinfoBeschreibung/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 Funktionsbaum

Bearbeitungsart/auto-dezentral

X Automatisch, dezentral von ‘2gether’ durchgeführte Funktion

Bearbeitungsart/auto-zentral

X Automatisch, zentral von ‘2gether’ durchgeführte Funktion

Hauptprozeß Bearbeitungskennzeichen

X „*“ als Hinweis auf WORD-Hinterlegung

Systemattribute/Extern i

X Verweis auf WORD-Hin-terlegung

Informations- --2 außer ‘Generalisierung/Spezialisierung’


Grobkonzept Projekt

Objekt-/Sym-boltyp Attributtyp Kann Muß Inhalt

trägerOrganisations-einheit

--

Organisations-einheitstyp

--

(externe) Person

--

Personentyp --Anwendungs-systemtyp

--

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 disjunkt‘n’: vollständig, nicht dis-junkt

Regel --Entitytyp Beschreibung/

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



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

- und

Org

anis

atio

ns-

abte

ilung

Per

sona

l-ab

teilu

ngS

tudi

en- u

ndP

rüfu

ngsa

btei

lung

(STA

B)

Wirt

scha

ftsab

tei-

lung

und

Abt

eilu

ngfü

r Geb

äude

und

Tech

nik

Quä

stur

Vol

ksw

irt-

scha

fts-

lehr

eR

echt

swis

sen-

scha

ftG

eist

es- u

ndFo

rmal

-w

isse

nsch

aft

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 93Seite 46 von 171 Erstellt gemeinsam mit 15. April 1998

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, Lehrveranstaltungen, 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 Chipkartenverwaltung, die dem Kapitel „allgemeine Funktionen“ zugeordnet wurden. Bei den anderen Themengebieten wurden Prozeßketten (eEPK) und Funktionsbäume modelliert, um die künftige Ablaufbeschreibung detaillierter und transparenter zu machen und damit die Akzeptanz der potentiellen Benutzer zu erhöhen. Das Kapitel „Sonstige Funktionen“ (Kapitel 5.10 Grobkonzept), wurde in „Allgemeine Funktionen“ umbenannt.

In jedem Themenabschnitt, wie z.B. „Lehrveranstaltungen“, findet man das Übersichtsmodell (Prozeßauswahlmatrix oder Funktionsbaum) abgebildet mit Erläuterungen. In allen Unterabschnitten, wie z.B. „Planung von Lehrveranstaltungen“, werden Funktionszuordnungsdiagramme 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. „Planung 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 wesentlicher 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 allen 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 Funktionsbä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 besonders allen Teilnehmern für ihre engagierte Mitarbeit danken.

Auf Ergebnisse des Grobkonzepts, das als Anhang vorliegt, wird im folgenden des öfteren 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 des

StudiumsP*

BeendigungStudium

P*

P


P


*

* P


Studiums

P*

BeendigungStudium


P


P*Zusatzstudium/Wechsel des

StudiumsP*

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. Dateneingaben werden z.B. über Internet möglich sein, Bezahlungen und Rückmeldungen mit der Studentenausweis-Chipkarte oder auch über Internet, Studienwechsel können systemunterstützt direkt vom Studenten durchgeführt werden. Bei der Beendigung des Studiums werden Folgeaktivitäten automatisch angestoßen. Wichtig ist ein Umdenkungsprozeß der Studenten, daß Termine mit der STAB einzuhalten und zu vereinbaren sind – letztendlich zum Wohl aller, da dann ein schnellerer reibungsloser Ablauf garantiert 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 Zulassungsantrag 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 Zahlung eines Kostenbeitrages (ÖH-Beitrag) verbinden. Die Zulassungsprozedur sieht daher die Integration von Kreditkartenzahlungen bei der Einwahl über Internet oder Quick-Card-Bezahlung bei Zugriff über WU-eigene Terminals vor. Sollte dies Probleme bereiten, 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 Systemeinfü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 (Austauschstudenten) ein von der ZAS geforderter Service. Sollte die Zulassung nicht innerhalb einer festgesetzten Frist erteilt werden, erlöschen diese Anmeldungen.


Grobkonzept Projekt

Nach Erteilung der Zulassung am Schalter wird von der STAB eine Chipkarte als Studentenausweis ausgegeben, die neben der Legitimationsfunktionalität auch Zahlungsfunktionen 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 (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. Zulassungsvoraussetzungen und mit besonderen Zulassungsvoraussetzungen, wobei letztere Rahmenbedingung die Integration der StabDat in das neue System erfordert mit umfangreichen Drag- und Drop-Funktionalitäten und Layout-Gestaltungsmaßnahmen. Weitere 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 Studienkommissionen 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 Kapazitä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 systemunterstützt möglich sein.

STAB: Groupware-Funktionalitäten beschleunigen Genehmigungsverfahren bei ind. Diplomstudiengängen und Studienberechtigungsprüfungen.

STAB: Prüfungsbescheid mit Fächern wird automatisiert erstellt.

STAB: Analysen bzgl. Studienberechtigungsprüfungen können aus dem System abgerufen 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. Fachhochschulabsolventen 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 Terminierung 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 Anfangsphase).STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitarbeiterumschulung.STAB: digitale Lichtbilder müssen angefertigt werden.

ZID

Plus kein Druck der Zulassungsunterlagen nötig (Studienblatt, Semesteretikett, Zahlschein etc.)

Studierende


Grobkonzept Projekt


Plus Schnellere ZulassungFernzulassungsantrag möglichSchnellere Bearbeitungszeit am SchalterDurch Terminierung geringere Wartezeit vor dem SchalterMehr Zahlungsmöglichkeiten durch ChipkarteÖH: automatische Rückerstattung des ÖH-Beitrags bei zurückgewiesenen Studenten

Minus

Daten zur Zulassung müssen selbst in ‘2gether’ eingetragen werdenZusä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 Zahlschein)

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 beschrieben; 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 Ausnahme 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 Studenten. Sowohl Rückmeldungen ohne Bezahlung des ÖH-Beitrags (bei Zulassung an anderen 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 Zahlschein mit Scancode)STAB: Rückmeldung und Bezahlung des ÖH-Beitrags in den meisten Fällen ohne Schalterbetreuung der StudentenSTAB: automatische Ermahnung wird an Studenten geschickt beim Erreichen des Rückmeldefristendes minus einer WocheSTAB: Rückmeldemerkmal wird auf Chipkarte automatisch gesetzt (Ansicht über „wallets“)

Minus

STAB: Betreuung der Studenten am Schalter nötig bei Rückmeldung über Internet (Chipkarteneintrag der Rückmeldung), falls automatischer Chipkarteneintrag fehlschlägt (wie heute über Reklamation zu lösen).

Studierende


Grobkonzept Projekt


Plus Rückmeldung ohne Zahlschein möglichFernrückmeldung möglich

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

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 Studenten geprüft und daraus die notwendigen Aktionen abgeleitet. Kann das System die entsprechenden Wünsche des Studenten nicht vollziehen, sollte eine Ablehnung angezeigt werden.




Nutzenpotential: Zusatzsturium/Wechsel des Studiums

Verwaltung

Plus STAB: Automatische Prüfmöglichkeit für Studenten durch das System, ob Studienwechsel 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).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“


Grobkonzept Projekt

Bemerkungen:In der Prozeßkette „Beendigung des Studiums“ (eEPK) kann man den gewünschten Ablauf zur Studienbeendigung verfolgen. Natürlich müssen bei Studienbeendigung Folgeaktivitäten angestoßen werden, die aufgrund der sehr dezentralen Verteilung idealerweise 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 Studenten gegeben sind. Auch werden einige Bescheide (Abgangsbescheide, Feststellungsbescheide) in Zukunft direkt vom Studenten am System ohne größeren Verwaltungsaufwand 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 Mengengerüst bearbeitet wird.

Die Prozeßkette „Beendigung des Sonderstudiums“ beschreibt die leicht geänderte Situation bei Studien mit Auflagen, Studien mit Studienberechtigungsprüfungen und individuellen 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 Generierung 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 Mitarbeiterumschulung.

Quästur

Plus Kontenabrechnung wird automatisch angestoßen und ausgeführt.

Studierende

Plus Abmeldungswunsch kann direkt am System erfolgen ohne Schalterkontakt.Fernabmeldung möglichkeine „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:


Grobkonzept Projekt

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 Ablaufunterstützung fordert, können bei der Verleihung des Doktortitels (ca. 100/a) auch Ad-hoc-Funktionalitäten des Systems zum Zuge kommen.

4.1.3 Lehrveranstaltungen

*

AdministrationLehrver-

anstaltung

*

Lehrver-anstaltungen

*

Planung vonLehrver-

anstaltungen

*

Aufnahme vonLehrver-

anstaltungen

*

Lehrver-anstaltungen

administrieren

Abbildung 24: Funktionsbaum „Lehrveranstaltung“

Bemerkungen:Geplant ist eine Einbindung aller LV-Leiter bei der Eingabe der Daten zur Lehrveranstaltung direkt in das System 2gether. Natürlich wird eine Akzeptanz kritisch von der Anwenderfreundlichkeit des Systems und von der Vertrautheit dem System gegenüber abhä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 einbeziehen zu können. Durch die tägliche Arbeit mit dem System ‘2gether’ über Groupwise-Funktionalitäten, wie Jobverwaltung, Terminplanung und E-Mail-



Verwaltung, und unterstü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 wiedergegeben.

Bei Planung einer Lehrveranstaltung im System sollte auf eine Datenbasis bereits abgehaltener Lehrveranstaltungen zurückgegriffen werden können. Eine „Revitalisierung“ dieser Lehrveranstaltungen kann dann jederzeit möglich sein; mitsamt der dazugehörigen Anmeldemodalitäten, Beschreibungen, Terminwünsche etc.. Auch eine Präferenzliste von Hörsälen und Terminen sollte bearbeitet werden, um eine möglichst optimale Zuordnung aller Hörsäle gewährleisten zu können.


Grobkonzept Projekt

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 Gewohnheiten 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-Organisationsabteilung Hörsäle getauscht werden können. Weitere Maßnahmen zur einer Verbesserung der Kapazitätsausnutzung wären eine Online-Einsicht in die aktuellen Daten der Hörsaalbelegung und ein Warnsystem bei großer Diskrepanz der Teilnehmer einer Lehrveranstaltung (natürlich auch bei Prüfungen) zu der Hörsaalkapazität - aufgrund 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 Servicestelle 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 Semester – 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 automatisch generierten Links zu den Internetseiten der Institute/Abteilungen. Somit wäre der Versorgung des Informationsbedarfs der Studenten bei Wartung der Daten im System 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, systemunterstü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 planungsrelevante Einträge im System – wie z.B. Anmeldefristen, max. Teilnehmerzahl, Anmeldemodalitäten – von den Instituten/Abteilungen durchgeführt werden, so daß Anmeldungen 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 Lehrveranstaltungsszenarien systemgeneriert durchgeführt werden kann, und so Institute, aber auch die Fachbereiche und das Studiendekanat schnell an wichtige Kontrolldaten gelangen 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 verwaltet 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.


Grobkonzept Projekt


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

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


Grobkonzept Projekt

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 Nichtaufnahme 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 Lehrveranstaltung erscheint sinnvoll im Hinblick auf spätere Planungsaktivitäten und einer automatischen 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 Bearbeiten 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 Studiendekanat) 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 Studiendekanat) fällt weg.

Verwaltung

Plus Rechts- und Organisationsabteilung: automatisch generierte E-Mail (Beauftragungsbescheide) an den LV-Leiter anstatt der Erstellung und Versendung der schriftlichen LV-Beginnmeldungen an die Institute (im Normalfall).Rechts- und Organisationsabteilung: automatische Selektion der nicht bearbeiteten LehrveranstaltungenRechts- und Organisationsabteilung: keine Einmahnungen an die InstituteRechts- und Organisationsabteilung: automatische Generation der


Grobkonzept Projekt

Nutzenpotential: Aufnahme von Lehrveranstaltungen

Benachrichtigung an den Studiendekan (nur Freigabe der automatisch generierten E-Mail)Rechts- und Organisationsabteilung: kein Anstoß zur Datenübernahme zwischen WUFIS und STEP nötigRechts- und Organisationsabteilung: kein Vergleich der LV-Beginnmeldungen und den Einträgen im STEP-System nötigRechts- 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-anstaltungenadministrieren

Lehrver-anstaltung

Institut/Abteilung

LV-Leiter/-in

Student/-in

Studien-dekanat

Abbildung 27: Funktionszuordnungsdiagramm „Administration Lehrveranstaltung“

Bemerkungen:



Aufgeführt in einem Funktionsbaum sind die wesentlichen Funktionalitäten, die ein zukü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; interessant wäre eine Tabellenstruktur, deren Köpfe entsprechend den Anforderungen etikettiert 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

PlanungPrüfungstermin

*

Prüfungen

*

Planung vonPrüfungen

*

Leistungs-feststellung

*

Abbildung 28: Funktionsbaum „Prüfung“

Bemerkungen:


Grobkonzept Projekt

Angestrebt wird, ein virtuelles Prüfungsamt im System abzubilden. Dazu sollten Tätigkeiten der Prüfungsreferate der STAB auf die systemunterstützte Mitarbeit der Studenten umgelegt werden. Hinzukommen sollte die Mitarbeit der Prüfer an den Abteilungen/Instituten, die die relevanten Daten direkt in das System eingeben.


4.1.4.1 Planung von Prüfungen

P*

Planung vonPrüfungen

LV-Leiter/-in

Büro desStudiendekans


(STAB)

Hörsaal-verwaltung

Prüfung

An- undAbmeldung

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 reserviert bekommen – bei der Absprache können Groupware-Eigenschaften des zukünftigen Systems eingesetzt werden.

Zur Unterstützung der Erstellung von Prüfungsunterlagen sollten Ausdrücke („Deckblätter“) aus dem System möglich sein mit den Personalien und den Terminen des Prüflings – 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 Dateneintrag über das WWW vorzusehen, um externe Prüfer miteinzubeziehen.


Nutzenpotential: Planung von Prüfungen

Institute/Mittelbau

Plus Hörsaalvergabe wird durch das System unterstützt (Groupware, Optimierungsalgorithmen)bei generierter Anmeldeliste Unterscheidung, ob mündliche oder schriftliche Prüfung erfolgen 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. Kapazitä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, Optimierungsalgorithmen). Anmeldelisten werden von den Studenten selbst gepflegt.

Verwaltung

Plus STAB: Hörsaalvergabe wird durch das System unterstützt (Groupware,


Grobkonzept Projekt

Nutzenpotential: Planung von Prüfungen

Optimierungsalgorithmen).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 umgeschrieben werden.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, Optimierungsalgorithmen).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

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 eine Liste der dem Prüfer im Semester zugeteilten Prüfungen wird per E-Mail automatisch an den Studenten die Benotung verschickt mit Angabe der vom Institut beschlossenen Einsichtsfrist (nicht zu verwechseln mit der rechtlichen Einsichtsfrist). Notenabfragen 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 angezeigten Daten sollte vom Prüfer leicht im System zu definieren sein (Anwählen von Tabellenkö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 Unterschrift 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. Zeugnisse sollten - soweit angestrebt - von den Studenten direkt vom System ausgedruckt werden mit maschineller Unterschrift (ausgenommen Diplomzeugnisse und Promotionszeugnisse).


Grobkonzept Projekt

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 Ausdrucke, Bestätigung und Unterschrift).


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überspielung 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 weiterzuleiten.

Verwaltung

Plus STAB: Daten der ausgefüllten Anmeldelisten/Prüfungsprotokolle brauchen nicht mehr in STEP eingetragen zu werden.



Nutzenpotential: Leistungsfeststellung

Minus

STAB: Schwerpunktverlagerung in beratungsspezifische Aufgabengebiete verlangt Mitarbeiterumschulung.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.

4.1.5 Diplomarbeiten/Dissertationen

Diplomarbeiten/Dissertationen

vereinbaren* FDiplomarbeiten/Dissertationen

betreuen* FDiplomarbeiten/Dissertationenabschließen

* P

Diplomarbeit/Dissertation

*


Grobkonzept Projekt

Abbildung 31: Funktionsbaum „Diplomarbeit/Dissertation“

Bemerkungen:Für die Administration der Diplomarbeiten und Dissertationen wird in ‘2gether’ eine eigene Datenbank eingerichtet mit den wesentlichen Informationen zu den Abschlußarbeiten, 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 Beendigung 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 werden.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 SystemZweitgutachter 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 (erweiterte Möglichkeiten durch das System verlangen aktuellere



Nutzenpotential: Diplomarbeiten/Dissertationen

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, Nationalbibliothek erfolgt nicht mehr durch STAB.STAB: Statistikformulare müssen nicht mehr administriert werden.STAB: Erfassungsblätter zur Arbeit („Abstracts“) müssen nicht mehr administriert werden.STEP: Rigorosum-Zeugnis, Diplomarbeitszeugnis wird aus dem System ‘2gether’ ausgedruckt - 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“).

Studierende

Plus Kein Besuch mehrerer Bearbeitungsstellen zum Erhalt des Sponsionsbescheids nötig.schnellere Bearbeitungszeit.Themendatenbank gibt guten Überblick über mögliche Arbeitsgebiete.


Grobkonzept Projekt

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 festgehalten, die bei der Vereinbarung von Diplomarbeiten und Dissertationen zum Einsatz kommen könnten.

Im Mittelpunkt steht die Themendatenbank, aus dem der Student, aber auch Interessenten 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 Institute/Abteilungen keine Pflicht, doch wäre es zum allgemeinen Überblick empfehlenswert 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 Institut/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 Promotion vom Studiendekan vorgeschlagen werden (meist in Absprache mit dem Institut).




4.1.5.2 Diplomarbeiten/Dissertationen betreuen

F*

Diplomarbeiten/Dissertationen

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 Diskussionsforums zur Arbeit sein, in der z.B. Literaturdateien, eine Linkliste im WWW zu themenverwandten Seiten oder auch verschiedene Versionen der Arbeit abgelegt werden würden.

Im Falle eines Betreuerwechsels durch den Studenten würden alle betreuenden Personen informiert, wodurch das Aufkommen von „Datenleichen“ vermindert werden könnte.


4.1.5.3 Diplomarbeiten/Dissertationen abschließen

P*

Diplomarbeiten/Dissertationenabschließen

Studiendekan/Vizestudiendekan

Betreuer/-in

Student/-inStudium


Abrechnung


Grobkonzept Projekt

Abbildung 34: Funktionszuordnungsdiagramm „Einreichung, Beurteilung und Veröffentlichung“

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 Dezentralitä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ühren“

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 verschiedene Ü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 Studienplanverwaltung im System, und das Negieren von Anmeldungen zu Parallellehrveranstaltungen; wobei auch Gruppen von Lehrveranstaltungen definiert werden können, in denen nur eine Anmeldung möglich ist. Natürlich muß ein solches Anmeldesystem auch 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 definierten Präferenzlisten etc.. Die Layout-Gestaltung der Anmeldemaske sollte institutsseitig/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


Grobkonzept Projekt

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ätze 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. Schwierig gestaltet es sich, die Abmeldung von den Lehrveranstaltungen zu urgieren, da ein Druck auf die Studenten aufgrund fehlender rechtlicher Mittel 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 Fehlentwicklungen 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üfungsanmeldungen systemunterstützt möglich sein. Zu beachten ist eine erhöhte Sicherheitsanforderung, da Anmeldung zu Prüfungen kritischer sein könnten (Sanktionierung bei Nichtantritten). 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überschreitungen 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 verfolgt 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 flexibel 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


Grobkonzept Projekt

automatisch generierte E-Mail-Verteiler für schnellen Informationsaustausch an die Studenten.

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

Minus

Anmeldemodalitäten müssen zumindest einmal festgelegt werden im System.


Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.Nachrücker werden vom System über Wartelisten automatisch berücksichtigt; Spätanmelder 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.



Nutzenpotential: Prüfungsanmeldungen

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).STAB: Keine Betreuung des Studenten zur Anmeldung nötig.STAB: Anmeldemodalitäten werden automatisch berücksichtigt (Präferenzeingaben, Kapazitätsauslastungen).STAB: Nachrücker und Wartelisten werden automatisch und institutsseitig administriert.STAB: Kapazitätsengpässe und Kapazitätsanalysen werden automatisch gemeldet.

Studiendekanat

Plus Kapazitätsengpässe und -analysen werden automatisch gemeldet.

Studierende

Plus Prüfung, ob Anmeldung erfolgen kann, erfolgt sofort online.Präferenzen zu LV können berücksichtigt werdenWartelisten werden erstellt - Nachrücker werden sofort per E-Mail verständigt.Prüfungstermine, Prüfer und Dauer werden per E-Mail sofort mitgeteilt.


Grobkonzept Projekt

4.1.6.3 Abmeldungen

F

Abmeldungen

Student/-in

An- undAbmeldung


(STAB)

Studien-dekanat

Prüfung

Fachbereich

Lehrver-anstaltung

Abbildung 38: Funktionszuordnungsdiagramm „Abmeldung durchführen“

Bemerkungen:In einem Funktionsbaum finden sich die wesentlichen Funktionen des Systems zur Unterstü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 gewartet 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ücksichtigt).




Nutzenpotential: Abmeldungen

Plus Nachrücker werden vom System über Wartelisten automatisch berücksichtigt; Spätanmelder 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 resultierende anmelderechtlichen Konsequenzen werden durch das System automatisch berü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.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.


Grobkonzept Projekt

4.1.7 Anerkennungen

An-erkennungen

*

P

Aner-kennungen

erzielen

P

Nostrifi-kationenerzielen

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 bekommen können.

Alle Anerkennungen von WU-internen Leistungen bei Aufnahme von Zusatzstudien und Wechsel des Studiums sollten automatisch durch das System gewährt werden; näheres 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 dokumentiert.

Verschiedene Verbesserungspotentiale ergeben sich bei Analyse der derzeitigen Situation: Zum Beispiel können Daten direkt in das System vom Studenten eingegeben werden, Terminvereinbarungen können im Vorfeld getroffen werden, Ergebnisinformationen den Antragstellern über E-Mail gegeben werden, und Teile der Schriftstücke in der Verwaltung schon aus den Daten vom System vorgeneriert werden.

Nutzenpotential: Anerkennungen erzielen

Verwaltung

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 Versenden von Schriftstücken eingeschränkt - z.B. Versendung an die Studienkommission zur Entscheidung, Versendung an Fachgutachter - und


Grobkonzept Projekt

Nutzenpotential: Anerkennungen erzielen

die Archivierung von Kopien in Papierform wird obsolet.STAB/Studienkommission: Anerkennungsbescheid wird vom Studenten am System ausgedruckt - 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 Studienkommission erfolgt systemunterstützt über E-Mail.STAB/Studienkommission: Terminvereinbarung mit Antragsteller zur Vorlage der Originaldokumente 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 BearbeitungszeitAnerkennungsbescheid kann direkt aus dem System ausgedruckt werden - keine Schalterbetreuung notwendig.



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 Gebiet Nostrifikationen durchzuführen sein.

In der Prozeßkette „Nostrifikationen erzielen“ wird dokumentiert, wie in Zukunft die Bearbeitung der Nostrifikation aussehen könnte. Verbesserungspotential liegt in der Information der beteiligten Stellen. In diesem Zusammenhang ist auch die Prozeßkette „Zulassung Studierende mit Nostrifikationsauflagen“ zu beachten, in der eine Zulassung zum Studium mit Auflagen zum Erlangen der Nostrifikation beschrieben wird.


Grobkonzept Projekt

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 Organisationsabteilung und der Quästur vorgenommen. Bei beiden Organisationseinheiten sind Anwendungssysteme 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 beschrieben, 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 fraglich 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 (zumindest die Personaldaten aus WUFIS) integrieren und Schnittstellen zu dem System „PIS“ aufzeigen - alle notwendigen Informationen zur Abrechnung liefern.


4.1.9 Evaluierung der Lehre

*

Beurteilungvon Lehrver-anstaltungen

P

*

Arbeitsberichte erstellen

F


*


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 Generation aller Berichtsteile, die auf Daten im System basieren, von den Instituten/Abteilungen ohne größere Umstände möglich sein.



Grobkonzept Projekt

Nutzenpotential: Evaluierung der Lehre

Institute/Mittelbau und Sekretariate

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öglich.Layout - Vorgabe der Arbeitsberichte möglich über 2gether.

Studierende

Plus Einheitliche Systemlandschaft bei Benutzung von ‘2gether’ zur Abgabe der Evaluierung.



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 notwendig, 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 Lehrveranstaltung auch angemeldet ist. In der beiliegenden Prozeßkette (eEPK) wird ein Evaluierungsszenario 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 Funktionalitäten in das System ‘2gether’ integriert werden.



Grobkonzept Projekt

4.1.9.2 Arbeitsberichte erstellen

F*

Arbeitsberichte erstellen

EvaluierungStudien-dekan

Studien-kommission

Institut/Abteilung

Abbildung 45: Funktionszuordnungsdiagramm „Arbeitsbericht Institutsvorstände“

Bemerkungen:Alle Funktionalitäten, die das System zur Unterstützung der Erstellung von Arbeitsberichten 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 einer darauffolgenden Verschickung an das Studiendekanat und die Studienkommissionen über das System.




4.1.10 Allgemeine Funktionen

allgemeineFunktionen

Stammdatenverwaltung

*

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 ChipkartenverwaltungDer 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 Diagramm grau hinterlegt.


Grobkonzept Projekt

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 diese – 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 geschrieben 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ögliche Sicherheit und Effizienz in der Handhabung gewährleistet. So fallen unnötige Transportwege sowie die unnötige Herausgabe WU-interner oder gar persönlicher Daten 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 Studien- und Prüfungsabteilung gehört.




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 Ansprechpartner 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 Abteilungen 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 StammdatenverwaltungDie Stammdatenverwaltung sollte je nach Datenbereich klar definierte Zuständigkeiten aufweisen.



Grobkonzept Projekt

4.1.10.4 Auswertungen/AusdruckeDie 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 werden. Datenexporte der Ergebnisse in verschiedenen Formaten sollten unterstützt werden.

Eine Übersicht wünschenswerter Abfragen und weitere Informationen enthält das Kapitel 5.10.2 des Grobkonzepts.



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“


Grobkonzept Projekt

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 Kapitel 6 verwiesen, das sehr anschaulich und umfangreich entsprechende Anforderungen auflistet.

Die Benutzerführung sollte intuitiv und einfach ablaufen und alle angesprochene Eingabemedien unterstützen (IVR, Internet etc.). Auch wurde bei den Interviews eine englische Sprachvariante als conditio sine qua non gefordert und eine französische als sinnvolle Erweiterung angesprochen (unabdingbar für die Information der Austauschstudenten).

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. Unterschriften beantworten können.

Es sollte den je nach durchgeführter Transaktion unterschiedlichen Sicherheitsanforderungen Rechnung getragen werden. Hier bieten die Eingabe der Benutzerkennung und Paßwörter, elektr. Unterschriften, TAN-Nummern und die Verwendung von Verschlüsselungsalgorithmen vielfältige Möglichkeiten je nach Eingabemedium die korrekte Authentifizierung gewährleisten zu können. Zum Zeitpunkt der Einführung des Systems sollten auch Transaktionen über das Internet per WWW vom Sicherheitsstandard her allen Ansprüchen gerecht werden (128-Bit Schlüssel etc.), falls die derzeitige Entwicklung anhält.

Alle Transaktionen im System sollten mitprotokolliert werden und von den verschiedenen interessierten Abteilungen einsehbar sein, falls die Datenschutzgesetze dies erlauben. 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 Anwender.



Eine umfangreiche Benutzerverwaltungskomponente sollte im System integriert werden. Berechtigungen müssen anwenderfreundlich verwaltet werden und automatisiert vergeben werden können. Bisherige Benutzerverwaltungssysteme können eingespart werden.

Datenschutz muß entsprechend berücksichtigt werden - insbesondere sollten Anforderungen der ÖH bzgl. der Einschränkung der Einsicht in Studentenstammdaten einbezogen werden.

Eine Auslagerung von Altbeständen von Daten zur Archivierung muß unterstützt werden, wie auch die Rückspielen dieser Daten zur Ansicht. Transaktionen (z.B. Zuordnungen 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 sichergestellt 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. verstehen sich von selbst.


Grobkonzept Projekt

4.2 Anregungen der verschiedenen Organisationseinheiten

In den Interviews wurden die verschiedenen Anforderungen, Bemerkungen und Befürchtungen der beteiligten Interviewpartner aufgenommen und werden im Folgenden dokumentiert. Die aufgeführten Themen entsprechen nicht unbedingt der Meinung der beratenden Firmen - sie sollen vielmehr ein Forum zur Transparenz der Meinungsvielfalt der WU-Wien bilden. Manche Themen wurden auch von den beratenden Firmen im Gespräch gefordert oder von mehreren Abteilungen angesprochen, wobei hier meist nur der erste Anstoß vermerkt wurde. Die von den beratenden Firmen unterstützten Anregungen werden durch das unterstrichene erste Wort des Satzes gekennzeichnet. Im Anhang findet man eine Legende zu den Abkürzungen der interviewten Abteilungen/Institute.

4.2.1 Studien- und Prüfungsabteilung Durch Nachschauen vom Studenten im Medium (z.B. WWW)

sollte möglich 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, Datenfelderkontrolle, 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 Zukunft 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 erfolgen falls sich eine Veränderung im System ergab!



Zulassungsdaten sollen direkt von Schulen eingespielt werden in Zukunft (von Schuldatenbanken).

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

2gether wird die Aufnahme mit Auflagen zum Studium (z.B. Fachhochschulabsolventen zu Doktoratsstudium mit Auflagen) unterstützen müssen.

Interessant wäre ein Sponsions-Ranking pro Fachbereich als Auswertung.

4.2.2 Institute/AbteilungenLehrveranstaltungen

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 Lehrveranstaltung eine Prüfung geplant ist.(WI)

Anforderung: Die Wartelistenfunktionalitäten sollten umfassend sein - speziell 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)


Grobkonzept Projekt

Anregung: Druck auf die Studenten zur Abmeldung zu LV dadurch, daß nur eine Menge, oder auch Reservoir, von „Credit Points“ pro Student zur Anmeldung zur LV existiert. (siehe Universität Konstanz). (WS2)

Anforderung: Bei der Hörsaalvergabe muß auch die Blockvergabe der Hörsä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.: Budgetsituationen 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 abgecheckt 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 Optimierung ü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 besten wäre Anlegung einer Tabelle in der Anmeldeliste mit den Veranstaltungsterminen als Spaltenköpfe (für Anwesenheitslisten etc.) - alle Feiertage, Rektoratstage etc. sind zu berücksichtigen. (BüRe)

Ü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 sollten sich auch auf Pakete von Lehrveranstaltungen beziehen können.(BüRe)

In dem im Internet generierten VVZ sollten Links zwischen den Lehrveranstaltungen und den ausführenden Instituten/Abteilungen automatisch vorgegeben 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 Mindest- (Lehr-) Stundenzahl erfüllen. (WI)

Bei Anmeldung zu Proseminaren und Seminaren sollte einen Themenauswahl ü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 Budgets, 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)


Grobkonzept Projekt

Vorschlag zur LV-Beginnmeldung: der LV-Leiters sollte bei seiner allerersten 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, Verteilerlisten 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 Eintrag 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 sollte über Genehmigung der Rechts- und Organisationsabteilung und des Studiendekanats 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 Lehrveranstaltung 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 - speziell 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) informiert 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 informiert werden können). (WS2)

Anforderung: Die Menge der Prüflinge sollten bei mehreren Prüfern entsprechend den Prüfern im System zugeordnet werden können. (WS2)

Die freiwerdenden Kapazitäten der Prüfungsabteilung sollten dafür eingesetzt werden, den (zeitlichen) Engpaß, der dadurch entsteht, daß eine LV von der STAB dem Studienplanpunkt zugeordnet werden muß, zu vermeiden. (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 anderen (schriftlichen) Prüfung ab, dann sollte diese Teilnahme auch automatisch generiert werden. (FI)

Anforderung: Das Halten von Prüfungsfragen im ‘2gether’ ist strikt optional (Gefahr des Mißbrauchs). (WA)


Grobkonzept Projekt

Anforderung: Nachrücker für Prüfungen müssen sich explizit anmelden.(WI)

Anmeldelisten für Lehrveranstaltungen oder Prüfungen dienen dazu, Verteilerlisten 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üfungsanforderungen einsehbar sein. (WS3)

Diplomarbeiten/Dissertationen Forderung: Rechtzeitige, zeitnahe Eintragungen in der

Themendatenbank, insbes. wenn (d.h. wann) das Thema vergeben worden ist. (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), Modellierung der Workflow-Prozesse).(WS2)

Es gibt einen abgestuften Delegationsmechanismus. Der Delegationsmechanismus 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 Gutachten vom Fachprofessor und Kooperationsprofessor. (EnSp)

Filter sollten bei der E-Mail-Verwaltung problemlos anwendbar und definierbar sein. (PoÖk)

Sommerhochschulkurse brauchen erst einmal nicht im System administriert werden. (ZAS)

Die Vergabe von ECTS-Credits sollte im System berücksichtigt werden - Nachweis von erzielten Credits könnte über maschinell bestätigten Ausdruck vom Studenten möglich sein. (ZAS)

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 (Englische 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. Unterschrift des ZAS. (ZAS)


Grobkonzept Projekt

Die Hörsaalverteilung sollte immer aktuell abrufbar sein. (BeSt) Anforderung: Berücksichtigung von nationalen und WU-internen

„Feiertagen“ im WU-weiten Terminkalender. (BeSt) WU sollte als Trust Center für Verschlüsselungs-Verwaltung

(Elektr. Unterschrift) dienen. (BeST) Ausblick: Bibliotheksverwaltung sollte in das System integriert

werden, insbesondere 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 gefordert 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 automatisch 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) anzuschauen 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 definieren. (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 angemeldete Studenten sein. (ÖH)



Anforderung: Sichergestellt werden muß, daß LV-Anmeldungen nach einer gewissen Frist, ohne daß eine Zulassung des angemeldeten Studenten erfolgt ist, gestrichen werden. (ÖH)

Anmerkung: Kritisch wird die kurze Zeit der Ist-Aufnahme im Projekt ‘2gether’ gesehen und daher werden Zweifel am ausreichenden Informationsstand 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 System).

Besser als eine Zuordnung der Veranstaltungen zu den Hörsälen analog der Verteilung wie vor 2 Semestern wäre jedes Semester eine vollautomatische 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öglichkeit 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 BedeutungWI WirtschaftsinformatikPoÖk Politische ÖkonomieRoSp Romanische SprachenEnSp Englische SprachenBüRe Bürgerliches RechtWA WarenhandelFI FinanzierungBeSt Betriebswirtschaftliche SteuerlehreWiSoGe Wirtschafts- und Sozialgeschichte


Grobkonzept Projekt

ZAS Zentrum für AuslandsstudienPeWi PersonalwirtschaftWS 1 Workshop 1WS 2 Workshop 2WS 3 Workshop 3WS 4 Workshop 4

Tabelle 6: Legende zu den Anmerkungen



4.3 Konzeptionelles Datenschema

4.3.1 IntentionNeben der Beschreibung der universitären Abläufe unter Berücksichtigung des neuen Systems ‘2gether’ durch Geschäftsprozeßmodelle, Funktionsbäume und Funktionszuordnungsdiagramme (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 handelt. Die technischen „Einzelheiten“, z.B. ob es sich um eine relationale oder eine objektorientierte 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 verständlich sein.

4.3.2 Semantische DatenmodelleDie 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. Eingegraute 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.




Grobkonzept Projekt

4.3.2.2 Studienplan

Abbildung 51: Semantisches Datenmodell ‘Studienplan’




*

Stu

dien

-pl

an

*

Stu

dien

-pl

anpu

nkt

*

Stu

dier

ende

/-rde

finie

rtLe

istu

ngfü

r

Fach

*

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

Fach

-ka

tego

rie

Wah

l- od

er

Pfli

chtfa

ch e

tc.

[Bed

ingu

ng] e

tc.

wird

real

isie

rtdu

rch

Stu

nden

-au

smaß

Prü

fung

s-or

dnun

g

ist B

a-si

s fü

r

1

Fern

stud

ium

-ei

nhei

tbe

steh

tau

s

wird

erse

tzt

durc

h

*

Lehr

ver-

anst

altu

ng

*

Stu

dien

-pl

an

Fach

-ka

tego

rie

Fern

-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

ß-ar

beit

[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äch

er-

kom

bina

tion

Fach

best

eht

aus

*

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] e

tc.

regl

emen

tiert

Stu

dien

-pl

anpu

nkt

(Abs

chlu

ßarb

eit)

benö

tigt

Typ

Abs

chlu

ß-ar

beit

Stu

dien

-pl

anpu

nkt

(Abs

chlu

ßarb

eit)

*

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’

*

Organisations-einheit

*

istbeteiligt

an

Verwaltungs-mitarbeiter

wissenschaftl.Mitarbeiter

*

Mitarbeiter

1

*

LV-Leitung

*

LV-Beteiligung *

Lehrver-anstaltung

Fachbereich

wirddurchgeführt

im

*

Lehrver-anstaltung

Lehrauftrags-rahmen

* *

Semester

Wochen-stunden-zuteilung

cn

Professor AssistentStudiendekan L1-Lehrer

genehmigt beantragt

Lehrver-anstaltungs-

raum

*

Semester

*Felder s.

"2gether - Grobkonzept", S. 57f

Lehrver-anstaltung

*

Zuteilung

[@Belegungszeit] etc.

*

Studierende/-r

[Name][Adresse][WU-Matrikel-nummer] etc.

*

Lehrver-anstaltung

*[Plazierung in derAnmeldungsreihenfolge]

etc.

Lehrver-anstaltungs-anmeldung

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



4.3.2.6 An- und Abmeldung

Lehrver-anstaltungs-anmeldung

Anmeldung

Prüfungs-anmeldung

1

giltfür

Studiumdes

Studierenden

1 cn

Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’


Grobkonzept Projekt

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

1WU-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

trifiz

ieru

ng e

tc. *

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

Term

in(-

liste

)de

s V

MA

'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

1interner

Mitarbeiter

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

1internerRaum

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

rteilu

ng] e

tc.

Lehr

ver-

anst

altu

ngs-

beur

teilu

ng

wird

beur

teilt

durc

h

Lehr

ver-

anst

altu

ng

[Zie

lerfü

llung

][D

idak

tik]

[Ler

nbeh

elfe

][B

etre

uung

] etc

.

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

Anza

hl v

on:

[wis

s. In

stitu

tspe

rson

al]

[abg

ehal

tene

Leh

rver

anst

altu

ngen

][d

urch

gefü

hrte

Beu

rteilu

ngen

] etc

.so

wie

Bel

astu

ngsa

naly

se

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

Organisations-einheit

Anschriftder Org.-Einh.

Anschriftdes MA's

Heimatan-schrift des

Studierenden

Studienan-schrift des

Studierenden

cccc

1

n

11

Abbildung 61: Semantisches Datenmodell ‘Adresse’


Grobkonzept Projekt

5 MENGEN- UND WERTGERÜSTDie folgende Tabelle 7 enthält eine Auflistung des Mengengerüstes, das für das zukünftige 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 Funktionalität („Fkt.“), andererseits als daten- (satz-) erzeugend („Ds.“). Letztere Größe hat (zunä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.

ZulassungswocheFkt., Ds. 1997

(pers.) Stundenplan 15.000 p.sem. zeitliche Spitzen Fkt. 1997(weitere) Zulassung, Wechsel

3.000 - 5.500 p.a. Fristen Fkt., Ds. 1997

Abmeldung v. Studienrichtung

1.000 p.a. Fkt. 1997

Abmeldung v. Studium 60 % d. Stud. aufwendig, zeitintensiv Fkt. 1997Abmeldung von LV 30.000 p.a. zeitliche Spitzen Fkt. 1997Abmeldung von Teildiplomprü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. 1997Anerkennungsanträge 5 - 6.000 p.a. große Belastung Fkt., Ds. 1997Anerkennungs-bescheide

16.000 p.a. Fkt., Ds. 1997

Anmeldung zu LV 122 - 144.000 p.a.

zeitliche Spitzen Fkt., Ds. 1997


5 MENGEN- UND WERTGERÜST

Bereich Häufigkeit Bemerkung Objekttyp JahrAnmeldung zu Teildiplomprüfung

23.000 p.a. zeitliche Spitzen Fkt., Ds. 1997

Aufnahme LV’s 2 p.a. à 2.500 Fkt. 1997Auskunft 100.000 p.sem. Fkt. 1997Erstellung/Wartung Studienplä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.) 1997Generierung TAN’s 15.000 p.sem. Fkt. 1997Leistungsfeststellung 100.000 LV’s

10.000 Dipl.Fkt., Ds. 1997

Planung LV’s 2 p.a. à 2.500 Fkt., Ds. 1997Planung Prüfungen 2 p.a. Fkt., Ds. 1997Planung Studienjahr-einteilung

1 p.a. Fkt., Ds.

Prüfungsanmeldungen 12.750 Dipl. 125.000 Prüf.

Fkt., Ds. 1997

Raumverwaltung 3.700 p.a. Fkt., Ds. 1997Rückmeldung 52 - 65.000 p.a. großer Aufwand Fkt., Ds. 1997Standard-Ausdrücke z.B. 2.700

Diplome p.a.Fkt. 1997

Studienabschluß 1.300 - 1.600p.a. Fkt. 1997VVZ-Zugriff 75.000 p.sem. zeitliche Spitzen Fkt. 1997Wartelisteeinträge Teildiplomprü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 eingeflossen (siehe Kapitel 8).


Grobkonzept Projekt

6 DATENSCHUTZ UND DATENSICHERHEIT

6.1 SchutzbedarfsermittlungDurch eine angemessene IT-Sicherheitsstrategie soll die Datensicherheit zur Gewährleistung einer ordnungsgemäßen Informationsverarbeitung (im Interesse der datenverarbeitenden Stellen) und der Datenschutz bei der Verarbeitung personenbezogener Daten (im Interesse der betroffenen Studenten und Mitarbeiter) gewährleistet werden.

Da bei der Studien- und Prüfungsverwaltung personenbezogene Daten verarbeitet werden, ist das dargestellte Schutzstufenkonzept bei der Beurteilung der einzelnen Funktionalitäten zu Grunde gelegt, wobei auch der Verwendungszusammenhang der zu verarbeitenden 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 Sicherheitskonzept – 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 Restrisikoanalyse enthält.

Das IT-Sicherheitskonzept ist umzusetzen durch: Abgleich vorhandener Maßnahmen mit dem Sollkonzept, Realisierung der offenen Maßnahmen, Realisierung der datenschutzrechtlichen Anforderungen, Beteiligung des Beauftragten für Datenschutz, Freigabe des Verfahrens, Schulung der Anwender, Inbetriebnahme des Verfahrens.


6 DATENSCHUTZ UND DATENSICHERHEIT6.1 Schutzbedarfsermittlung

6.1.1 Schutzstufenkonzept

6.1.1.1 Stufe INiedriger/geringer Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung keine besondere Beeinträchtigung des informationellen Selbstbestimmungsrechts erwarten läßt.

Beispiele:

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 Verarbeitung 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äftigungsverhä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 IIHoher Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung eine erhebliche Beeinträchtigung des informationellen Selbstbestimmungsrechts insofern erwarten läßt, als der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt werden kann oder die Daten aufgrund ihrer besonderen Sensibilität bzw. ihres Verwendungszusammenhangs einen höheren Schutzbedarf als Stufe I erfordern.


Grobkonzept Projekt

Beispiele:

besonders sensible Sozialdaten, Steuerdaten, Daten, die einem Berufs-, Geschäfts-, Fernmelde- oder Mandantengeheimnis unterliegen, Personalverwaltungsdaten (dienstliche Beurteilungen, berufliche Laufbahn u. dgl.) soweit nicht Stufe I, als „streng vertraulich“ eingestufte Verwaltungsdaten.

Sehr hoher Schutzbedarf ist bei personenbezogenen Daten gegeben, deren Verarbeitung eine sehr hohe Gefährdung des informationellen Selbstbestimmungsrechts insofern erwarten läßt, als eine Gefahr für Leib und Leben oder die persönliche Freiheit des Betroffenen gegeben ist.

Beispiele:

Adressen von polizeilichen V-Leuten, Adressen von Zeugen in bestimmten Strafverfahren.

Als Maßnahme für die Sicherstellung des Schutzbedarfs der Stufe II ist ein maßgeschneidertes 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 Bereiche 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 Schutzbedarfszuordnung vorzunehmen:

Gruppe Modul Schutzbe-darf

Stufe

Lehrveranstaltungen

Administration Lehrveranstaltung mittel I

Aufnahme Lehrveranstaltung mittel IPlanung Lehrveranstaltung kein I

Prüfungen Leistungsfeststellung mittel IPlanung Prüfungstermin niedrig/gering I

Studien Beendigung Studium mittel IRückmeldung Studium niedrig/gering IWechsel Studium/Aufnahme Zusatzstudium

mittel I

Zulassung Studium mittel I

Diplomarbeiten & Dissertationen

Einreichung, Beurteilung & Veröffentlichung

mittel I

Laufende Betreuung niedrig/gering IThemenvereinbarung niedrig/gering I

Anerkennungen Anerkennung durchführen mittel I


Grobkonzept Projekt

Gruppe Modul Schutzbe-darf

Stufe

Anerkennung vorbereiten mittel IBescheide der Anerkennung ausfertigen

mittel I

Abrechnungen Abrechnung mittel I

Evaluierungen Arbeitsbericht Institutsvorstände kein IBeurteilung Lehrveranstaltung niedrig/gering I

An- und Abmeldungen

Lehrveranstaltungsanmeldung durchführen

mittel I

Prüfungsabmeldung durchführen mittel IPrüfungsanmeldung durchführen mittel I

Allgemeine Module Hörsaaladministration kein IChipkartenverwaltung hoch II

Tabelle 8: Zuordnung des Schutzbedarfes

6.2 ChipkartenWichtige Funktionalitäten der Chipkarten sind:

Chipkarten als Speicher von Daten, die hinsichtlich ihrer Vertraulichkeit und/oder Integrität hohen Schutzbedarf aufweisen (z. B. Kontodaten, Personalverwaltungsdaten, Sozialdaten);

Chipkarten als Mittel zur Authentisierung ihres Trägers für die Gewährung des Zugriffs auf sicherheitsrelevante Daten und Funktionen (Kontoverfügungen, Änderung prüfungsrelevanter Individualdaten);

Chipkarten als Mittel zur Signatur von Dokumenten (Anerkennungsbescheide, 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 überzeugende 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 Vertraulichkeit);

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 gespeichert 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:

Ausstattung des Kartenkörpers mit fälschungssicheren Authentisierungsmerkmalen wie z.B. Unterschrift, Foto, Hologramme.

Steuerung der Zugriffs- und Nutzungsberechtigungen durch die Chipkarte selbst.

Realisierung aktiver und passiver Sicherheitsmechanismen gegen eine unbefugte Analyse der Chip-Inhalte sowie der chipintegrierten Sicherheitsfunktionen.

Benutzung allgemein anerkannter, veröffentlichter Algorithmen für Verschlüsselungs- und Signaturfunktionen sowie zur Generierung von Zufallszahlen.

Sicherung der Kommunikation zwischen der Chipkarte, dem Chipkartenbasierten Dienstleistungssystem (CDLS) und dem ggf. im Hintergrund wirkenden System durch kryptographische Maßnahmen.


Grobkonzept Projekt

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 neutralen, zertifizierten Systemumgebungen die Dateninhalte und Funktionalitäten ihrer Chipkarten 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 Risiken zu betrachten, wenn es um Fragen ihrer IT-Sicherheit geht. Aufwendige sicherheitstechnische Maßnahmen an und in der Chipkarte können durch unsichere Systemumgebungen bei der weiteren Verwendung der Daten konterkariert werden.

Wenn zum Beispiel das System der Studien- und Prüfungsabteilung nicht den erforderlichen 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.

Allgemein sind an die Sicherheitsfunktionen folgende Anforderungen zu stellen:

Zugriffs- und Nutzungsberechtigungen sollten soweit möglich von der Chipkarte selbst geprüft und gesteuert werden.

In Anwendungen sollten sich alle beteiligten Rechner (inkl. Chipkarten) gegenseitig authentifizieren. Die Authentifizierung des Benutzers hat gegenüber der Chipkarte zu erfolgen.

Sicherheitserwägungen greifen bereits bei der Herstellung, Initialisierung und dem Versand 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 Files), das Laden von Hersteller- und Transportschlüssel für die spätere

Initialisierung und die Ausgabe der Chipkarten und Transportschlüssel an den

Empfänger, insbesondere der Versand an die Studierendendurch entsprechende technische und organisatorische Maßnahmen abgesichert werden.

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 Sicherung der Chipkarte verfügt. Wesentliche Teile des Betriebssystems können bei der späteren Initialisierung über entsprechend authentisierte CDLS dynamisch aus Tabellen geladen 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 Forderungen zur Paßwortverwaltung bei Rechnern nicht voll auf Chipkarten übertragen werden, jedoch sollte die PIN-Länge je nach Sensibilität mindestens 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.

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 Programm-Programm-Kommunikation mit einem anderen Rechner oder einer anderen


Grobkonzept Projekt

Karte (z.B. mit einer Professional Card). Der Rechner bzw. die andere Karte muß authentifiziert werden.

Zwar bilden – wie oben festgestellt – Chipkarten und CDLS erst zusammen ein vollwertiges Rechensystem, jedoch befinden sich beide Komponenten in der Regel in unterschiedlicher 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 Student/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 gespeicherten 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 Funktion der Software sowie umgekehrt des Ausschlusses ungewollter Funktionen im realisierbaren Rahmen zu ermöglichen.

Als besonders angriffsgefährdet sind CDLS vom Typ „PC mit Kartenterminal“ anzusehen, sofern sie nicht in manipulationsgeschützten Umgebungen eingesetzt werden. Erhöhte Schutzfunktionen werden hier als notwendig angesehen.

6.3 InternetMit dem Zugang zum Internet sind Risiken verbunden, die größtenteils daraus resultieren, daß dieses Datennetz nicht unter Sicherheitsaspekten entwickelt wurde und historisch gewachsen ist. Schwächen finden sich in den Protokollen für die Datenübertragung, 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 somit 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üsseln; hierzu gehören auch Paßwörter und sonstige Authentifikationsdaten. Es sollte angestrebt 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) beauftragt werden.

Übernommene Programme und Dokumente sind vorab mit einem aktuellen Virenscanner 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üfsummenverfahren 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 Filterfunktion (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 verarbeitet, ist der hohe personelle und sachliche Aufwand für Firewall-Lösungen gerechtfertigt und geboten. Firewall-Konzepte stellen erhöhte Anforderungen an die lokale Systemverwaltung, da Administrationsfehler in diesem Bereich ungleich schwerwiegendere Konsequenzen haben können als bei isoliert betriebenen Rechnern.


Grobkonzept Projekt

7 MIGRATIONSKONZEPT

7.1 AllgemeinesDen folgenden Ausführungen zum Migrationsplan (wie auch den Wirtschaftlichkeitsbetrachtungen 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 realistisch und machbar anzusehen und wird in diesem Ausmaß auch von uns empfohlen.

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 20021 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.2 Ablöse STEPDB und INSTDBBei der Ablöse der alten Datenbankanwendungen durch die neue Software im Rahmen des 2gether-Projektes sind folgende Kriterien zu beachten:

7.2.1 DatenübernahmeSobald – wie im gegenständlichen Fall – sich die geplante neue Datenbankstruktur wesentlich von der alten unterscheidet und es gleichzeitig unmöglich ist, die neuen Anwendungen ohne „Altdaten“ zu starten, stellt die Datenübernahme eine erhebliche Erschwernis für die Betriebsaufnahme dar. Erfahrungsgemäß treten hierbei Probleme der folgenden Arten auf:

Die Altdaten entsprechen nicht den Konsistenzbedingungen der neuen Datenbank.

Die Altdaten können nicht sämtliche notwendigen Felder der neuen Datenbank 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 zusammenfinden.

Erschwerend tritt hinzu, daß sich im – bis zuletzt lebenden – Altbestand auch noch zwischen dem letzten Test und der realen Übernahme derartige Problemfälle ergeben können. 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.


Grobkonzept Projekt

7.2.2 Anmerkungen zur Synchronisation von DatenbankenEine permanente Online-Synchronisation großer Datenbanken ist praktisch ausgeschlossen. So lange der Altdatenbank die Führung des aktuellen Standes obliegt, muß von der Altanwendung aus nach jeder Datenbankveränderung eine analoge Veränderung 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

unterschiedlicher Technologie.Hat die Neudatenbank die Führung inne, so stellt sich das umgekehrte Problem, nämlich 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 dieser Methode liegt allerdings in den zu erwartenden hohen Laufzeiten für den regelmäßig notwendigen Datenabgleich, der zumindest die Tagfertigkeit der Datenbanken sicherstellen sollte. Bei dem derzeitigen hohen Änderungsaufkommen kann davon ausgegangen 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 werden, beide Datenbanken an einem gemeinsamen Stichtag umzustellen.

7.3 Zeitlicher AspektNach Aussagen des Herstellers SNI ist die derzeitige Version des Betriebssystems BS2000 und des Datenbanksystems UDS im Jahre 2000 nicht mehr lauffähig. Als Konsequenz muß

entweder auf die neuen Releases von BS2000 und UDS umgestiegen werden

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 Jahrhundertwechsel bereiten. Die Weiterverwendung der alten Anwendung verursacht demnach ausschließlich aufgrund notwendiger Systemadaptierungen (bei Hardware und Software) 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 allem der Massenbetrieb zu Semesterbeginn abgewickelt wird (Immatrikulation, Inskription, 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 empfohlen werden.

Bezüglich der Oracle-Anwendungen sind Jahr-2000-Einschränkungen nicht bekannt, allerdings sind hier noch entsprechende Garantien des Herstellers einzuholen.

7.4 SchnittstellenZwar sind die STEP-Anwendungen zu einem gemeinsamen Stichtag zu ersetzen, es kann jedoch davon ausgegangen werden, daß – um den dadurch entstehenden Zeitdruck 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 integriert sind, sind entsprechende Schnittstellen vorzusehen. Als wichtigste Schnittstellen sind hier anzuführen:

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


Grobkonzept Projekt

Es ist somit eine Schnittstelle erforderlich, die entweder – analog zur heutigen WUFIS-STEP-Schnittstelle – die Daten der angebotenen Lehrveranstaltungen in 2gether einspielt 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 betreffenden Semesters überzuleiten sind, sondern auch alle jene aus früheren Semestern, zu denen noch Prüfungen abgehalten werden.

7.4.2 HörsaalbelegungDie 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 ÜbergangszeitraumWie 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 werden:

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 verzichten 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 StudentenFür die Zulassung zu bestimmten Lehrveranstaltungen oder Prüfungen sind bestimmte Vorbedingungen zu erfüllen – das sind in der Regel absolvierte Prüfungen oder bescheidmäß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üfungshistorie zu beginnen. Dazu muß der Studienabteilung jedoch eine einfache Möglichkeit geboten werden, für Studierende, die den Nachweis einer Voraussetzung benötigen, diesen direkt am Schalter nachzuerfassen. Um manuelle Tätigkeiten dieser Art so gering 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 SelbstbedienungsfunktionenDie vorgesehenen Selbstbedienungsfunktionen für die Studierenden führen zu einer umfassenden Entlastung der angestellten Verwaltungskräfte. Aus Gründen der Ausfallssicherheit sollte dennoch die Möglichkeit beibehalten werden, an den Schaltern der Studienabteilung die an sich für die Selbstbedienung vorgesehenen Tätigkeiten vorzunehmen.

7.6 Zeitlicher AblaufWird aus den genannten Gründen entschieden, das 2gether-Projekt stufenweise einzuführen, so erscheint folgende Reihenfolge des Einsatzes der neuen Anwendungen zweckmäßig:

Gruppe Modul FunktionalitätStufe1 2 3 4 5 6

Lehrveranstaltungen

Administration LV XAufnahme LV XPlanung LV X


Grobkonzept Projekt


Anmerkung: durch Schnittstellen ist sicherzustellen, daß bereits in Stufe 1 die Inskription möglich ist.

PrüfungenPlanung Prüfungstermin

X

Leistungsfeststellung X

Studien

Studienpläne XZulassung Studium X X4

Zusatzstudium XStudienwechselRückmeldung Studium XBeendigung Studium X X5

Diplomarbeiten und Dissertationen

Themenvereinbarung XLaufende Betreuung XEinreichung, Beurteilung und Veröffentlichung

Beurteilung, soweit für Zeugnis erforderlich

X

Volle Funktionalität X

Anerkennungen

Anerkennung vorbereiten

X

Anerkennung durchführen

X

Bescheide ausfertigen X X6

Abrechnungen Abrechnung Basisfunktionalität XVolle Funktionalität X

EvaluierungArbeitsbericht Institut XBeurteilung Lehrveranst.

X

An- und Abmeldungen

Lehrveranst. Anmeldung

X

Prüfungsanmeldung XPrüfungsabmeldung X

Allgemeine Module

Hörsaaladministration XBenutzeradministration X

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.5 Eine allfällige Unterstützung von Nebensystemen wie Bibliothek, Leihgeräte etc. kann in einer späteren Phase erfolgen.6 Eine allfällige Unterstützung des Aktenlaufes vor der eigentlichen Bescheiderstellung kann in einer späteren Phase erfolgen.




Chipkartenverwaltung Unabhängig vom Zeitplan

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 weitere Funktionalitäten, die zur Abrundung eines provisorisch verwendbaren Gesamtsystems 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 abzuwickeln.

7.6.1 DatenüberleitungDas Datenmodell muß in jenen Teilen, die für die Realisierung in Phase 1 vorgesehen 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, entsprechende Umsetztabellen 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 problemlos, vor allem wenn das Datenbankdesign auf das jeweilige Datenbanksystem abgestimmt 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 angepaßt ist.

Im Anschluß daran ist erstmalig eine Datenübernahme aus den Alt-Datenbanken STEPDB und INSTDB vorzunehmen. Bei Notwendigkeit sind die Umsetztabellen solange 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.


Grobkonzept Projekt

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 StammdatenerfassungDaten, die nicht durch Überleitung aus den Altsystemen gewonnen werden können, aber 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 1In Phase 1 sind die Funktionalitäten

Benutzeradministration Stammdaten Studierende Studien (mit geringfügigen Abstrichen) 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 PhasenDie nachgelagerten Phasen 2 bis 6 können, was ihre Funktionalität betrifft, ohne Zeitdruck in Angriff genommen werden.

7.7 Zuordnungen alte/neue DatenbankDie folgende Tabelle 11 zeigt eine grobe Zuordnung zwischen den alten Datenbanken STEPDB und INSTDB zu den neuen Objekten. Die zweibuchstabigen Codes der Spalten STEPDB und INSTDB entsprechen den Tabellennamen, gefolgt von der Anzahl der Einträge im März 1998.

Objektname StepDB InstDB AnmerkungenAbgeltungsart PQ (6634) Kollegiengeld etc.Abschlußarbeit Diplomarbeit etc.; Titel, Termine,

Methoden, Kurzfassung, Förderungsmöglichkeiten

Abschlußarbeitsbegutachtung

Beurteilung, Begründung

Adresse PE (2383) ST (92072)

Anerkennungsbescheid

BD (38325) BB (112821) BL (222)

Aktenzeichen, Datum, Inhalt, Anrechnungsvermerk

Anerkennungsgegenstand

AN (81284) Behörde, Datum, evtl. Note, Art, Semesterzahl

Anmeldung LM (1029897) LV oder Prüfung; Datum, Status, NummerArbeitsberichtErhebungsbogenLehrauftragsrahmen

Lehrauftragstyp, Versteuerungsart

Lehrveranstaltung LV (8718) LV (5720) Typ, Bezeichnung, Daten aus der Ankündigung

Lehrveranstaltungsanmeldung

LS (689688) Anmeldungsreihenfolge

Lehrveranstaltungsbeurteilung

LP (36568) LT (103266)

Teilnahmefrequenz, Beurteilung

Lehrveranstaltungsrahmen

Kontingente, Rahmenwerte

Lehrveranstaltungsteilnahme

LS (689688) Ergebnisse

Lehrveranstaltungstermin

MT (18674) Teilnehmerzahl


Grobkonzept Projekt

Objektname StepDB InstDB AnmerkungenLV-Ankündigung IL (26556)

AH (13) AR (74)

Nummer, Zeitraum, Bezeichnung, Typ, Wochenstunden, Termine, letztes Semester, Lehrziele, Lehrinhalte, Sprache, Anforderungen, Literatur, Teilnehmerzahl

LV-Beteiligung v. Org.-Einh.

Funktion, Art der Beteiligung, Remuneration

LV-Beteiligung Mitarbeiter

ER (972) MI (49069) MS (33173) MB (20714)

MI (39223) MT (18674)

rechtl. Grundlage, Art der Beteiligung, Abrechnungsdaten

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

IN (234) IN (80) Bezeichnung, Art, Typ, ..., Öffnungszeiten

Prüfung AB (2607) Bezeichnung, Art, Beschreibung, CodePrüfungen des wiss. MA

TT (31143) TK (29615)

Anmeldezeitraum, Teilnehmerzahlen, Zuteilungssystem

Prüfung des Studenten

BS (488439) PR (325313) ET (3263)

Beurteilung, Status, Einsichtsfrist

Prüfungstermin TE (1609) PositionRaum Größe, AusstattungReservierung Belegungszeit, StatusRückmeldung SI (746161) Datum, Typ, BemerkungSemester Anfang, Ende, Bezeichnung, 1. Und letzte

Unterrichtswoche, lehrveranstaltungsfreie Zeiten, Fristen, Termine

Studium Typ, GesamtstundenzahlStudium des Studenten

BS (488439) Anfangs- und Enddatum, Status, Erfüllungsstatus, Abgabestatus

Student ST (92072) SH (127163)

Name, Matrikelnummer, Zahlweise, Gebührenstatus, absolvierte Schule, Stammhochschule, Rückgabestatus, Salden

Studentenausweis Status, Gültigkeitszeitraum, Kontonummer WU

Studienplan PL (36) Bezeichnung, Inkrafttreten, Ablaufdatum, Versionsnummer, zu verleihender Titel

Studienabschnitt eines Studiums

Anzahl Semester, Nachlaßsemester, Stundenzahl

Studium der Zulassung

lfd. Nr., Status



Objektname StepDB InstDB AnmerkungenStudiumsänderung Wechsel, Aufnahme, BeendigungStudienplanpunkt BP (7129) Bezeichnung, Typ, StundenausmaßTermin des wiss. MA

Anmeldekapazität

Terminliste TE (1609) Art der Termine, GültigkeitszeitraumWartelistenposition LS (689688)Zuteilung BelegungszeitZulassung zum Studium

Datum, Termine, Anmeldenummer, Status, Kennwort, Bemerkung

Tabelle 11: Zuordnung der neuen Objekte

Die nachstehende Abbildung 62 gibt die Zusammenhänge innerhalb der STEPDB wieder. Die Pfeile sind grundsätzlich vom Owner in Richtung Member gezeichnet, strichlierte Pfeile sind Beziehungen, die nicht durch Sets, sondern mittels Foreign Keys realisiert sind (in der Regel die Matrikelnummer). Die dunkel hinterlegten Recordarten enthalten keine Daten.


Grobkonzept Projekt

Abbildung 62: Struktur der Datenbank STEPDB



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


Grobkonzept Projekt

Abbildung 63: Struktur der Datenbank INSTDB


Grobkonzept Projekt

8 WIRTSCHAFTLICHKEITSBETRACHTUNGWirtschaftlichkeitsbetrachtungen 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 (Effektivitä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 Vereinfachung von Arbeitsabläufen und insbesondere auch aus dem Wegfall 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 eines neuen Systems wie folgt darstellen:

Abbildung 64: Bewertbarkeit des Verbesserungspotentials

Es ist darauf hinzuweisen, daß im vorliegenden Projekt lediglich die Steigerung der Effizienz 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.


Grobkonzept Projekt

8.1.1 Qualitative VerbesserungenDie 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 herleiten. Hierbei seien besonders erwähnt:

Eine integrierte, redundanzfreie DatenbasisDieses Ziel verkörpert die Grundlage aller weiteren Punkte. Unmittelbar bewirkt es eine höhere Fehlersicherheit bei der Bearbeitung.

Ein einheitliches, homogenes DV-SystemHier entfällt das mühsame Umschalten zwischen verschiedenen Anwendungen, was nicht zuletzt eine größere Vertrautheit mit den Funktionalitäten des Systems bewirken wird.

Optimale AuswertungsmöglichkeitenDurch 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 MehrfachdatenerfassungEin Grundsatz des neuen Systems ist es, Daten dort zu erfassen, wo sie anfallen. Dies beschleunigt die Dateneingabe und bewirkt zudem eine bessere 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 Informationen erheblich zeitnaher zur Verfügung. Als Beispiel seien hier nur die Notenauskunft für Prüfungsnoten oder die zeitnahe Einsicht in aktuelle Planungsstände des Vorlesungsverzeichnisses genannt.

Diese qualitativen Verbesserungen können somit auch zu kürzeren Studienzeiten führen. Im genannten Beispiel der Prüfungsnoten können beispielsweise die nur befristet gültigen Interimszeugnisse wegfallen und somit unter Umständen Anmeldefristen überhaupt erst eingehalten werden.

Die im Zusammenhang der Prozeßbeschreibung angeführte Argumenten- oder Nutzenbilanz stellt desweiteren eine detaillierte Auflistung auch qualitativ zu verstehender Verbesserungen dar. An dieser Stelle soll jedoch nicht weiter explizit hierauf eingegangen werden (vgl. Abschnitt Organisatorische Gestaltung der Studien- und Prüfungsverwaltung).



8.1.2 Quantitativ meßbare VerbesserungenDie exakte Herleitung des quantitativen Nutzens – der Verringerung des benötigten Arbeitsaufwandes zur Durchführung geringer bewerteter Tätigkeiten ausgedrückt in Personenarbeitsleistungen (PAL)7 – ist nicht unproblematisch. Dies gilt insbesondere vor dem Hintergrund des Projektes, eine Ausschreibungsgrundlage zu erstellen. Dadurch muß eine Abschätzung in diesem Rahmen zwangsläufig von einer optimalen Umsetzung der in diesem Fachkonzept beschriebenen Anforderungen, bei denen es sich ja auch um Maximalanforderungen handelt, an das System ausgehen.

Um eine fundiertere Basis für unsere Abschätzungen zu erhalten, wurden die Organisationseinheiten des Untersuchungsbereichs gebeten, Erhebungsbögen zum Mengen- und Wertegerüst auszufüllen, die auch eine (subjektive) Einschätzung der zu erwartenden Verbesserungen in Form von Zeitersparnis beinhaltet haben. Der Rücklauf dieser Bögen betrug beispielsweise aus den Instituten 50%, wobei zudem der Aussagegehalt 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 Personenarbeitsleistungen, 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 Verwaltungsbereiche, 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ößenordnung von Personenarbeitsleistungen nur in der STAB, so daß die Quästur, die RO, das ZAS und das Studiendekanat im folgenden nicht ein-gehender betrachtet werden. Dies bedeutet nicht, daß nicht auch in diesen Bereichen punktuelle, qualitative Verbesserungen zu erwarten sind (vgl. Argumentenbilanz, Abschnitt Organisatorische Gestaltung der Studien- und Prüfungsverwaltung).

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 wurde deshalb gewählt, weil der erzielbare Nutzen in einer Verringerung der benötigten Arbeitsleistung liegt, nicht jedoch in der Verringerung der Mitarbeiteranzahl.


Grobkonzept Projekt

Zum anderen wurden die zehn Institute und Abteilungen des (erweiterten) Untersuchungsbereichs um das spezifische Mengen- und Wertegerüst einschließlich einer Stellungnahme gebeten.

8.1.2.1 Studien- und PrüfungsabteilungZusammenfassend ergibt sich für die Studien- und Prüfungsabteilung ein Potential von

11 - 15 PAL8.

Dabei geht der maximale Wert vom Idealfall der optimalen Umsetzung der Anforderungen 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.

Abbildung 65: Qualitative Verteilung des Nutzenpotentials in der STAB

Die Nummern auf der horizontalen Achse stehen stellvertretend für die ermittelten Prozesse. Eine Zuordnung wird in Tabelle 12 vorgenommen.

8 Personenarbeitsleistung = Arbeitsleistung einer Person.



Lfd. Nr. Prozeßbereich1. Erstellung/ Wartung Studienplan2. Planung Studienjahreinteilung3. Zulassung4. Rückmeldung Studium5. Wechsel Studium/ Aufnahme Zusatzstudium6. Beendigung Studium7. Verleihung akadem. Grad/akadem. Feier8. Planung Prüfungstermin9. Leistungsfeststellung10. Notenabfrage11. Diplomarbeiten12. Dissertationen13. LV-Anmeldungen14. Prüfungsanmeldungen15. Abmeldungen16. Vormerkungen / Warteliste17. Anmeldeauskunft18. Anerkennungen19. 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.


Grobkonzept Projekt

Diese Bereiche verfügen über das höchste Automatisierungspotential.

8.1.2.2 Institute/AbteilungenAnalog erfolgt die Bewertung des Nutzenpotentials bei den Instituten. Hier ist jedoch eine „Hochrechnung“ der Daten aus der Befragung auf die gesamte WU erforderlich.

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üfungsanmeldun-gen10

Planung Prüfungstermin

# Prüfungsanmeldun-gen

Leistungsfeststellung

# Prüfungsanmeldun-gen

Notenabfrage

# Abschlußarbeiten Themenvereinbarung# Abschlußarbeiten Laufende Betreuung

9 „#“ := Anzahl10 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üfungsanmeldungen in etwa mit der Anzahl der Prüfungen korreliert, wurde auf diese zurückgegriffen.



Bezugsgröße Prozeßbereich# Abschlußarbeiten Einreichung, Beurteilung & Veröffentlichung

# LV-Anmeldungen LV-Anmeldungen# Prüfungsanmeldun-gen

Prüfungsanmeldungen

# LV-Anmeldungen Abmeldungen# LV-Anmeldungen Vormerkungen / Warteliste

# LV-Anmeldungen Anmeldeauskunft# Lehrveranstaltungen (Anträge zur) Hörsaaladministration

# 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

xbn

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

bj := WU-weiter Wert der Bezugsgröße des Prozeßbereichs j

Als Ergebnis läßt sich feststellen, daß sich eine WU-weite Effizienzsteigerung im Gegenwert von


Grobkonzept Projekt

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üfungsverwaltung können somit merklich reduziert und als zusätzliche Potentiale zur Unterstü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.

11 Personenarbeitsleistung = Arbeitsleistung einer Person.



Abbildung 66: Qualitative Verteilung des Nutzenpotentials in den Instituten

Hierbei ist anzumerken, daß – nach unserer Auffassung – tatsächlich ein größeres Nutzenpotential 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 Lehrveranstaltung3. Administration Lehrveranstaltung4. Planung Prüfungstermin5. Leistungsfeststellung6. Notenabfrage7. Abschlußarbeiten (Dipl.+Diss.), Summe8. Themenvereinbarung (Dipl.+Diss.)9. Laufende Betreuung (Dipl.+Diss.)10. Einreichung, Beurteilung & Veröffentlichung (Dipl.+Diss.)11. LV-Anmeldungen12. Prüfungsanmeldungen13. Abmeldungen14. Vormerkungen / Warteliste15. Anmeldeauskunft16. (Anträge zur)Hörsaaladministration17. Beurteilung Lehrveranstaltung18. Arbeitsbericht Institutsvorstände

Tabelle 14: Numerierung der Prozeßbereiche (Institute)


Grobkonzept Projekt

Zum Bereich der „LV-Anmeldungen“ ist noch zu vermerken, daß bereits heute die Anmeldung 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, andernfalls können sie nicht an der Lehrveranstaltung teilnehmen.



8.2 Kosten-/NutzenrechnungDa die Anwendung des Hedonistischen Modells auf die Quantifizierung der Einsparungen nicht möglich war12, wurde teils auf die Ergebnisse der Fragebogenaktion, teils auf eigene Schätzungen der zu erwartenden Verringerung des Verwaltungsaufwandes zurü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 geringer als die eingesparten Tätigkeiten einzustufen ist. Die Steigerung der Effektivität, die üblicherweise gleich hoch wie der Effizienzgewinn eingestuft wird (siehe dazu auch Seite 158, 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 Werte zurückgegriffen. Die vom ZID erstellte Kostenschätzung, deren Ansätze uns als durchaus plausibel erscheinen, ist in Anhang F beige-fügt. Es wurden folgende Adaptierungen vorgenommen (siehe Tabelle 15 auf Seite 169):

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 (Basis: ZID Gehaltskostenanteil 1997).

Die bislang unberücksichtigt gebliebenen notwendigen laufenden Adaptierungsarbeiten am Neusystem 2gether wurden aufwandsmäßig in die Kalkulation aufgenommen (1 Mitarbeiter fulltime).

Die Entwicklungszeit für die Realisierung des „2gether“-Projektes wurde mit drei Jahren angenommen (siehe dazu das in Kapitel 7 ausgeführte Migrationskonzept).

Der Durchrechnungszeitraum wurde auf 10 Jahre reduziert.

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.


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 TotalHardware, Systemsoftware (inkl. Wartung) 10,8 0,9 0,9 0,9 11,5 0,9 0,9 0,9 13,2 1,0 41,9Anwendungs-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 2008Hardware, 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,6Anwendungs-SW (Entwicklung) 19,2 19,2 19,2 0,0 0,0 0,0 0,0 0,0 0,0 0,0 57,6Eigenleistung (Entw. + lfd. Adaptierung) 1,2 1,2 1,2 0,6 0,6 0,7 0,7 0,7 0,7 0,7 8,3Schulung 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,5Kosten 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 2008Werkverträge (Erfassungsarbeiten STAB) 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 2,0Material (Formulare) 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 0,2 2,0Porto 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 5,0Reduktion Verwaltungsstellen -9,0 -13,0 -34,0 -34,0 -34,0 -34,0 -34,0 -34,0Reduktion 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,4Einsparungen 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 2008Aufwand 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% –

Tabelle 15: Gegenüberstellung der geschätzten Kosten

8 WIRTSCHAFTLICHKEITSBETRACHTUNG8.2 Kosten-/Nutzenrechnung

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 erwirkten 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: ProjektaufbauorganisationAbbildung 5: Phasen des Projektes ‘2gether’Abbildung 6: Die Instanzen eines UniversitätsprozessesAbbildung 7: Werkzeuggestütztes Vorgehen im Projekt ‘2gether’Abbildung 8: Das ARIS-Haus im GesamtüberblickAbbildung 9: Ebenenkonzept des ARISAbbildung 10: Beispiel eines Organigramms (Ausschnitt)Abbildung 11: Beispiel eines FunktionsbaumsAbbildung 12: Beispiel Entity-Relationship-ModellAbbildung 13: Beispiel einer Ereignisgesteuerten Prozeßkette (Ausschnitt)Abbildung 14: Legende der verwendeten ObjekttypenAbbildung 15: Bestandteile der MethodikAbbildung 16: WU Wien Aufbauorganisation nach UOG 93, ÜberblickAbbildung 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 AVerzeichnisse

Abbildung 27: Funktionszuordnungsdiagramm „Administration Lehrveranstal-tung“

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

fü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 Insti-

tutsvorstände“Abbildung 46: Funktionsbaum „allgemeine Funktionen“Abbildung 47: Funktionszuordnungsdiagramm „Hörsaaladministration“Abbildung 48: Funktionsbaum „allgemeine Systemfunktionen“Abbildung 49: Clustersammlung zur Studien- und PrüfungsverwaltungAbbildung 50: Semantisches Datenmodell ‘Studium’Abbildung 51: Semantisches Datenmodell ‘Studienplan’Abbildung 52: Semantisches Datenmodell ‘Lehrveranstaltung’Abbildung 53: Semantisches Datenmodell ‘Vorlesungsverzeichnis’


Grobkonzept Projekt

Abbildung 54: Semantisches Datenmodell ‘Prüfungen’Abbildung 55: Semantisches Datenmodell ‘An- und Abmeldung’Abbildung 56: Semantisches Datenmodell ‘Abschlußarbeiten’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 STEPDBAbbildung 63: Struktur der Datenbank INSTDBAbbildung 64: Bewertbarkeit des VerbesserungspotentialsAbbildung 65: Qualitative Verteilung des Nutzenpotentials in der STABAbbildung 66: Qualitative Verteilung des Nutzenpotentials in den Instituten



TABELLENVERZEICHNIS

Tabelle 1: Interviews und AbstimmungsgesprächeTabelle 2: Workshops – Termine und TeilnehmerTabelle 3: ModelltypverwendungTabelle 4: Modell-/ObjekttypzuordnungTabelle 5: Objekt-/AttributtypzuordnungTabelle 6: Legende zu den AnmerkungenTabelle 7: Mengengerüst der Studien- und Prüfungsverwaltung i.w.S.Tabelle 8: Zuordnung des SchutzbedarfesTabelle 9: Empfohlene BasistermineTabelle 10: Definition möglicher UmstellungsstufenTabelle 11: Zuordnung der neuen ObjekteTabelle 12: Numerierung der Prozeßbereiche (Verwaltung)Tabelle 13: Bezugsgrößen der ProzeßbereicheTabelle 14: Numerierung der Prozeßbereiche (Institute)Tabelle 15: Gegenüberstellung der geschätzten Kosten


Grobkonzept Projekt

VERZEICHNIS DER ABKÜRZUNGEN

ARIS Architektur Integrierter InformationsSystemeBeSt Betriebswirtschaftliche SteuerlehreBüRe Bürgerliches RechtCDLS Chipkartenbasiertes DienstleistungssystemEEPK Erweiterte Ereignisgesteuerte ProzeßketteEnSp Englische SprachenFI FinanzierungInstDB Datenbank auf UDS-Basis, Teil des AltsystemsISO/IEC International festgelegter StandardIT InformationstechnologieLV LehrveranstaltungPAL Personenarbeitsleistung (Arbeitsleistung einer Person)PAM ProzeßauswahlmatrixPeWi PersonalwirtschaftPIN Personal Identification NumberPoÖk Politische ÖkonomiePOS Point of SalePUK Personal Unblocking KeyRO Rechts- und OrganisationisabteilungRoSp Romanische SprachenSTAB Studien- und PrüfungsabteilungStepDB Datenbank auf UDS-Basis, Teil des AltsystemsUDS Codasyl-basiertes Datenbanksystem der Firma SNIWA WarenhandelWI WirtschaftsinformatikWiSoGe Wirtschafts- und Sozialgeschichte



WS 1 Workshop 1WS 2 Workshop 2WS 3 Workshop 3WS 4 Workshop 4ZAS Zentrum für AuslandsstudienZID 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 Anwendungssystemen in Dienstleistungsbetrieben, Deutscher Universitätsverlag, Wiesbaden, 1997

[KruOeSiVa95]

Krumbiegel, J., Oechsler, W.A., Sinz, E.J., Vaanholt, S.: Business Process 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 Kommunikationssystemen an Forschungs- u. Lehrarbeitsplätzen - Theoretische Analyse und empirische Ergebnisse, Hansen/Janko (Hrsg.), WU Wien, 1988

[ProSo93] Prosser, A., Sommer, B.: EDV-unterstützte Lehrveranstaltungsadministration 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 Anwendungssystem, 3. Aufl., Berlin et al. 1998

[Schmi97] Schmidt, S.: WU Informationssystem 2000 - Neue Ansätze der Studentenverwaltung, Diplomarbeit, WU Wien, 1997

[Si95] Sinz, E.J.: Serviceorientierung der Hochschulverwaltung und ihre Unterstützung durch workflow-orientierte Anwendungssysteme, Bamberger Beiträge zur Wirtschaftsinformatik, Nr. 35, 1995

[Si96] Sinz, E. et al.: WU IS 2000 – Geschäftsprozeß- & Anwendungssystemarchitektur der WU Wien, Bamberg, 1996

[Si97] Sinz, E.J.: Analsyse und Gestaltung universitärer Geschäftsprozesse und Anwendungssysteme, Bamberger Beiträge zur Wirtschaftsinformatik, 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).

ObjektnameFeldname Bemerkung

AbgeltungsartBezeichnung z.B. Kollegiengeld, TutorengeldRegelwerk

AbschlußarbeitTitel Ggf. auch englischTyp der Arbeit Diplomarbeit, Dissertation etc.AbgabedatumSeitenzahlTextspracheKurzfassung AbstractSchlagwörter ggf. auch englischVorkenntnisse Erforderliche VorkenntnisseMethoden benötigte MethodenFristen z.B. für Themeabgrenzung, Vorlage einer

GrobfassungBemerkungen z.B. Ablaufplanung, BenotungLiteraturlisteWeb-Link-ListeFörderungs-möglichkeiten<sonstige Felder> s. 'Grobkonzept 2gether', S. 77ff

AbschlußarbeitbegutachtungBeurteilung


Anhang BDatenfelder

ObjektnameFeldname BemerkungBegründung

AA-Fach-ZUOFachrolle Erstfach, Nebenfach

AdressePLZ PostleitzahlOrtLandStrasseTelefonE-Mail

AnerkennungsbescheidAktenzeichenAblehnung? Kennzeichen, ob der Bescheid ablehnend

istDatum der BescheidungAusfolgedatumDatum der Anrechnung

AnerkennungsgegenstandArt der AnerkennungNummer lfd. Nummer der AnerkennungSemesteranzahl Anzahl der angerechneten Semester

Note Note, falls nicht aus dem Ergebnis angerechnet wird

Bemerkung


Grobkonzept Projekt

ObjektnameFeldname BemerkungBehörde Bezeichnung der ausstellenden Behörde,

z.B.der ausl. Universität

StaatStadtAusstellungsdatum Ausstellungsdatum der Urkunde

AnmeldungDatumTyp z.B. LV, PrüfungStatus z.B. aktuell, zurückgenommenNummer lfd. Nummer der Anmeldung

Arbeitsbericht# wiss. Institutspersonal Anzahl wiss. Institutspersonal

# abgehaltene Lehrveranstaltungen

Anzahl abgehaltene Lehrveranstaltungen

# durchgeführte Beurteilungen

Anzahl durchgeführte Beurteilungen

Belastungsanalysen s. 'Grobkonzept 2gether', S. 95 f

ErhebungsbogenZielerfüllungDidaktikLernbehelfeBetreuung

LehrauftragsrahmenLehrauftragstyp Funktion der beteiligten Org.-Einheit

Versteuerungsart


Anhang BDatenfelder


LehrveranstaltungBezeichnungLV-Typ<Felder aus der LV-Ankündigung>

Daten, die schließlich für die LV gelten und relevant sind

LehrveranstaltungsanmeldungPlazierung in der Anmeldungsreihenfolge

LehrveranstaltungsbeurteilungTeilnahmefrequenzBeurteilungÖffentlichkeitsgradGlobalurteile (Zufriedenheit, Empfehlung)DurchfallquotenAllgemeine FragenIndividuelle Fragen

LehrveranstaltungsrahmenKontingent, remuneriert SchlüsselattributKontingent, nicht remuneriertRahmenwerte

LehrveranstaltungsteilnahmeErgebnisse auch Zwischenergebnisse


Grobkonzept Projekt


LehrveranstaltungsterminTeilnehmerzahl

LV-AnkündigungLV-BeginnLV-EndeNummer lfd. Nummer im Abhaltungsplan

BezeichnungTyp z.B. Vorlesung, Seminar, Lehrgang

WochenstundenLV-Termine Wochentage, UhrzeitenLetztes Semester Semester, in dem die LV zuletzt

abgehalten wurdeStatus Status der Ankündigung, z.B. vorläufig,

entgültigModus AbhaltungsmodusAnmeldeartECTS-Anerkennungspunkte

European Credit Transfer System-Credits

ReihenfolgeverfahrenLehrinhalteLehrzieleUnterrichtsspracheAnforderungenVerwendete Literatur# Teilnehmer max. Anzahl der Teilnehmer<sonstige Abhaltungsinformationen>

s. 'Grobkonzept 2gether', S. 58


Anhang BDatenfelder


LV-Beteiligung v. Org.-EinheitFunktion Funktion der beteiligten Org.-Einheit

RemunerationstypArt der Beteiligung

LV-Beteiligung MitarbeiterRechtliche Grundlage z.B. Venia, Gastprofessur etc.AbrechnungsdatenArt der Beteiligung z.B. Leitung etc.

LeistungLeistungsart s. 'Grobkonzept 2gether', S. 91

Mitarbeiter/-inVornameZunameAkad. GradAnredeTelefonklappeFamilienstandGeburtsdatumGeburtsortGeschlechtSozialversicherungsnummerArt der PersonFunktionStaatsbürgerschaft


Grobkonzept Projekt

ObjektnameFeldname BemerkungDienstverhältnis

NostrifizierungGrad Bezeichnung des verl. Grades

OrganisationseinheitBezeichnungArt der Org.-Einheit z.B. extern/internTyp der Org.-Einheit z.B. Abteilung, Fachbereich, Institut

Hochschulcode lt. MinisteriumsentwurfFachgruppeÖffnungszeiten

PrüfungBezeichnungPrüfungsartBeschreibungPrüfungscode lt. Ministerium

Prüfungen des wiss. MAAnmeldezeitraumTeilnehmerzahlenZuteilungssystem

Prüfung des StudentenBeurteilung Endnote/ErgebnisStatusEinsichtsfristZwischenergebnis 1-n


Anhang BDatenfelder

ObjektnameFeldname BemerkungPunkte

PrüfungsterminPosition

RaumGrößeAusstattung

ReservierungBelegungszeit SchlüsselattributStatus

RückmeldungDatumTypBemerkung

SemesterSemesteranfangSemesterendeJahrBezeichnungTyp Sommer-, Wintersemester1. Unterrichtswoche mind. 14 WochenLetzte UnterrichtswocheLehrveranstaltungsfreie ZeitenImmatrikulationsfrist


Grobkonzept Projekt

ObjektnameFeldname BemerkungRückmeldungsfristPrüfungszeiträumeSponsionsterminePromotionstermine

StudiumStudientyp Kennzahl, BezeichnungGesamt-stundenzahl

Studium des StudentenAnfangsdatumEnddatumStatus z.B. "aufgenommenes ordentliches

Studium", "aufgenommenes Studium irregulare"

Erfüllungsstatus Bei Beendigung des Studiums: Sind alle Studienplanpunkte erfüllt?

Abgabestatus Bei Beendigung des Studiums: Sind die erfoderlichen Exemplare der Abschlußarbeit abgeben?

Student/-inNameWU-MatrikelnummerVermerk ZahlweiseGebührenstatusImmatrikulationsstatusSchule absolvierte SchuleSchulform Form der absolvierten SchuleAufnahmedatum


Anhang BDatenfelder

ObjektnameFeldname BemerkungExmatrikulationsdatumReifeprüfungsdatumStammhochschuleRückgabestatus I Bei Beendigung des Studiums: Sind die

entliehenen Bücher abgeben?

Rückgabestatus II analog: GeräteRückgabestatus III analog: SchlüsselSaldenstatus Salden auf diversen Konten?

StudentenausweisGültigkeitszeitraumStatusKontonummer der WU Zwecks Bezahlung vom Bankomat-

Terminal

StudienplanBezeichnungDatum des InkrafttretensAblaufdatumVersionsnummerTitel Titel, der durch die Absolvierung des

Studienabschnitts verliehen wird

Studienabschnitt des StudiumsAnzahl der Semester Anzahl der Semester, die inskribiert sein

müssenNummer lfd. nummer des AbschnittsNachlaßsemester Anzahl der Semester, die nachgelassen

werden könnenStundenzahl


Grobkonzept Projekt


Studium der ZulassungLfd. Nr.Status

StudiumsänderungTyp z.B. Wechsel, Aufnahme, Beendigung

StudienplanpunktBezeichnungTypStundenausmaß

Termin des wiss. MAAnmeldekapazität

TerminlisteGültigkeitszeitraumArt der Termine z.B. Prüfungstermin, Vorlagetermine

VergabeStatus Interesse, Bearbeitung

WartelistenpositionPosition

ZuteilungBelegungszeit Schlüsselattribut


Anhang BDatenfelder


Zulassung zum StudiumDatum der ZulassungVorlageterminAnmeldenummerStatus<Ersterfassungsfelder> s. 'Grobkonzept 2gether', S. 42 ffHochschulstatistik Felder des Formulars des Statistischen

ZentralamtsKennwortKennwort (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 entnehmen, 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 FunktionsbaumStudien- und Prüfungsverwaltung EERMAnwendungen WU-Wien Soll Anwendungssystemtypdia

gr.

\ROOT\2gether\Soll-Konzept\Lehrveranstaltungen

Lehrveranstaltungen administrieren

Funktionsbaum

Aufnahme von Lehrveranstaltungen

EEPK

Planung von Lehrveranstaltungen EEPKLehrveranstaltung EERMVorlesungsverzeichnis EERMAdministration Lehrveranstaltung Funktionszuordnungsdiagr

.Aufnahme Lehrveranstaltung Funktionszuordnungsdiagr

.Planung Lehrveranstaltung Funktionszuordnungsdiagr

.Lehrveranstaltung Prozeßauswahlmatrix

13 Nicht zu verwechseln mit der Struktur der ARIS-Methodik.


Anhang CARIS-Datenbank/Modell-Liste

Gruppe Modell Typ\ROOT\2gether\Soll-Konzept\Lehrveranstaltungen\Detailfunktionen

Anwesenheitslisten führen Funktionszuordnungsdiagr.

Datenfelder freigeben zur Ansicht Funktionszuordnungsdiagr.

Endnoten eingeben Funktionszuordnungsdiagr.

Layout der Anmeldeliste festlegen Funktionszuordnungsdiagr.

Lehrveranstaltungen mit eigener Beteiligung auflisten

Funktionszuordnungsdiagr.

Nachmeldungen eingeben Funktionszuordnungsdiagr.

Studierende zu Gruppen zusammenfassen


Studierendenlisten pro LV ausgeben


Teilnehmerlisten & Anwesenheitslisten ausdrucken


Zwischenergebnisse & Mitarbeitsnoten eingeben


\ROOT\2gether\Soll-Konzept\Prüfungen

Leistungsfeststellung EEPK

Planung von Prüfungen EEPKPrüfung EERMLeistungsfeststellung Funktionszuordnungsdiagr

.Planung Prüfungstermin Funktionszuordnungsdiagr

.Prüfung Prozeßauswahlmatrix

\ROOT\2gether\Soll- Diplomarbeiten/Dissertationen Funktionsbaum


Grobkonzept Projekt

Gruppe Modell TypKonzept\Diplomarbeiten & Dissertationen

betreuen

Diplomarbeiten/Dissertationen vereinbaren

Funktionsbaum

Diplomarbeiten/Dissertationen abschließen

EEPK

Diplomarbeit/ Dissertation EERMEinreichung, Beurteilung & Veröffentlichung


Laufende Betreuung Funktionszuordnungsdiagr.

Themenvereinbarung Funktionszuordnungsdiagr.

Diplomarbeit/ Dissertation Prozeßauswahlmatrix

\ROOT\2gether\Soll-Konzept\Diplomarbeiten & Dissertationen\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ühren


Stichwortkatalog erstellen Funktionszuordnungsdiagr.

Termine abstimmen Funktionszuordnungsdiagr.

Themen eintragen Funktionszuordnungsdiagr



Gruppe Modell Typ.

Voraussetzungen prüfen Funktionszuordnungsdiagr.

Zweitgutachter festlegen Funktionszuordnungsdiagr.

über Thema, Bearbeiter und Erstbetreuer informieren


\ROOT\2gether\Soll-Konzept\An- und Abmeldungen

Abmeldungen Funktionsbaum

LV-Anmeldungen FunktionsbaumPrüfungsanmeldungen FunktionsbaumAn- und Abmeldung EERMAbmeldung durchführen Funktionszuordnungsdiagr

.Lehrveranstaltungsanmeldung durchführen


Prüfungsanmeldung durchführen Funktionszuordnungsdiagr.

An-und Abmeldung Prozeßauswahlmatrix

\ROOT\2gether\Soll-Konzept\An- und Abmeldungen\Detailfunktionen

Abmeldung überprüfen Funktionszuordnungsdiagr.

Anmelde-Berechtigungen überprüfen


Informationen weitergeben Funktionszuordnungsdiagr.

Kapazitätsanalysen durchführen Funktionszuordnungsdiagr.

LV/Prüfung auswählen Funktionszuordnungsdiagr.

Lehrveranstaltung auswählen Funktionszuordnungsdiagr


Grobkonzept Projekt

Gruppe Modell Typ.

Lehrveranstaltungsanmeldung prüfen


Prüfung auswählen Funktionszuordnungsdiagr.

Prüfungsanmeldung überprüfen Funktionszuordnungsdiagr.

Sicherheitsvorkehrungen durchführen


Zuteilungsalgorithmen entwerfen Funktionszuordnungsdiagr.

\ROOT\2gether\Soll-Konzept\Anerkennungen

Anerkennungen erzielen EEPK

Nostrifikationen erzielen EEPKAnerkennung EERMErzielen 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 EEPKAbrechnung EERMAbrechnung Funktionszuordnungsdiagr

.

\ROOT\2gether\Soll-Konzept\Evaluierungen

Arbeitsberichte erstellen Funktionsbaum



Gruppe Modell TypBeurteilung von Lehrveranstaltungen

EEPK

Evaluierung EERMArbeitsbericht Institutsvorstände Funktionszuordnungsdiagr

.Beurteilung Lehrveranstaltung Funktionszuordnungsdiagr

.Evaluierung der Lehre Prozeßauswahlmatrix

\ROOT\2gether\Soll-Konzept\Studien

Beendigung des Sonderstudiums EEPK

Beendigung des Studiums EEPKErstellung Diplomzeugnis EEPKRü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

Studienplan EERMStudium EERMBeendigung Studium Funktionszuordnungsdiagr

.Diplomzeugniserstellung Funktionszuordnungsdiagr

.


Grobkonzept Projekt

Gruppe Modell TypRückmeldung Studium Funktionszuordnungsdiagr

.Wechsel Studium/Aufnahme Zusatzstudium


Zulassung Studium Funktionszuordnungsdiagr.

Zulassung Studium mit Auflagen Funktionszuordnungsdiagr.

Zulassung Studium mit Berechtigungsprüfung


Zulassung Studium mit allg. Voraussetzung


Zulassung Studium mit bes. Voraussetzung


Zulassung Studium mit ind. Studiengang


Studium Prozeßauswahlmatrix

\ROOT\2gether\Soll-Konzept\allgemeine Funktionen

Hörsaaladministration Funktionsbaum

PowerCard Funktionsbaumallgemeine Funktionen FunktionsbaumAdresse EERMRaumverwaltung EERMHörsaaladministration Funktionszuordnungsdiagr

.

\ROOT\2gether\Soll-Konzept\allgemeine Funktionen\Detailfunktionen

Chipkartenfunkionen Funktionszuordnungsdiagr.

Chipkartenverwaltung Funktionszuordnungsdiagr.

Hörsaal reservieren Funktionszuordnungsdiagr



Gruppe Modell Typ.

Hörsaal verwalten Funktionszuordnungsdiagr.

Hörsaal zurückgeben Funktionszuordnungsdiagr.

Hörsaalreservierungs-Info versenden


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


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 TypSoll-Konzept 2gether, Grobkonzept Funktionsbau

mStudien- und Prüfungsverwaltung Funktionsbau

m

Lehrveranstaltungen

Lehrveranstaltungen administrieren Funktionsbaum

Aufnahme von Lehrveranstaltungen EEPKPlanung von Lehrveranstaltungen EEPK

Prüfungen Leistungsfeststellung EEPKPlanung von Prüfungen EEPK

Diplomarbeiten & Dissertationen

Diplomarbeiten/Dissertationen betreuen Funktionsbaum

Diplomarbeiten/Dissertationen vereinbaren Funktionsbaum

Diplomarbeiten/Dissertationen abschließen EEPK

An- und Abmeldungen

Abmeldungen Funktionsbaum

LV-Anmeldungen Funktionsbaum

Prüfungsanmeldungen Funktionsbaum

Anerkennungen Anerkennungen erzielen EEPKNostrifikationen erzielen EEPK

Abrechnungen Abrechnungen mit PAV und PTKG EEPKAbrechnungen mit PAV und ohne PTKG EEPKAbrechnungen ohne PAV und PTKG EEPK

Evaluierungen Arbeitsberichte erstellen Funktionsbau


Anhang DARIS-Datenbank/wichtigste Modelle

Gruppe Modell Typm

Beurteilung von Lehrveranstaltungen EEPK

Studien Beendigung des Sonderstudiums EEPKBeendigung des Studiums EEPKErstellung Diplomzeugnis EEPKRückmeldung Studierende mit Zahlschein EEPKRückmeldung Studierende ohne Zahlschein EEPKZulassung Studierende mit Nostrifikationsauflagen EEPKZulassung Studierende mit Studienberechtigungsprüfung

EEPK

Zulassung Studierende mit allg. Voraussetzungen EEPKZulassung Studierende mit bes. Voraussetzungen EEPKZulassung Studierende mit indiv. Diplomstudiengang

EEPK

Zusatzstudium/Wechsel des Studiums EEPK

Allgemeine Funktionen

Hörsaaladministration Funktionsbaum

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’ automatisiert, d.h. etwa in einem Batch-Lauf durchzuführende Funktionen, sortiert nach den zugehörigen Prozessen.

Modell Funktion Automa-tisiert

Aufnahme von Lehrveranstaltungen

Beauftragungsbescheide verschicken X

Planung von Lehrveranstaltungen

Erinnerung bzgl. Erhebungsbogen an LV-Leiter verschicken

X

Erinnerung bzgl. LV-Beschreibung verschicken XHistorie v. LV-Leiter und LV überprüfen X

Leistungsfeststellung Anmeldedaten anzeigen XAuswahlliste aller Prüfungen ohne Noteneingabe generieren

X

Daten an Rechts- und Organisationsabteilung weiterleiten

X

Studierenden über Einsichtstermine benachrichtigen

X

Studierenden über Noteneintrag benachrichtigen

X

Planung von Prüfungen Prüfung anzeigen Xüber Terminierungsprobleme informieren XAuswahlliste der möglichen Prüfungen generieren

X

Prüfungstermin in Kalender eintragen XAnerkennungen erzielen Antragsteller über Anerkennung informieren XAbrechnungen 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) XAbrechnungen ohne PAV Abrechnungsbelege erstellen X


Anhang EARIS-Datenbank/Auswertungen


und PTKGAdressenangaben der Fehlläufer angeben XAnweisungen an Postsparkasse übermitteln XDaten an Bundesrechenzentrum schicken XDatenabgleich vornehmen (PIS->2gether) XFehlläufer informieren XLeistungsempfänger benachrichtigen X

Beendigung des Sonderstudiums

Abmeldung bewirken X

Bescheid erstellen XInformation der Abmeldung versenden XKartenfunkionen deaktivieren XSaldo der Abrechnungskonten prüfen XStudienblatt zur Beendigung generieren XStudierenden über Negativsalden informieren XStudierendenstammsatz deaktivieren X

Beendigung des Studiums

Abmeldung bewirken X

Information der Abmeldung versenden XKartenfunkionen deaktivieren XSaldo der Abrechnungskonten prüfen XStudienblatt zur Beendigung generieren XStudierenden über Negativsalden informieren XStudierendenstammsatz deaktivieren X

Erstellung Diplomzeugnis

Sponsionsbescheid versenden X

Rückmeldung Studierende mit Zahlschein

Bezahlungen bzgl. Rückmeldung überprüfen X

an Rückmeldungsbezahlung erinnern XRückmeldung Studierende ohne Zahlschein

Erinnerung an Rückmeldung versenden X


Grobkonzept Projekt


Zulassung Studierende mit Studienberechtigungsprüfung

Prüfungsbescheid zur Studienberechtigungsprüfung konfigurieren

X

Zulassung Studierende mit allg. Voraussetzungen

Zulassungsvoraussetzungen prüfen X

ÖH-Beitrag zurückerstatten XZulassung 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 überprüfen

X

Neue Studienwahl bestätigen XWechselmöglichkeit überprüfen Xbisherige Leistungen anerkennen X


Grobkonzept Projekt

Anhang F: Wirtschaftlichkeitsbetrachtungen (ZID)

Documents

Sollspezifikation '2gether' der WU Wien · Web viewSollspezifikation Projekt. der WIRTSCHAFTSUNIVERSITÄT WIEN K:\WU-WIEN\SOLLSPEZ\BERICHT8.DOC INHALTSVERZEICHNIS. 1 Einleitung