TU Wien | ZID | ZIDline 9 | SAP-Einführung

SAP-Einführung an der TU Wien

Es wird ernst - kurze Geschichte und einige technische Aspekte des Projekts "uni.verse"

Wolfgang Kleinert

    Vorgeschichte
    Einige Aspekte der SAP-Basistechnologie
    Die Infrastruktur von uni.vers
    Zugang über ACOnet und "Portal Austria"
    Anforderungen an die Hard- und Software auf Seiten der Institute (Clients)
    Schlussbemerkung

Die Technische Universität Wien wird ab 1. 1. 2004 gemäß UG 2002 und Rechnungslegungsverordnung des BMBWK so wie auch alle anderen 20 vollrechtsfähigen Universitäten Bilanzen erstellen und ein dem ersten Abschnitt des dritten Buchs des Handelsgesetzbuchs entsprechendes Rechnungswesen führen müssen. Am 5. 1. 2004 geht das IT-Verfahren "uni.verse" für das neue Rechnungswesen in den Echtbetrieb.

Die Zeiten des Bundeshaushaltsgesetzes (BHG) und der entsprechenden IT-Verfahren (HV, HV-online, BVI, IBIS) werden auch für die TU Wien mit Jahresende 2003 vorüber sein. Die Institute wurden und werden bereits vom Rektorat durch Veranstaltungen und andere Informationen ausführlich auf die neue Situation vorbereitet. Hier soll ein wenig die Geschichte der geplanten SAP-Einführung erzählt und einige technische Aspekte des neuen IT-Verfahrens sowie die Anforderungen an die Hard- und Software auf Seiten der Institute (Clients) beleuchtet werden.

Vorgeschichte

Im Juni 2002 hat das BMBWK in Erweiterung des bereits seit mehreren Jahren laufenden Projektauftrags "HV-SAP" (d.h. die Umstellung der Applikation "Haushaltsverrechnung des Bundes" auf SAP R/3, mit dem Auftraggeber BMF, dem Generalunternehmer Siemens Business Services (SBS) und dem Betreiber Bundesrechenzentrum GmbH (BRZ)) der Firma SBS den Auftrag erteilt, als Generalunternehmer und Projektleiter "... das abschnittweise Redesign des Rechnungswesens gemäß UG 2002 der Universitäten unter Heranziehung der Standardsoftware SAP R/3" durchzuführen und den Echtbetrieb durch das BRZ vorzubereiten. Mögliche Alternativen wurden wegen des großen Zeitdrucks bei der Implementierung des UG 2002 offensichtlich nicht ernsthaft in Erwägung gezogen. Eckdaten dieses Auftrags waren u.a.:

(alle Zitate aus der "Projektpräsentation Kick-off Baden" vom 24. 9. 2002, zu finden auf der Projekt Homepage [1], siehe auch die gute Zusammenstellung der Universität Innsbruck [2]).

"UNI-SAP" wurde inzwischen in "uni.verse" umbenannt. Bis zum 1. 1. 2005 soll dann auch das auf dem SAP-Modul HR (steht für Personalmanagement und -verwaltung) beruhende IT-Verfahren "uni.pers" die Altapplikation "Besoldung" im BRZ abgelöst haben. An diesem Verfahren werden 16 Universitäten (darunter auch die TU Wien) teilnehmen und damit die Lohnverrechnung und Gehaltsauszahlung durchführen. Für das Jahr 2004 wird die Altapplikation "Besoldung" (PIS, PAV) auch für die Drittmittelangestellten weiterlaufen. Nach dem UG 2002 bleiben nur mehr die Beamten auch in Zukunft in der Bundesbesoldung, die ebenfalls mit 1. 1. 2005 auf SAP HR umgestellt werden soll (Projekt "PM-SAP").

SAP R/3 - was ist das ?

Was verbirgt sich hinter dem Kürzel SAP ?
Bedeutung: Quelle:
Systeme, Anwendungen, Produkte in der Datenverarbeitung SAPGUI Ver. 3.0 f
Ursprünglicher Name (1972): Systemanalyse und Programmentwicklung SAP AG
Fehlinterpretationen:
Software, Anwendungen und Probleme Prof., anonym
Submit and pray Anonymus
Was verbirgt sich hinter dem Kürzel R/3?
Bedeutung: Quelle:
R: realtime-processing - Echtzeitverarbeitung webmaster@sap-ag.de
3: Dreistufige Client/Server-Architektur
www.fh-brandenburg.de/~sap_r3/info/w_sap.htm

