UNIVIS
Ein Haus voller Daten

von Harald Riedel-Taschner (Ausgabe 05/2, Oktober 2005)

 

Kasten: UNIVIS: Darf's ein bisserl mehr sein?

Kasten: Datawarehouse: Technik & Logistik

 

Vor einem Jahr erschien der letzte Comment-Artikel zum Thema UNIVIS. Damals wurde eine Vorstudie für das UNIVIS-Teilprojekt Managementinformationssystem (MIS) / Datawarehouse erwähnt, auf die noch im September 2004 das Projekt Reporting System mit dem Ziel aufsetzte, ein bis dato nicht existierendes universitäres Berichtswesen aufzubauen. Mittlerweile ist das ambitionierte Projekt, das im Abschnitt Reporting System: Von der i3v-Tabelle zum Monatsbericht näher beschrieben wird, weit gediehen: Die ersten Reports sollen Ende Oktober 2005 zur Verfügung stehen.

Aber auch in anderen UNIVIS-Teilprojekten hat sich viel getan (siehe Abschnitt UNIVIS: Neuerungen im Überblick). Darüber hinaus war die Arbeit des letzten Jahres geprägt von der Wartung und umfangreichen Weiterentwicklung der Universitätsverwaltungssoftware i3v sowie von Konsolidierungsmaßnahmen in den Bereichen Changemanagement und Softwareentwicklung (siehe Kasten UNIVIS: Darf's ein bisserl mehr sein?).

UNIVIS: Neuerungen im Überblick

Studien- und Lehrwesen

In der Dienstleistungseinrichtung Studien- und Lehrwesen (Studienzulassung), in der Universitätsbibliothek und am Universitäts-Sportinstitut wurden im August 2005 Bankomatterminals installiert. Damit ist es unter anderem erstmals möglich, den Studienbeitrag direkt am Schalter der Studienzulassung mittels Bankomatkarte zu entrichten. Neben diesem zusätzlichen One Stop-Service1) können die Studierenden in der Studienzulassung nun auch ihren Zahlschein zur Überweisung des Studienbeitrags ausdrucken, falls er verloren wurde und der/die Studierende nicht mittels Bankomatkarte zahlen möchte.

Die Rückerstattung der Studienbeiträge auf das Konto des Einzahlers wird mittlerweile für alle begünstigten Personengruppen - auch für die studierenden MitarbeiterInnen der Universität Wien - über i3v abgewickelt.

Die schon etwas betagte Prüfungsverwaltungssoftware PV-Client, die mit Ausnahme der Rechtswissenschaftlichen und der Medizinischen Fakultät an allen Fakultäten der Uni Wien jahrelang im Einsatz war, wurde im Zuge der Vereinheitlichung der Verwaltungssysteme seit September 2004 Schritt für Schritt abgelöst. Die Funktionen des PV-Client sind seit Ende März 2005 vollständig in i3v integriert. Per 30. April 2005 konnte der PV-Client daher mit allen daran gebundenen Transaktionsservern endgültig außer Betrieb genommen werden. Nachdem im Bereich der Prüfungsverwaltung ein sehr großer Personenkreis noch nicht i3v-erprobt war, mussten fast 300 Uni-MitarbeiterInnen entsprechend ausgebildet werden. Deshalb fanden von Jänner bis Mai 2005 insgesamt 15 Basisschulungen zu i3v und 32 Schulungen zur i3v-Prüfungsverwaltung statt.

Auf Basis der ersten Ergebnisse des universitätsweiten Projekts Lehre XXI, das u.a. die Geschäftsprozesse im Lehr- und Prüfungswesen vereinheitlichen soll, entsteht derzeit ein Prototyp eines Lehrveranstaltungs-Anmeldesystems für die Politikwissenschaft. Synchron dazu wurde eine XML-basierte, allgemein einsetzbare Importschnittstelle zu i3v entwickelt. Mit Hilfe dieser Schnittstelle soll das Importieren von Prüfungsdaten aus dezentralen "Insellösungen" (z.B. JUSTA, APIS oder ISWI2)) in das i3v vereinheitlicht und erleichtert werden. Das langfristige Ziel ist, alle Daten im selben System verwalten zu können.

In Folge der Umstellung auf den neuen Organisationsplan der Uni Wien, der mit 1. 10. 2004 in Kraft trat, musste der Lehrveranstaltungs-Workflow komplett adaptiert werden: Die Implementierung des Universitätsgesetzes 2002 erforderte tiefgreifende Anpassungen in der i3v-Software, zumal fast jeder bisherige Workflow-Schritt aufgrund der mit Oktober 2004 eingerichteten Studienprogrammleitungen überholt war. Ab September 2004 wurde sukzessive die neue Organisationsstruktur der Uni Wien in i3v abgebildet. Unter anderem mussten Universitätseinrichtungen, Personen (damit z.B. Arbeitsplätze und -adressen), Kostenstellen, Lehrveranstaltungen und Lehranteile neu zugeordnet werden.

Personalwesen

Hier hatte die Abteilung Universitätsverwaltung des ZID an den komplexen Geschäftsprozessen der Personalabteilung zu tüfteln; insbesondere die EDV-unterstützte Berechnung von Sonderzahlungen und die Anmeldungen zu den Sozialversicherungsträgern erwiesen sich als unerwartet zeitaufwendige Projekte. Daneben war das Teilprojekt Personalwesen geprägt durch die Vorbereitungen für den Umstieg des Bundesrechenzentrums (BRZ GmbH) auf pm-sap, das neue Lohnverrechnungsprogramm für Beamte.3) Nach der ursprünglichen Planung des Ministeriums für Bildung, Wissenschaft und Kultur (bm:bwk) hätte pm-sap am 1. Jänner 2005 an allen österreichischen Unis in Betrieb gehen sollen; die Einführung wurde jedoch um ein Jahr verschoben. Daher wurde auch die Fertigstellung der Schnittstelle zwischen i3v und pm-sap auf Herbst 2005 vertagt. Nach derzeitigem Wissensstand sollen im November 2005 Probeabrechnungen laufen, und per 1. 1. 2006 soll pm-sap definitiv an allen Universitäten eingesetzt werden. Damit wird früher oder später die PAV-Schnittstelle (die bisherige Schnittstelle zum Besoldungsverfahren des BRZ) ausgedient haben und stillgelegt werden. Abschließend sei noch ein Überblick über den Ressourceneinsatz des Softwareentwicklungs-Teams der AUV angeführt: Wie aus Abb. 1 ersichtlich ist, wurde 2004 und 2005 jeweils rund ein Drittel der personellen Ressourcen in das UNIVIS-Teilprojekt Personalwesen investiert.

Ausblick

Um die notwendigen Daten zur Berechnung von Kennzahlen aus dem Forschungsbereich für die Wissensbilanz zur Verfügung stellen zu können, wurde kürzlich mit dem Aufbau einer Forschungs- und Leistungsdokumentation begonnen, welche die bestehende Forschungsdatenbank FODOK ablösen soll. Geleitet wird dieses Projekt von der Dienstleistungseinrichtung (DLE) Forschungsservice und Internationale Beziehungen, unter tatkräftiger Mitwirkung der DLE Bibliotheks- und Archivwesen, der DLE Finanzwesen und Controlling und des Zentralen Informatikdienstes.

Zielsetzung ist es, Daten aus allen forschungsrelevanten Bereichen für die Entscheidungsträger der Universität Wien, aber auch für alle internen und externen Interessenten einfach und schnell verfügbar zu machen. Dabei sollen insbesondere Daten zu folgenden Themen abgefragt werden können: Publikationen, Forschungsprojekte, Patente, Aktivitäten bei wissenschaftlichen Veranstaltungen (als Vortragender, Veranstalter etc.), wissenschaftliche Auszeichnungen und Preise, Gutachtertätigkeiten, Herausgeberschaften sowie Mitgliedschaften in wissenschaftlichen Organisationen.

UNIVIS: Darf?s ein bisserl mehr sein?

Changemanagement