Ich erinnere mich noch gut an meine Probleme mit der SAP-Terminologie. Selbstverständlich braucht jede technische Disziplin eigene Begriffe um Sachverhalte effektiv zu beschreiben, die sich von der Begriffswelt anderer Disziplinen unterscheiden, eben einen eigenen Wortschatz (und dieser Artikel ist selbst ein anschauliches Beispiel dafür). Daher hat bei mir z.B. ein Satz wie: "Für die Realisierung des Cut-over-Plans müssen die Change Requests für das Rollout der zweiten Tranche bis zum x. x. 2003 abgenommen werden" zwar zunächst völliges Unverständnis hervorgerufen, aber gleichzeitig meine Neugier erweckt , die Definition der mir unbekannten Begriffe zu erforschen. Größere Schwierigkeiten hatte ich immer mit Aussagen wie: "Für die detaillierte Kostenverfolgung müssen statistische Innenaufträge angelegt werden". Das klingt zunächst wie ein ganz normaler Satz und doch erweckt er keinerlei brauchbare Assoziationen. Dieses Kauderwelsch, das natürlich den SAP-Gurus und -Beratern flüssig von den Lippen kommt, erschwert es dem SAP-Novizen ohne betriebswirtschaftliche Vorbildung, das unglaublich mächtige betriebswirtschaftliche Werkzeug auf Anhieb zu verstehen.

Das Vorhaben, innerhalb von 18 Monaten 21 Unternehmen auf SAP R/3 umzustellen und gleichzeitig völlig neue Rahmenbedingungen für das Rechnungswesen einzuführen, war gelinde gesagt äußerst ambitioniert. Es gibt weltweit dafür kein Referenzmodell. Die TU München hat z.B. für ihre SAP-Einführung einen Zeitraum von 30 Monaten geplant (siehe auch den nett geschriebenen Newsletter "SAPalott" [3]). Der Ansatz des Generalunternehmers bestand daher in der ziemlich strikten Anwendung der Standardempfehlungen von SAP für die Einführung ihres Produkts in Unternehmen. Das gilt sowohl für die Definition der Teilprojekte als auch für die Projektorganisation und die verwendete Terminologie (siehe auch zum SAP Glossar [4]).

Die 6 Teilprojekte von uni.verse

Organisationsentwicklung
  Erarbeitung eines betriebswirtschaftlichen Modells
  Definition der Aufbau- und Ablauforganisation
  Unterstützung beim Change Management
SAP-Einführung
  Erstellung der Feinkonzepte auf Basis der Ergebnisse der Organisationsentwicklung
  Erstellung des Universitäts-Masters
Roll-Out und Schulung
  Durchführung aller Schulungen
  Adaptierungen des Universitäts-Masters an individuelle Anforderungen der Universitäten
Technik und Entwicklungen
  Bereitstellen der SAP-Systeme und Netzanbindungen
  Erstellen der Schnittstellen
  Datenübernahme aus Altsystemen
Betrieb und Services
  Betrieb der SAP-Systeme und Schnittstellen
  Betrieb des Desks im 2nd-Level-Support
Produktivsetzungsplanung

Abbildung 1

Abbildung 1: Projektorganisation uni.verse

Als "Aufsichtsrat" des Projekts uni.verse agiert der Lenkungsausschuss. Er setzt sich aus von der Österreichischen Rektorenkonferenz nominierten Vertretern der Universitäten, des BMBWK, des BMF, des BRZ, des Instituts für Verwaltungsmanagement der Universität Innsbruck (als Koordinator vom BMBWK beauftragt) und von Siemens Business Services zusammen.

Der Koordinationsausschuss hat die Aufgabe, alle Universitäten einzubinden. Er wird regelmäßig über den Projektstand informiert, Inhalte werden diskutiert und bei Bedarf angepasst. Jede Universität hat einen Vertreter in den Ausschuss nominiert. Ihm kommt de facto keine Entscheidungsfunktion zu.

Die wesentlichen Entscheidungen werden vom Projektmanagement getroffen. Es ist für die Führung und Steuerung des Projektes verantwortlich und setzt sich aus jeweils einem Vertreter der Universität Wien, des Instituts für Verwaltungsmanagement, der Bundesrechenzentrum GmbH, der Firma SAP AG und der Firma Siemens Business Services GmbH zusammen. Der Lenkungsausschuss segnete meistens die Entscheidungen ab, die dann dem Koordinationsausschuss zur Kenntnis gebracht wurden.

An jeder Universität musste ein lokales Projektteam und ein lokaler Lenkungsausschuss eingesetzt werden. Zum Projektleiter an der TU Wien wurde Herr Mag. Christian Spranger (PCE) bestellt, zu seiner Stellvertreterin Frau Amtsdir. Eva Glatzer (Leiterin der Quästur). Ich bin Leiter des Teilprojekts "Technik & Entwicklung".