Parallel zu allen konkreten Projektarbeiten wurde im Laufe des letzten Jahres nicht nur die Entwicklung der i3v-Software auf ein breites und ausbaufähiges Standbein gestellt (siehe i3v - fit für die Zukunft), auch die dahinter liegenden Prozesse und die organisatorischen Rahmenbedingungen wurden optimiert:

  • Dem Softwareentwicklungs-Team der Abteilung Universitätsverwaltung (AUV) des ZID obliegt es nun, auf Basis der fachlichen Vorgaben Anforderungen an die i3v-Software zu definieren, in Rücksprache mit den Dienstleistungseinrichtungen fachliche Analysen zu erstellen und darauf aufbauend technische Designs zu formulieren. Für die fachlich fokussierten UNIVIS-Teilprojekte wurden Teilprojektleiter ernannt, welche die Aufgabenlisten verwalten und regelmäßige Abstimmungsgespräche mit den jeweiligen Fachabteilungen führen, um Anforderungen an die Software und konkrete Arbeitsaufträge zu besprechen.

  • Die fachliche Qualitätssicherung der Analysen und Designs wird durch einen Abnahmeprozess gewährleistet. Erst wenn die Fachabteilungen den Umsetzungsvorschlägen zustimmen, werden die Anpassungen bzw. Neuentwicklungen der i3v-Software auf der i3v-Entwicklungsumgebung realisiert.

  • Anschließend werden sie auf die i3v-Testumgebung übertragen ("ausgeliefert") und damit in den Verantwortungsbereich des Support-Referats der AUV übergeben, das gemeinsam mit den Fachabteilungen die adaptierten bzw. neu entwickelten Funktionen und Funktionalitäten testet und über die Freigabe der Software für den Produktionsbetrieb entscheidet. Dieses Referat übernimmt dadurch auch die Verantwortung für den Support und das Erstellen der technischen Teile der Dokumentation (auf Basis der von den Fachabteilungen abgenommenen Analyse- und Designdokumente).

  • Funktioniert alles wie erwünscht, wird das neu Implementierte auf die i3v-Produktionsumgebung ausgeliefert. Damit übernimmt das UNIVIS-Produktionsreferat die technische Verantwortung für den Betrieb der neu erstellten Software.

Dreh- und Angelpunkt dieses Prozesses - vor allem im Hinblick auf das neue Datawarehouse der Uni Wien, das Ende Oktober 2005 in Betrieb gehen soll - sind die Auslieferungen von der Entwicklungs- auf die Testumgebung bzw. von der Test- auf die Produktionsumgebung: Die Ladeprozesse in das Datawarehouse müssen mit den i3v-Auslieferungen synchronisiert werden, um sicherzustellen, dass die Daten in den Reports nicht plötzlich widersinnige und irrationale Werte ausweisen, weil sich z.B. die Bedeutung eines Feldes in i3v geändert hat, diese Änderung aber nicht in den Sternschemata des Datawarehouse nachgezogen wurde.

i3v - fit für die Zukunft

Die Universitätsverwaltungssoftware i3v wird nicht nur in Bezug auf fachliche Anforderungen, sondern auch hinsichtlich Bedienbarkeit und Qualitätssicherung laufend weiterentwickelt. In diesem Kontext wurden z.B. das Datenfehlermanagement und die Verwendung des i3v-Workflow verbessert und um neue Funktionalitäten erweitert. In naher Zukunft soll eine alternative tabellarische Darstellungsform realisiert werden, mit der mehrere Datensätze gleichzeitig bearbeitet werden können und die Filter- und Sortierfunktionen bietet, die bisher in i3v nicht möglich waren. Auch die Anbindung anderer Systeme an i3v hat einen hohen Stellenwert: Neben den bereits umgesetzten Schnittstellen zu externen Lohnverrechnungsprogrammen und zum Datenverbund des Bundesrechenzentrums sind auch XML-Schnittstellen in Arbeit, um Daten aus "fremden" Systemen laufend in standardisierter Form nach i3v übernehmen zu können. Als Voraussetzung für den geplanten Umstieg auf die aktuelle Datenbankversion 10g des Oracle-Servers wurde der i3v-Klient mit Jahreswechsel 2004/2005 auf die neueste Version der Plattform Metacard umgestellt. Ein weiteres Vorhaben bis Ende 2006 ist die Integration von Web-Services in bestehende Anwendungen. Parallel zur "traditionellen" Entwicklung wird i3v um Web-Komponenten erweitert. Dadurch können - unabhängig von der Verwendung durch das Verwaltungspersonal - auch Dienstleistungen für zusätzliche Benutzerkreise angeboten werden (z.B. für Lehrende und/oder Studierende). Erste bereits im Einsatz befindliche Anwendungen für Studierende der Uni Wien sind die Voranmeldung zum Studium per Internet sowie UNIVIS online. Beim Ausbau der Online-Services wird auf den Technologie-Standard J2EE und auf weit verbreitete Open Source Frameworks wie Spring und Hybernate gesetzt. Erfreulicherweise ist es auch gelungen, den Spring-Mitentwickler Jürgen Höller projektbegleitend an Bord zu holen.

Reporting System: Von der i3v-Tabelle zum Monatsbericht

Bereits im ursprünglichen Masterplan des UNIVIS-Projekts war ein Teilprojekt Managementinformationssystem / Datawarehouse vorgesehen. Die nun erfolgte Überleitung der Universität Wien in die Vollrechtsfähigkeit nach dem UG 2002 und die damit verbundenen Notwendigkeiten (wie das Festschreiben von Zielvereinbarungen zwischen Universität und Ministerium sowie zwischen Rektor und Organisationseinheiten der Universität, aber auch die im UG 2002 § 13 Abs. 6 geforderte Wissensbilanz und die Berechnungen für ein formelgebundenes Budget nach UG 2002 § 12 Abs. 8) machten es notwendig, dieses Teilprojekt in Angriff zu nehmen. Mit Oktober 2004 starteten die DLE Finanzwesen und Controlling und die Abteilung Universitätsverwaltung des ZID daher das Projekt Reporting System, dessen Ziel es ist, zur Unterstützung der Entscheidungsträger der Uni Wien ein Berichtswesen auf Basis eines Datawarehouse aus allen universitären Bereichen aufzubauen.

Was ist ein Datawarehouse?

Operative EDV-Systeme für die Universitätsverwaltung sind in erster Linie dazu gedacht, die in der jeweiligen Fachabteilung angesiedelten Geschäftsprozesse zu unterstützen. Dabei steht die Verwaltung einzelner Datensätze im Vordergrund. Die erfassten Daten (z.B. einer Studienzulassung) werden zweckorientiert in einer Datenbank gespeichert und können auch wieder abgerufen werden, z.B. um ein Studienblatt oder ein Zeugnis zu drucken. An der Universität Wien wird für das Studien- und das Personalwesen sowie für die Raumbewirtschaftung die Universitätsverwaltungssoftware i3v eingesetzt; das Rechnungswesen der Universität wird über das am Bundesrechenzentrum betriebene Standard-Finanzverwaltungsystem SAP/R3 abgewickelt.

Alle diese EDV-Systeme sind aber auf die täglichen Arbeiten in den Fachabteilungen hin optimiert und verfügen über keine professionellen Auswertungsmöglichkeiten. Will man Daten auf eine andere Art extrahieren, als durch die Bildschirmmasken und programmierten Schnittstellen vorgesehen ist, so muss man mit entsprechenden Werkzeugen direkt auf die Datenbank zugreifen, die hinter diesen Systemen steht. Bei i3v-Daten geschieht dies durch SQL- oder PL/SQL-Prozeduren durch den ZID; bei SAP/R3 ist jedoch auf diesem Weg kein Zugriff auf die Grunddaten möglich. Für Auswertungen, die unterschiedliche Datenbestände verknüpfen (z.B. um Kennzahlen wie die Kosten eines Studierenden in einer bestimmten Studienrichtung zu berechnen), braucht man daher ein System, das imstande ist, alle benötigten Basisdaten in sich aufzunehmen und zu vereinheitlichen, um dann auf diesen neuen Datenbestand Abfragen zuzulassen. Außerdem sollte dieses System so beschaffen sein, dass nach entsprechender Einschulung jede Fachabteilung selbst in der Lage ist, mit einer geeigneten Software (einem so genannten Frontend-Tool, meist über Webbrowser) die gewünschten Auswertungen zu erstellen.