Die Entwicklung eines einzigen "Masters" für alle Universitäten, dessen Voreinstellungen dann im "Roll-out" durch ein von SAP-Beratern durchgeführtes "Customizing" an die Bedürfnisse der jeweiligen Universität angepasst werden sollte, hat sich in der Realität als nicht unproblematisch erwiesen. So hat sich bald herausgestellt, dass die strategische Vorgabe der Universitätsleitung der TU Wien, SAP so "dezentral als möglich" einzuführen, um die bei uns so wichtigen Drittmittelaktivitäten in der Universität halten zu können, weiter vom "Master" entfernt war als im Projekt vorgesehen. In zahlreichen TU-internen Workshops wurden die für uns wichtigen Geschäftsprozesse analysiert und dokumentiert. Selbst so komplizierte Abläufe wie die Umbuchungen bei Telefongebühren, Softwarelizenzen und Dienstleistungen des ZID konnten zufriedenstellend abgebildet werden. Andere gewünschte Prozesse führten zu "Change Requests", das sind Änderungswünsche, für deren Realisierung die antragstellenden Universitäten aus Eigenmitteln aufkommen mussten.

Es ist der TU Wien dank des enormen Einsatzes unserer Projektleitung und des unschätzbaren Know-Hows von Herrn Dr. Alexander Redlein und seiner Gruppe - die in Zukunft als lokales SAP-Kompetenzzentrum der TU Wien ("CCC" = Customer Competence Center als Dienstleistung des neu geschaffenen Zentrums für Informations- und Facility-Management) tätig sein werden - und den wirklich guten Roll-out Beratern von IBM und SBS gelungen, mit vertretbaren Kosten die strategisch notwendigen "Change Requests" zu realisieren. Einige unserer Forderungen wurden sogar nachträglich ins zentrale Master-Konzept übernommen und ihre Realisierung vom BMBWK finanziert, wie z.B. die ursprünglich nicht vorgesehene, scheinbar triviale Forderung, dass dezentrale Organisationseinheiten nicht berechtigt sein dürfen, die Konten anderer Organisationseinheiten einzusehen oder gar zu bebuchen.

Das CCC der TU Wien hat es auch übernommen, die TU-spezifischen Schulungsunterlagen zu erstellen (SBS war nur für den Master beauftragt), die Endanwenderschulungen durchzuführen, den so genannten "First-Level Support" durchzuführen (an den Betreiber BRZ dürfen sich nur qualifizierte "Key-User" unter Verwendung des SAP-Tools SLF / "Support Line Feedback" wenden) und die Zugangssoftware an den Instituten zu installieren.

Den Universitäten wurden und werden vom BMBWF gemäß § 141 Abs. 4 UG 2002 unter dem Titel "Implementierungskosten" die Kosten für die SAP-Lizenzen, die Entwicklungskosten von uni.verse sowie die Betriebskosten von uni.verse und uni.pers drei Jahre lang (2004 - 2006) neben dem Globalbetrag extra zugewiesen, ab dem Jahr 2007 sind dann die Betriebskosten im Rahmen der Leistungsvereinbarungen zu verhandeln und von den Universitäten aus dem laufenden Budget zu bezahlen.

Für den Betrieb der IT-Verfahren uni.verse und uni.pers sind von den einzelnen Universitäten Verträge mit dem BRZ abgeschlossen worden bzw. stehen unmittelbar vor dem Abschluss. Da das BRZ aufgrund gesetzlicher Bestimmungen weder Gewinne machen noch Verluste schreiben darf, müssen die Kosten für die Anschaffung und den Betrieb der Server-Hardware (Details siehe später) in den Betriebskosten mitkalkuliert werden. Das hat zu einer Mindestbindungsdauer von jeweils 5 Jahren (uni.verse 2004 - 2008, uni.pers 2005 - 2009) geführt. Wünscht eine Universität dennoch einen früheren Ausstieg aus dem Vertrag, so sind dem BRZ die dadurch nachweislich entstandenen Kosten - im Wesentlichen die verbleibenden Abschreibungsanteile der Hardwareinvestition - zu ersetzen.

Für mich sind die Universitäten ein wenig in die Situation von Kindern geraten, für die die wohlmeinenden und fürsorgenden Eltern eine verpflichtend mehrjährige Vereinsmitgliedschaft organisiert haben, den Mitgliedsbeitrag vom Taschengeld einbehalten aber gleichzeitig verlangen, dass die Kinder die Beitrittserklärung selbst unterschreiben, weil sie ja demnächst volljährig werden.

Einige Aspekte der SAP-Basistechnologie