Ein solches System nennt man Datawarehouse - ganz nach dem Vorbild eines großen Kaufhauses, in dem die Produkte vieler Sparten gut sortiert und geordnet angeboten werden, damit man zum Einkaufen nicht die einzelnen Herstellerfirmen aufsuchen muss. Kauft man beim Baumarkt rote Kletterrosen, dazu Dünger, Gartenwerkzeug und dann noch Lavendel, um ihn zum Rosenstock zu setzen und ein ansprechendes Beet zu gestalten, so geht man genauso vor wie im Datawarehousing: Der beschriebene Vorgang ist vergleichbar mit dem Zusammenführen der Daten unterschiedlicher operativer Systeme - z.B. der Studierendendaten und der Finanzdaten in der Dimension Semester.

Baumarkt

Reporting System der Uni Wien

Gartenabteilung

  • Rosen
    Rosenarten und -farben

Studierendendaten

  • Fakten der Faktentabelle (Studierende, Matrikelnummern usw.)
    Dimensionen (Semester, Studienabschnitt usw.)

Werkzeugabteilung

Personaldaten

Elektroabteilung

Prüfungsdaten

(...)

(...)

Ein Grundprinzip der EDV-unterstützten universitären Verwaltung ist es, dass jede Fachabteilung für die Erfassung, Pflege und Herausgabe der sie betreffenden Daten verantwortlich ist. Für Erfassung und Pflege der Daten stehen die schon genannten operativen Systeme wie i3v oder SAP/R3 zur Verfügung. Durch den Aufbau des Datawarehouse wird nun erreicht, dass jede Fachabteilung "ihre" Daten auch wieder auswerten und veröffentlichen kann. Das kann Berichtsnotwendigkeiten an den Rektor genauso betreffen wie jene an Studienpräses und StudienprogrammleiterInnen oder Berichte für die universitäre Öffentlichkeitsarbeit.

Projektverlauf

Das Projekt Reporting System wird im Rahmen des UNIVIS-Projekts abgewickelt und finanziert; Gesamtprojektleiter ist Mag. Wolfgang Steinhart (DLE Finanzwesen und Controlling). Der Abteilung Universitätsverwaltung des ZID obliegt die technische Projektleitung und somit die Verantwortung für die technische Umsetzung der Anforderungen. Dies umfasst sowohl die (in enger Abstimmung mit der DLE Finanzwesen und Controlling erfolgende) Entwicklung des Berichtswesens als auch den Betrieb des in einzelnen Phasen fertig gestellten Systems. Innerhalb der Abteilung Universitätsverwaltung ist das Projekt zur Gänze - vom Initialaufbau des Datawarehouse über den Aufbau von Berichten bis hin zum technischen Betrieb auf allen Ebenen - im Produktionsreferat verankert.

Im Folgenden sollen die einzelnen Phasen und die wichtigsten Meilensteine des Projekts Reporting System kurz vorgestellt werden (siehe auch Abb. 2). Technisch Interessierte finden nähere Informationen über die Realisierung des Projekts im Kasten Datawarehouse: Technik & Logistik.

Phase 0 (Sommer 2004): Vorstudie
Eine erste Annäherung an das Thema Datawarehouse fand im Zuge einer Vorstudie der Firma Gosch Consulting statt, bei der u.a. das Kennenlernen der möglichen Anbieter für Datawarehouse-Software und der grundlegende Funktionsumfang eines Datawarehouse im Vordergrund standen. Weiters wurden im Rahmen der Vorstudie die relevanten Tätigkeitsbereiche für eine reportmäßige Abbildung erarbeitet und Vorschläge für Projektorganisation, Projektstruktur, Termine und Ressourcen vorgelegt.

Phase 1 (Herbst 2004): Ausschreibung
Im Herbst 2004 wurden acht marktpräsente Firmen zu informellen Produktpräsentationen eingeladen, um einen Überblick und eine bessere Orientierung über die gängigsten Software-Tools zu erhalten. So gerüstet, erfolgte im November und Dezember 2004 die zweistufige Ausschreibung nach EU-Vergaberichtlinie und Bundesvergabegesetz in Form eines Verhandlungsverfahrens mit vorheriger Bekanntmachung. Ausgeschrieben wurde nur das Frontend-Tool und dessen Implementierung; fünf Firmen wurden zur Anbotslegung eingeladen.

Während dieser Zeit wurden vom Datawarehouse-Team des ZID die Sternschema-Modellierung und der ETL-Prozess (siehe Kasten Datawarehouse: Technik & Logistik) erlernt und durchgeführt. Als Software für den ETL-Prozess wurde der Oracle Warehouse Builder (OWB) gewählt, da dieser sämtliche Anforderungen bestens erfüllt, in der bestehenden Campuslizenz mit der Firma Oracle bereits enthalten ist und sich gut in das Oracle-basierte Produktportfolio der Universität Wien einfügt.

Um die Daten aus den operativen Systemen eines Betriebes speziell für die Bedürfnisse eines Datawarehouse zu transformieren, wird in der Regel eine relationale Art der Datenmodellierung angewandt, die man Sternschema-Modellierung nennt (nähere Informationen dazu finden Sie z.B. bei Wikipedia; ein Artikel zum Sternschema der Universität Wien ist für die nächste Ausgabe des Comment geplant). Die umgewandelten Daten werden in die Tabellen des Datawarehouse geladen; auf diese Tabellen greift dann das Frontend-Tool zu und holt sich die Daten für die modellierten Berichte.

Die DLE Finanzwesen und Controlling gestaltete unterdessen den Prototypen eines Monatsberichts an das Rektorat. Einen weiteren umfassenden Bericht diverser Universitätskennzahlen stellt die Wissensbilanz dar, die als Grundlage für die Budgetverhandlungen und die Leistungsvereinbarung zwischen Universität und Ministerium dienen wird. Für diese beiden großen Berichte galt es in der ersten Ausbaustufe des Projekts die Datenbasis in Form eines Datawarehouse zu schaffen.

Phase 2 (Quartal 1 & 2 2005): ETL-Prozess, Teststellungen & Zuschlag
Im Jänner 2005 begannen die Arbeiten mit dem Oracle Warehouse Builder, um den ETL-Prozess zu implementieren. Zunächst wurden die Datenfelder in i3v und SAP/BW (SAP Business Information Warehouse) bestimmt, die für die Befüllung der Datawarehouse-Tabellen unter Vorgabe des Monatsberichts relevant sind. Anschließend wurden sukzessive die entsprechenden ETL-Mappings modelliert und ausgeführt. Im Zuge dessen waren auch umfangreiche Tätigkeiten im Bereich Datenqualitätsmanagement erforderlich (siehe Kasten Datawarehouse: Technik & Logistik).

Gleichzeitig wurde der in der Ausschreibung geforderte Proof of concept der angebotenen Tools durchgeführt: Die drei bestbewerteten Anbieter-Firmen mussten je zwei Wochen lang auf universitätseigenen PCs und auf Basis vorgegebener Testberichte die Leistungsfähigkeit ihres Produkts unter Beweis stellen. Den Zuschlag erhielt schließlich die Firma Siemens Business Systems (SBS) mit der Implementierung des Frontend-Tools Cognos.