Die SAP AG ist mit 29.000 Mitarbeitern und 7,4 Mrd. Euro Umsatz Europas größtes Softwarehaus und Weltmarktführer bei betrieblicher Software. Über 60.000 Installationen in mehr als hundert Ländern haben SAP R/3 dabei zu einem Quasi-Standard gemacht. Allerdings sind in dieser mächtigen Software bereits so viele Möglichkeiten "standardisiert", dass bei der SAP-Einführung durch ein kompliziertes Customizing - meist unter Einbeziehung von speziell geschulten SAP-Beratern - die gewünschten, aber meist im Vorhinein vom Unternehmen noch nicht genau spezifizierten, Geschäftsprozesse modelliert werden müssen. Der voreingestellte Standard dient als "Reibebaum" zur Begründung von Änderungen.

Die SAP-Basistechnologie beruht auf einer drei-schichtigen Client/Server-Architektur, wobei diesen Schichten innerhalb der Software jeweils spezifische Aufgaben zukommen. Im Einzelnen sind dies:

Diese klare Trennung ermöglicht einerseits die Verteilung der Schichten auf verschiedene Rechner (vertikale Verteilung) und andererseits die Ausführbarkeit einer Schicht auf verschiedenen Rechnern bzw. Prozessoren gleichzeitig (horizontale Verteilung). Die Anwender benötigen lediglich die Präsentationsschicht auf ihrem Arbeitsplatzrechner, während die Applikations- und die Datenbankschicht auf separaten Servern installiert und ausgeführt werden können (siehe [5]).

Abbildung 2

Abbildung 2: 3-Schicht Architektur von SAP R/3, (Quelle: IWI, www.iwi.uni-hannover.de)

Der normale R/3-Anwender, der die betriebswirtschaftlichen Funktionalitäten nutzt, benutzt als Arbeitsmittel ausschließlich die Präsentationsebene in der Form des SAP GUI. Zur Unterstützung unterschiedlichster Frontend-Hardware werden verschiedene SAP GUI-Realisierungen angeboten (siehe [6]).

Abbildung 3

Abbildung 3: Front-End Varianten, aus [6])

In der derzeit bei uni.verse eingesetzten Release 4.6c von SAP R/3 hat der SAP GUI für Windows den Vorteil, dass er als einziger den vollen Funktionsumfang der Präsentationsebene unterstützt. Nur im SAP GUI für Windows gibt es die Möglichkeit, für ABAP-Programme (ABAP steht für "Advanced Business Application Programming" und ist eine von SAP geschaffene Programmiersprache für die Entwicklung von Anwendungsprogrammen im R/3-System), eine direkte Kommunikation mit beliebten Werkzeugen wie Excel über das SAP-Schnittstellenprotokoll RFC (Remote Function Call) und das Microsoft-Schnittstellenprotokoll OLE/2 (Object Linking and Embedding) aufzubauen. Dadurch kann R/3 z.B. über das SAP GUI auf die Daten eines Excel-Spreadsheets in beiden Richtungen zugreifen. Auch der Zugriff auf den Windows-Standarddrucker vom zentralen Drucker-Spooler des R/3-Systems erfolgt derzeit nur mit dem SAP GUI für Windows problemlos.

Der SAP GUI für HTML (Web-GUI) benötigt auf den Frontends nur einen Webbrowser, zur Umwandlung der Darstellung der Masken in HTML ist allerdings die Installation eines eigenen Internet Transaction Servers (ITS) erforderlich.

Abbildung 4

Abbildung 4: Protokollumsetzung durch einen ITS, (aus [5])

Der ITS konvertiert automatisch SAP-Bildschirme in HTML-Seiten, wobei er für ausgewählte Transaktionen vorgefertigte HTML-Darstellungen benutzt. Beim horizontalen Scrollen in breiten Masken muss allerdings jedesmal eine neue HTML-Seite erstellt werden, was zu merkbaren Performance-Verlusten führt.

Erst mit der neuen Release 4.7 (SAP R/3 Enterprise) steht mit dem SAP Web Application Server eine neue Laufzeitumgebung zur Verfügung, die neben ABAP- auch Java-Programme in der Applikationsschicht ausführen kann. Da uni.pers bereits auf der Release 4.7 implementiert wird, steht im Jahr 2004 für uni.verse ein Release-Wechsel ins Haus. Das bedeutet zwar für die Universitäten einen zusätzlichen Aufwand, da die speziellen Customizing-Einstellungen und Change Requests erneut überprüft und abgenommen werden müssen, bietet aber auch eine Chance, die neue SAP-Technologie zu nutzen.

Die R/3-Softwarearchitektur erlaubt eine Verteilung der Applikationsebene auf mehrere so genannte "Instanzen", die auch auf getrennten Rechnern betrieben werden können. Eine R/3-Instanz ist eine Gruppe von Prozessen mit dazugehörigen gemeinsam genutzten Speicherbereichen, die durch einen Dispatcherprozess gesteuert werden und auf dieselbe Datenbank zugreifen.

Ein "Mandant" hingegen ist eine betriebswirtschaftlich selbständige Einheit. Sie umfasst auch eigenständige Bilanzen. Das Customizing wird vorwiegend mandantenabhängig vorgenommen. Es gibt allerdings Daten in der R/3-Datenbank, die systemweit gültig sind. Dazu gehören unter anderem ABAP-Programme, Funktionsbausteine und fast alle technischen Einstellungen. Diese Daten können durch mandantenunabhängiges Customizing verändert werden und betreffen alle Mandanten innerhalb einer Instanz. "Somit eignen sich Mandanten innerhalb eines R/3-Systems z.B. für die Realisierung relativ unabhängiger Betriebsteile, weniger aber für die Umsetzung betriebswirtschaftlicher Abläufe vollständig unabhängiger Unternehmen" (zitiert nach [5]).

In uni.verse wurden nur zwei Instanzen eingerichtet. Eine für die Wirtschaftuniversität und eine für alle anderen 20 Universitäten. Genauer gesagt gilt das jeweils für das Entwicklungssystem, das Qualitätssicherungssystem und das Produktionssystem, die alle auf eigenen Instanzen und einer eigenen Hardware im BRZ laufen. Die Ausnahme für die WU resultiert aus der Tatsache, dass für die WU bereits seit einiger Zeit eine SAP-HR Lösung zur Personalverwaltung im Einsatz ist und die dafür notwendigen speziellen Einstellungen nicht auch für die anderen Universitäten übernommen werden konnten. Da sich die Universitäten eher früher als später zu eigenständigen und von einander unabhängigen Unternehmen entwickeln werden, die unterschiedliche Anforderungen an die Einführung neuerer SAP-Technologien und damit zusammenhängend an mandantenübergreifenden Einstellungen stellen werden, sind einerseits Konflikte zwischen den Universitäten und andererseits vermehrte Kosten für die an Innovation interessierten Universitäten absehbar und unvermeidlich.

Die Infrastruktur von uni.vers

Sowohl für die Implementierung von SAP R/3 als auch für den Produktivbetrieb musste eine entsprechende Serverhardware zur Verfügung gestellt werden. Die Hardware wurde vom BRZ bei HP beschafft und wird vom BRZ für die Universitäten betrieben. Grundlage war die Empfehlung von SAP, für R/3 ein dreistufiges System (Entwicklung, Qualitätssicherung und Produktion auf je einer eigenen Instanz) zu verwenden. Aufbauend auf diesen Vorgaben wurde von HP in Abstimmung mit dem BRZ ein Konzept vorgelegt, das der Lenkungsausschuss von uni.verse angenommen hat.

Der Vorschlag zur Realisierung der Serverhardware für den Produktivbetrieb ging dabei von folgenden Annahmen aus:

Für HP waren für die Dimensionierung der Serverhardware ("Sizing") die folgenden SAP-Benutzerklassen von Bedeutung, die sich aus dem geschätzten Zugriffsverhalten ableiten lassen.

Nach Abstimmung mit dem Projektmanagement wurde die hypothetische Systemlast der User folgendermaßen aufgeteilt:

High User: 10% der Professional User (Gleichzeitigkeit: 40%)
Middle User: 90% der Professional und 50% der Limited User bzw. Institutsuser (Gleichzeitigkeit: 40%)
Low User: 50% der Limited und 100% der Berichtsuser (Gleichzeitigkeit: 20%)

Mit Professional, Limited, Instituts- und Berichtsuser sind die vier Typen von SAP-Lizenzen gemeint, die für uni.verse vom BMBWK für und nach den Anforderungen der Universitäten angeschafft wurden. Es handelt sich dabei um personenbezogene Lizenzen, die den mit Username und Passwort geschützten Zugang zur SAP R/3-Applikation ermöglichen.

Für die Berichtsuser wird, abgesehen von einem Puffer von 50 GB (für temporäres Abrufen von Berichten) kein Speicherplatz am Server bzw. SAN vorgesehen. Diese Vorgangsweise wurde damit begründet, dass Berichtsuser keine Daten auf dem SAP-System speichern und lediglich ein bestimmter Swap-Space zur Verfügung stehen muss. Als weiterer Parameter für die Dimensionierung wurde berücksichtigt, dass die Session eines ITS-Benutzers automatisch geschlossen wird, nachdem dieser zehn Minuten am System inaktiv ist.