Phase 3 (Sommer 2005): SAP/BW-Anbindung, Implementierung Cognos
Ab dem Sommer galt es nun, parallel zur Implementierung auch die Rahmenbedingungen für den Betrieb des Datawarehouse zu definieren. Eine besondere Herausforderung stellte die Anbindung des bereits erwähnten SAP/BW an das universitätseigene Datawarehouse dar. Das SAP/BW erfasst nach speziellen Vorgaben der Controller (DLE Finanzwesen und Controlling) die operativen Daten aus dem SAP/R3-Buchhaltungssystem der Universität und bereitet diese für Buchhaltungsauswertungen und einfache Reports für das Controlling auf. Eine Verknüpfung mit den anderen Datenbeständen der Universitätsverwaltung ist jedoch nicht gegeben. Deshalb müssen die Finanzdaten täglich über die Schnittstelle Open Hub aus SAP/BW exportiert und in die einheitliche Datenbasis des Datawarehouse übernommen werden. Da diese Schnittstelle kein Auslesen von Hierarchien, Perioden und Mengeneinheiten erlaubt (die sich aber selten ändern), war dafür eine zusätzliche Programmierung von SAP notwendig. Der ETL-Prozess für die Finanzdaten basiert infolgedessen auf zwei Dateien, die zeitgesteuert generiert werden; die Daten werden vom Bundesrechenzentrum zur Verfügung gestellt.

Im Juni 2005 begann auch die Implementierung des Frontend-Tools Cognos durch die Firma SBS. Zuerst erfolgten die Schulungen für die MitarbeiterInnen des Projektteams, dann wurden die "Sterne" nach Vorgaben von SBS an Cognos-Spezifika angepasst.

Phasen 4 & 5 (Herbst 2005): Produktionsüberleitung & Start Ausbaustufe 2

Ende Oktober 2005 soll das Datawarehouse der Universität Wien den Betrieb aufnehmen und die ersten Berichte liefern. Die Produktionsüberleitungs-Phase im Herbst besteht in erster Linie im Aufbau des Produktionsservers, damit auf das im ETL-Konzept vorgesehene dreistufige System umgestellt werden kann (siehe Kasten Datawarehouse: Technik & Logistik).

Weiters wird in der DLE Finanzwesen und Controlling eine so genannte Clearing-Stelle aufgebaut, die zukünftig die Abwicklung aller nicht-technischen Bereiche des Berichtswesens übernehmen soll - z.B. die Schulung der BenutzerInnen.

Für die Abteilung Universitätsverwaltung des ZID beginnt im Herbst 2005 gleichzeitig auch die zweite Ausbaustufe des Projekts Reporting System: die Integration zusätzlicher Datenbereiche für die Wissensbilanz, die Nachjustierung von Datenbereichen mit niedrigerer Priorität und die Unterstützung einer größeren Anzahl von BenutzerInnen. Auch die neu zu schaffende Forschungsdokumentation (siehe Ausblick) wird dann als Teil des Projekts in das Reporting System übernommen werden.

Datawarehouse: Technik & Logistik

Hardware

Das Datawarehouse der Universität Wien wird auf zwei IBM-Servern (pSeries 550) mit je vier Prozessoren betrieben. Auf beiden Rechnern läuft als Betriebssystem AIX 5.2 und als Datenbank-Managementsystem Oracle in der Version 10g. Einer der Server beherbergt die Entwicklungs-, die Test- und die Schulungsumgebung, der zweite die Qualitätssicherungs- und die tatsächliche Produktionsumgebung (siehe weiter unten).

ETL-Prozess

Unter ETL versteht man den Prozess des Extracting, Transforming und Loading von Daten. Die Daten werden aus den operativen Systemen wie i3v extrahiert ("entladen"), dann transformiert (z.B. durch Filtern von Daten oder Zusammenführen einzelner Felder) und - nach neuen Kriterien optimiert und für die Zwecke des Datawarehouse geordnet - wieder "geladen", diesmal jedoch in die Datenbank des Datawarehouse. Dies geschieht mit Hilfe einer speziellen Software; an der Universität Wien wird dafür der Oracle Warehouse Builder (OWB) eingesetzt.

CDC-Konzept