Die SAP-R/3 Produktivinstanz wird an zwei getrennten Standorten auf HP Superdome Systemen als MC/ ServiceGuard Cluster abgebildet und wird hochverfügbar im Bundesrechenzentrum bzw. im Parallelrechenzentrum betrieben. Die Instanz für BW (SAP Applikation Businesswarehouse) wird ebenfalls hochverfügbar in einer HP-UX-Partition auf diesen Systemen betrieben.

Abbildung 5

Abbildung 5: Serverhardware für das Produktionssystem im BRZ

Ein MC/ServiceGuard Cluster ist ein hochverfügbares System von HP 9000 Serie 800 Servern ("Nodes"), das genügend Redundanz an Hardware- und Softwarekomponenten besitzt, damit kein "single point of failure" zu einer Unterbrechung des Services führt. Anwendungsprozesse werden in "Packages" zusammengefasst. Im Falle eines einzelnen Fehlers eines Services, einer Betriebssystemkomponente, einer CPU, eines Speicherblocks, eines Nodes, eines Netzwerks oder einer anderen überwachten Ressource, kann der MC/ServiceGuard automatisch die Kontrolle des Packages auf einen anderen Node im Cluster transferieren, sodass die Services nach einer minimalen Unterbrechungszeit verfügbar bleiben.

Abbildung 6

Abbildung 6: MC/ServiceGuard Cluster Konfiguration

Abb. 6 zeigt die Situation eines typischen MC/Service Guard Clusters. Das Package A läuft auf Node 1, Package B auf Node 2. Jedes Package hat eine eigene Gruppe von zugeordneten Platten, die auch noch gespiegelt sind (Raid). Obwohl beide Nodes physisch an beide Raids angeschlossen sind, hat immer nur einer der beiden Nodes den exklusiven Zugriff (durchgezogene Linie). Das Netzwerk ist ebenfalls redundant ausgelegt. MC/ServiceGuard verwendet TCP/IP auch für die Übertragung und Überwachung von "heartbeat messages", die einen normal funktionierenden Node signalisieren.

Abbildung 7

Abbildung 7: MC/ServiceGuard Cluster nach Failover

Im Fehlerfall überträgt MC/ServiceGuard die Kontrolle des Packages A auf den nächsten verfügbaren Node. Abb. 7 zeigt die Situation nach der erfolgreichen Fehlerübergabe. Auf Node 2 laufen jetzt beide Packages (natürlich mit einer reduzierten Performance) und Node 2 hat exklusiven Zugang zu beiden Raids.

Weil der MC/ServiceGuard Cluster im BRZ die Superdome Nodes an zwei Standorten mit einer redundanten Anbindung an das SAN und LAN einsetzt, wird wirklich eine höchstmögliche Verfügbarkeit der Applikationen von uni.verse gewährleistet.

Die beiden Systeme werden in je zwei Hardware-Partitionen unterteilt:

Server 1:

Npar0: SAP BW6 CPUs PA8700 875 MHz, 12 GB RAM
Npar1: SAP R/36 CPUs PA8700 875 MHz, 18 GB RAM

Server 2:

Npar0: SAP BW6 CPUs PA8700 875 MHz, 12 GB RAM
Npar1: SAP R/36 CPUs PA8700 875 MHz, 18 GB RAM

Das Entwicklungssystem wird auf einem HP rp5470 Server und das Qualitätssicherungssystem auf einem HP rp7410 Server laufen. Beide Server verfügen über jeweils 6 CPUs PA8700 750 MHz und 9 GB RAM .

Zugang über ACOnet und "Portal Austria"

Der Wunsch der Universitäten, über das ACOnet auf die bereitgestellten Applikationsserver im BRZ mittels SAP GUI bzw. Web-GUI/ITS zugreifen zu können, wurde berücksichtigt. Das BRZ hat einen Zugang zu ACOnet im Rahmen des "ACO-IX" erhalten, der genügend Bandbreite für den Applikationszugriff zur Verfügung stellt. Nach den internen Richtlinien des BRZ muss für den Zugriff vom Internet auf Applikationen, die vom BRZ bereitgestellt werden, das "Portal Austria" als Schnittstelle fungieren. Die Applikation uni.verse wurde daher ins "Portal Austria" integriert.

Abbildung 8

Abbildung 8: Schematische Darstellung der Systemlandschaft im BRZ

Im Rahmen des "Portal Austria" soll es berechtigten Benutzern ermöglicht werden, einfach und einheitlich auf Funktionalitäten von SAP R/3 zugreifen zu können, ohne sich explizit bei einer bestimmten Applikation anmelden zu müssen. In diesem "Single Sign On"-Verfahren werden dem Benutzer automatisch alle ihm zugeordneten SAP-Module zur Verfügung gestellt und er kann aus dem Browser den SAP GUI für Windows oder den SAP-Web-Client (SAP GUI für HTML) starten. Da das System SAP R/3 derzeit über keine befriedigende Lösung zur erforderlichen Datenverschlüsselung bei der Kommunikation mit dem SAP GUI für Windows verfügt, wird eine sichere Datenübertragung über ein VPN (Virtuelles Privates Netzwerk) gewährleistet. Der VPN-Konzentrator im BRZ kann bis zu 5000 Client-Sitzungen simultan betreiben. Der sichere Zugang zum ITS erfolgt über Secure Socket Layer (SSL).

Das "Portal Austria" wird auch als Werkzeug für die Verwaltung der einzelnen Benutzer eingesetzt. Über die verteilte Administration ist es den Administratoren der Universitäten vorbehalten, entsprechende Berechtigungen zu vergeben und diese auch in ihrem Bereich unbürokratisch zu verwalten. Für die TU Wien wird diese Tätigkeit vom CCC durchgeführt.

Anforderungen an die Hard- und Software auf Seiten der Institute (Clients)

Im Folgenden werden kurz die Empfehlungen und Vorgaben seitens der Projektleitung zur Abdeckung der Leistungsanforderungen für Applikationen rund um uni.verse vorgestellt. Die technischen Voraussetzungen beziehen sich dabei nicht nur auf den Einsatz der SAP GUIs, sondern auch auf die Verwendung von Applikationen wie Internet-Browser und Microsoft Office. Bei Neubeschaffung von Rechnern sollte darauf geachtet werden, dass damit zumindest zwei Jahre ohne Einschränkung, und danach ein Jahr ohne unzumutbare Verzögerungen und Wartezeiten, gearbeitet werden kann.

Der ZID bietet im Rahmen der "Systempflege für Arbeitsplatzrechner" (sts.tuwien.ac.at/pss/) an, die Tauglichkeit eines Institutsarbeitsplatzes als SAP R/3-Client zu überprüfen bzw. herzustellen. Die notwendige Zugangssoftware (SAP GUI und VPN Client) steht im Rahmen der Campus Software zum kostenlosen Download bereit. Die Installation der Zugangssoftware wird in der Regel vom CCC der TU Wien durchgeführt.


Anforderungen an die Hardware (Empfehlungen)

CPU:
Intel Pentium III ab 1000 MHz (FC-PGA)
Intel Pentium 4 ab 1,5 GHz (Socket-478)
AMD Athlon XP ab 1200 MHz (Socket-A)

Hauptspeicher:
256 MB DIMM / 133 MHz
256 MB DDR-DIMM / PC 2100
256 MB RIMM / 800 MHz

Festplatte:
40 GB E-IDE (UDMA-100)
36 GB SCSI-LVD

CDROM:
40fach CDROM (ATAPI, SCSI)
10fach DVD-ROM (ATAPI, SCSI)

Grafikkarte:
AGP-Grafikkarte (16MB)

Netzwerk:

10/100 Mbit PCI Netzwerkkarte Ethernet

Monitor:
17 Zoll CRT / 96 kHz
19 Zoll CRT / 110 kHz
15 Zoll LCD / TFT Analog
17 Zoll LCD / TFT DVI

Tastatur:
104 Tasten Windows-kompatibel (mit Euro-Symbol)
105 Tasten IBM-kompatibel (mit Euro-Symbol)

Maus:
n Tasten PS/2 oder seriell mit Scrollrad
n Tasten PS/2 oder seriell mit Scrollrad und optischer Abtastung

Audiokarte:
"Soundblaster Live!"-kompatible PCI-Karte
Audiokarte "OnBoard"

Lautsprecher:

Computer-Lautsprecher Leistung min. 10 Watt
Mikrofon mit PC-Anschluss (ohne Phantom-Speisung)
Aktive Kopfhörer (Impedanz kleiner als 200 Ohm)

Anmerkung: Im Projekt uni.verse könnten diverse Schulungen im Multimedia-Format vorgetragen werden. Um multimediale Schulungsinhalte verstehen zu können, wird ein Schallwandler benötigt. Wenn es sich um eine Lern-Station handelt oder der Benutzer ein Einzelbüro hat, so können ohne weiteres aktive Lautsprecher verwendet werden. In Großraumbüros ist die Verwendung von Kopfhörern anzuraten, um weitere Kollegen nicht bei der Arbeit zu stören.


Anforderungen an die Software (Vorgaben)

Betriebssystem:
Windows NT 4.0 SP6a:
(Es wird darauf hingewiesen, dass Windows NT von Microsoft nicht mehr in der Wartung steht.)
Windows 2000 SP2
Windows XP
Windows 98SE (nicht secure !)