Der ETL-Prozess muss in regelmäßigen Intervallen durchgeführt werden, um eine möglichst aktuelle Datenbasis zu gewährleisten. Da nach der Initialladung bzw. nach jedem weiteren Ladelauf bereits Daten im Datawarehouse vorhanden sind, wäre es nicht sinnvoll, jedes Mal alle vorhandenen Daten zu löschen und die aktuellen einzuspielen. Aus diesem Grund hat man sich an der Uni Wien für den Einsatz eines Change Data Capture (CDC)-Konzepts in Form eines Full Diff Compare entschlossen. Dieses ermittelt die Änderungen, indem es die "alte" und die "neue" Datenbank - die beide durch Klone der Produktionsdatenbank der Quellsysteme (z.B. i3v) erzeugt werden - Datensatz für Datensatz vergleicht. Geladen werden dann nur noch jene Daten, die in den Quellsystemen neu erfasst oder geändert wurden. Dieses Konzept bietet auch den Vorteil, dass die Datenqualität vor dem Ladevorgang beurteilt und somit ein zusätzlicher Kontrollmechanismus eingeschoben werden kann.

Datenqualitätsmanagement (DQM)

Die Datenqualität der operativen Quellsysteme ist wesentlich für die Publikation aussagekräftiger, korrekter Berichte und erfordert deshalb besonderes Augenmerk und permanente Verbesserung. Daher wurde ein Workflow-unterstützter DQM-Prozess implementiert. Dieser Workflow reicht von der Erhebung und Analyse von Datenmängeln über die Festlegung von Maßnahmen hin bis zur Behebung - die häufig nur mit mehreren aufeinander abgestimmten Maßnahmen zu erreichen ist und dadurch einen längeren Zeitraum in Anspruch nehmen kann. Darüber hinaus musste als Basis für das Datawarehouse ein umfangreiches Glossar erstellt werden, um unterschiedliche Deutungen von Begriffen und die daraus resultierenden Missverständnisse und Probleme zu verhindern: Es ist unerlässlich, dass alle Personen, die von einem bestimmten Attribut in einem Bericht sprechen, exakt dasselbe meinen. Daher muss bereits bei der Befüllung des Datawarehouse genau nach diesen Definitionen vorgegangen werden.

Produktions-ETL-Konzept

Sowohl für den ETL-Prozess als auch für die Reporterstellung kommt an der Uni Wien ein dreistufiges System zum Einsatz: Entwicklung, Test und Produktion werden - analog zu anderen Verwaltungssystemen der Universität - als getrennte "Instanzen" geführt. Damit soll sichergestellt werden, dass nur freigegebene Daten für Außenstehende sichtbar werden und fehlerhafte Berichte nicht zur Publikation gelangen.

  • Auf der Entwicklungsumgebung wird der ETL-Prozess für neue Sternschemata entwickelt bzw. für bestehende Sterne angepasst.

  • Sobald die verschiedenen Prozesse fertig gestellt sind, werden sie auf die Testumgebung ausgeliefert. Hier erfolgt nun die Erstellung der Berichte und die Abnahme der Datenbasis durch die Key-User der jeweiligen Fachabteilung der Universität.

  • Nachdem die Daten und Berichte für korrekt befunden wurden, können sie auf die Produktionsumgebung ausgeliefert und - aufbauend auf einer Berechtigungshierarchie - entsprechend freigegeben werden.

 

 

1) StudienbeginnerInnen können sich nun per Internet voranmelden und anschließend in der Studienzulassung die notwendigen Unterlagen vorweisen und mittels Bankomatkarte bezahlen. Die Studienunterlagen und der Studierendenausweis werden dann sofort ausgestellt.

2) Über JUSTA können sich Studierende der Rechtswissenschaftlichen Fakultät zu Diplomprüfungen an- und abmelden. APIS ist das Anmelde-, Prüfungs- und Informationssystem der Fakultät für Psychologie. ISWI wird an der Fakultät für Informatik und an der Fakultät für Wirtschaftswissenschaften für die Anmeldung zu Lehrveranstaltungen und Prüfungen sowie für die Erfassung von Prüfungsnoten eingesetzt.

3) Die Besoldung für Beamte muss nach UG 2002 § 17 Abs. 2 im Bundesrechenzentrum erfolgen; die Lohnverrechnung für alle anderen MitarbeiterInnen der Uni Wien wird mit Hilfe der Software LeSalaire an der Universität durchgeführt.