Anmerkungen:
Für Betriebssysteme auf Apple Computer steht kein eigener SAP-GUI zur Verfügung. Der SAP GUI für HTML kann mit Einschränkungen verwendet werden, der SAP GUI für Java kommt erst Mitte 2004 (Release 4.7). Windows 2003 Server funktioniert derzeit nicht.

Viewer Tools:
Als Viewer Tool ist Adobe Acrobat Reader ab der Version 4.05 erforderlich.

Web-Browser:
Für die Anzeige der On-line-Hilfe ist alleinig der MS Internet Explorer ab der Version 6.0 SP1 zulässig, da Netscape Navigator aufgrund einer anderen internen Objektstruktur nicht kompatibel ist.

Office-Integration:
SAP R/3 bietet ein COM-Gateway zu Microsoft Excel. Für das Anzeigen von Berichten ist somit der Einsatz von Excel ab der Version 97 erforderlich. Es sei darauf hingewiesen, dass vom gesamten Office- Paket nur Excel benötigt wird, welches auch unterstützt wird.


Anforderungen an die Zugangssoftware (Vorgaben)

SAP-GUI für Windows:
SAP-GUI 6.20 (GUI-Patchlevel 36, BW-Patchlevel 9)

VPN-Client:
Cisco VPN-Client 4.0.1

Portal Austria-Integration:
Java Runtime Environment 1.4.2_01
Files für die Portal Austria-Integration (SSO-Client)

Anmerkung: Die Softwarepakete sind am Softwaredistributionserver des ZID hinterlegt.


Schlussbemerkung

Dieser Artikel ist zwar ziemlich lang geworden und doch konnte ich nicht über alles schreiben, was ich gerne losgeworden wäre. So ist zum Beispiel die Frage der Schnittstellen zu anderen Systemen spannend wie ein Krimi. Im Projekt uni.verse wurden bisher vom Lenkungsausschuss nur die Schnittstellen zum Bibliothekssystem ALEPH und zur Bundesbesoldung in Auftrag gegeben. Was wird mit den anderen Schnittstellen geschehen, die für "ein möglichst reibungsloses Zusammenspiel mit den IT-Anwendungen der Universitäten" (Projektauftrag) so wichtig sind? Was wird das die TU Wien kosten? Welche Schnittstellentechnologien werden möglich, welche davon wirklich eingesetzt werden? Fünf Jahre sind eine lange Zeitspanne, in der sich auch die Technologiekonzepte der SAP AG und des BRZ mehrfach ändern werden. Können wir uns zurücklehnen und einfach freuen, wenn die Bilanz richtig herauskommt?

Den Universitäten wurden im Projekt eine ganze Reihe von Pflichten und Verantwortlichkeiten auferlegt. Erwähnt habe ich schon die Administratoren der User am "Portal Austria", die Verantwortung für die Endanwenderschulung, die "Key-User" und den "First-Level Support". Nicht erwähnt habe ich die aufwendige Einrichtung und Pflege der Rollen und Berechtigungen im R/3-System, die bei einer dezentralen Nutzung wie an der TU Wien einen wirklich großen Aufwand darstellt. Nicht erwähnt habe ich den hohen Aufwand für die Pflege der Stammdaten, zu denen auch Kostenstellen, Finanzstellen, Innenaufträge und vieles mehr gehören. Nicht erwähnt habe ich die Schnittstellenverantwortlichen, die die Transaktionslogs kontrollieren und im Fehlerfalle die richtigen Aktionen setzen müssen. Was machen Universitäten, die nicht bereits mit einem so großen SAP Know-How starten konnten wie wir? Steht überall der Aufbau von lokalen CCCs auf der Tagesordnung? Werden wir uns in Zukunft nur mehr mit SAP beschäftigen?

Ich glaube nicht. Erstens werden wir es nach einer gewissen Anlaufphase sicher schaffen, mit den neuen rechtlichen Randbedingungen und der betriebswirtschaftlichen Software zurechtzukommen. Und zweitens wird es andere neue und spannende Projekte geben.

Literatur

[1] Projekt Homepage "uni.verse" www.uni.verse.at

[2] Universität Innsbruck, Projekt SAP www2.uibk.ac.at/fakten/leitung/rektor/sap/

[3] Newsletter zur SAP-Einführung an der TU München: www.sap.tum.de/sapalott.html

[4] SAP Glossar: help.sap.com/saphelp_46c/helpdata/de/35/2cd77bd7705394e10000009b387c12/frameset.htm

[5] SAP R/3 Systemadministration. Sigrid Hagemann, Liane Will, SAP Press, 2003

[6] mySAP Technology. Günther Färber, Julia Kirchner, Galileo Press, 2003


Seitenanfang | ZIDline 9 - Dezember 2003 | ZID | TU Wien