NewsletterCampusmanagementAusgabe 11 | März 2017

ERM SLMCAMPUS-

MANAGEMENT

ERM SLM

Editorial Schrittweiser Einstieg

Der veränderte Ablaufplan für die SAP-Einführung bedeutet im Kern den schrittweisen Einstieg in das integrierte Software-Sys-tem. Mit diesem – von Präsident Thomsen als „Smart Start“ bezeichneten – Vorgehen folgt das ERM-Projekt den Erfahrun-gen des SLM-Projekts, das ebenfalls auf ein allmähliches Ken-nenlernen der Anwendungen und zeitlich entzerrte Schulungen setzt. Dies ist nicht nur eine wesentliche Entlastung für die Nut-zerinnen und Nutzer, vor allem ermöglicht es, die notwendigen organisatorischen Veränderungen und den Kompetenzaufbau an der TU Berlin voranzutreiben. Denn bevor SAP in den Regel-betrieb geht, müssen eine Reihe von neuen Aufgaben, Funkti-onen bis hin zu neuen Supportstrukturen definiert und organisatorisch verankert werden. Stichworte sind Key User, First-Level-Support oder Softwaretests. In dieser Ausgabe wird der Stand zu diesen und weiteren Vorbereitungen dargestellt.

Deutlich geworden ist, die SAP-Einführung an der TU Berlin ist nicht nur ein IT-Projekt, sondern vor allem ein Organisations-entwicklungsprojekt.

ThemenVeränderter Projektplan bei ERM zur SAP-EinführungDie neue SAP-Software geht ab Januar 2018 in mehreren Etappen an den Start

Nachgefragt: Wie läuft der SAP-Pilotbetrieb für die Fachgebiete? Drei Monate Pilotphase im Prüfungsmanagement

Key User und Prozess-ExpertInnen im SAP-ProjektBeschäftigte unterstützen den Auf- und Ausbau der neuen SAP-Software

AManDa: neues Drittmittelprojekt-Informationssystem mit Volltextsuche Neuentwicklung von SAP für die TU Berlin

Organisationsmanagement Die Abbildung der Organisationsstruktur wird überarbeitet und erweitert Zeiterfassung mit SAP? Zwei neue Dienstvereinbarungen im Zuge der SAP-Einführung

Wie und was wird eigentlich an der SAP-Software getestet? Vom Fachkonzept zum Testergebnis im ERM-Projekt

Was ist eigentlich ein Change Request (CR)? Änderungsanforderung der Leistungsbeschreibung im Campusmanagement

Arbeitsalltag im Fachgebietssekretariat Und welche der Aufgaben bald in SAP erledigt werden

Veranstaltungen Impressum und Kontakt

03

04

05

07

08

09

10

11

12

13

Immer auf dem neuesten Stand

Abbonnieren Sie unseren RSS-Feed und erhalten Sie per Outlook aktuelle News aus dem Campusmanagement.

Direktzugang ▶ 180900

Lesetipp

Lesetipp

Lesetipp

Go-Live 2018 von drei ERM-Modulen

Organisationsmanagementbildet die Organisationsstruk-

tur der TU Berlin ab.

x

Identitätsmanagementordnet den NutzerInnen

des SAP-Systems Rollen und Berechtigungen zu.

Personaladministrationverwaltet die Personalstamm-

daten der Beschäftigten.

Themen | 03

Newsletter Campusmanagement | Ausgabe 11 | März 2017

Veränderter Projektplan bei ERM zur SAP-Einführung Die neue SAP-Software geht ab Januar 2018 in mehreren Etappen an den Start

Für die SAP-Einführung im ERM-Projekt ist ein veränderter Ablaufplan vom Lenkungsausschuss beschlossen worden. Die integrierte SAP-Software wird ab 1. Januar 2018 bis ins Jahr 2019 hinein in mehreren Schritten ein-geführt. Zuerst gehen im ERM-Projekt die Module Organisationsmanage-ment, Identitätsmanagement und der Bereich Personaladministration an den Start. Zur Ausweitung des Pilotbetriebes von SLM ist die Etablierung dieser drei Module Voraussetzung. Mit der Entzerrung der Einführungs-phase können die Beschäftigten sowie die gesamte Universität nach und nach die neuen Anwendungen kennenlernen. Bei SLM wird der Zeitplan mit den Erfahrungen aus der Pilotphase ebenfalls überarbeitet. Aufgabe des Organisationsmanagements ist, im SAP-System erstmalig die vollständige Organisationsstruktur der TU Berlin abzubilden. Sie ist die Grundlage für das Zusammenspiel aller weiteren SAP-Module. Sichere IT-gestützte Arbeitsabläufe – wie sie durch SAP realisiert werden – können nur dann eingeführt werden, wenn klare Strukturen mit festgelegten Aufgaben und Verantwortlichkeiten definiert sind. Je besser die Abbildung, desto geringer ist der Aufwand für Nutzung, Pflege und Weiterentwicklung des Systems.

Auf dieser Basis wird das Identitätsmanagement zunächst denjenigen Nut-zerInnen Rollen und Berechtigungen zuordnen, die im Bereich SLM mit dem neuen SAP-System arbeiten. Die Verwaltung von Personaldaten wird ebenfalls ab 2018 in SAP durch-geführt werden. Zuvor müssen die Daten ins neue System überführt werden.

ERM

SLM kann weitere Funktionalitäten ausbauen.

04 | Themen

SLMNachgefragt: Wie läuft der SAP-Pilot-betrieb für die Fachgebiete? Drei Monate Pilotphase im Prüfungsmanagement

Seit Dezember 2016 läuft für das Prüfungsmanagement ein Pilotbetrieb in drei Studiengängen. QISPOS wurde für die Bachelor- und Masterstudien-gänge Physik und Historische Urbanistik abgelöst und das neue Portal tuPORT gestartet. Wir haben nachgefragt: Wie läuft der Pilotbetrieb für die Fachgebiete nach drei Monaten?

„Die Software hat Potenzial, wenn sie richtig läuft. Bis dahin muss noch an ein paar Stellen geschraubt werden“, berichtet Elke Wandke aus ihren ers-ten Erfahrungen. „Der wichtigste Punkt ist die E-Mailbestätigung an Stu-dierende, wenn sie von mir zu einem Prüfungstermin zugeordnet wurden. Diese Funktion soll es in SAP geben, läuft jedoch noch nicht. Deshalb stan-den bereits StudentInnen an meinem Schreibtisch und wussten nur durch Zufall von ihrer Terminzuordnung. Leider kann ich selbst Studierende nicht mehr zu Prüfungen anmelden, wenn sie mir dafür ihr Einverständnis geben. Das war früher möglich, dadurch konnte ich ihnen mehr Service bieten“, merkt sie kritisch an. „Es würde meine Arbeit erleichtern, wenn ich nicht automatisch aus dem System ausgeloggt werde, wenn ich eine Weile darin nicht aktiv bin, beispielsweise wegen Telefonaten. Dadurch muss ich stän-dig neue TANs eingeben, um weiter arbeiten zu können. Da wünsche ich mir Verbesserungen.“ Neben all der Kritik habe sie sich allerdings gut auf die Pilotphase vorbereitet gefühlt. „Ich ging zu den angebotenen Schulun-gen und dort wurden mir meine Fragen kompetent und sympathisch vom SLM-Team beantwortet. Was ich mir noch wünsche, sind frühzeitige und konkrete Informationen per Rundmail – zum Beispiel, wenn neues Infoma-terial bereitgestellt wird oder wenn etwas nicht funktioniert.“

„Die von Frau Wandke angesprochene E-Mailbestätigung an Studierende befindet sich derzeit in den letzten Tests und wird bald freigegeben. Dazu informieren wir dann in einer Rundmail“, fasst Michael Jeschke, Projekt-manager von SLM, zusammen. „Dass FachgebietssekretärInnen Studie-rende nicht zu Prüfungen anmelden können, ist beabsichtigt. Denn bisher wurde damit Arbeit nur verlagert. Wir arbeiten intensiv daran, dass Prü-fungsanmeldungen in SAP vollständig durch die Studierenden selbst erfol-gen können und dadurch auch die bisher notwendigen Nacharbeiten im Referat Prüfungen und die damit verbundenen Rückfragen bei Studieren-den entfallen – ein Gewinn auf beiden Seiten. Den Hinweis auf den zu frü-hen Logout haben wir direkt an die tubIT weitergeleitet. Das war ein Fehler in den Einstellungen, der schnell behoben wurde“, kon kre- tisiert Michael Jeschke.

Diese Rückmeldungen seien, so der Projektmanager, für das SLM-Team sehr wertvoll. Man nehme alle Hinweise auf, analysiere sie und leite dar-aus Maßnahmen und Entscheidungen ab. Dieses Vorgehen ist Bestandteil der Pilotphase. Denn der Zweck eines Piloten ist, den Echtbetrieb in einem zeitlich und sachlich begrenzten Bereich durchzuführen und dabei zu über-prüfen, ob das Verfahren den technischen und organisatorischen Anforde-rungen in der Praxis standhalte. „Wir lernen aus den Erfahrungen, bleiben dran und verbessern“, verspricht der SLM-Projektmanager.

Elke Wandke ist seit 25 Jahren Fachgebietssekretärin an der TU Berlin. Sie arbeitet am Ins-titut für Optik und Atomare Physik, das am Pilotbetrieb beteiligt ist. Sie ist eine der Ersten, die mit der neuen SAP-Software arbeiten.

Weitere Informationen zum Pilotbetrieb und eine Zusam-menstellung der wichtigsten Fakten unter:pilot.sap.tu-berlin.deund unter Direktzugang ▶ 179872.

Themen | 05

Newsletter Campusmanagement | Ausgabe 11 | März 2017

✳Software-Ergonomie hat zum Ziel, die Software leicht verständlich und schnell benutzbar zu gestalten.

Key User und Prozess-ExpertInnen im SAP-Projekt Beschäftigte unterstützen den Auf- und Ausbau der neuen SAP-Software

Bei der Einführung der integrierten SAP-Software an der TU Berlin werden Mitarbeiterinnen und Mitarbeiter als Key User und Prozess-ExpertInnen maßgeblich den Aufbau der neuen Software unterstützen. Was genau unter Key Usern und Prozess-ExpertInnen zu verstehen ist, wird derzeit von der AG Change erarbeitet. Folgende Fragen und Antworten stellen den aktu-ellen Arbeitsstand da: Wie unterscheiden sich die beiden Funktionen und welche Aufgaben werden die Personen erledigen bzw. welche nicht?

Key User in der zentralen VerwaltungKey User sind in der Regel MitarbeiterInnen in der Zentralen Universitäts-verwaltung (ZUV) der TU Berlin, die über ein großes Fachwissen zu ihren Arbeitsprozessen und über das jeweilgie SAP-Modul verfügen und mit den formalen und rechtlichen Anforderungen an diese Prozesse vertraut sind. Im Rahmen des SAP-Projekts passen sie einerseits die SAP-Software an die Prozesse der TU Berlin an – soweit eine Standardsoftware dies erlaubt. Andererseits initiieren sie Anpassungen der Software, wenn sich die Pro-zesse oder rechtliche Rahmenbedingungen ändern. Besonderer Fokus liegt dabei auf Ergonomie✳ und Benutzungsoberfläche. Die Reichweite dieser Tätigkeit hängt u.a. vom Arbeitsbereich, den individuellen Fähigkei-ten der Key User, aber auch vom Zusammenspiel mit dem/der SAP-Modu-ladministratorIn ab. Key User vereinen Prozesskenntnis, eine hohe Kompetenz beim Umgang mit der Software und sind fachliche Ansprech-personen für KollegInnen im eigenen Bereich, für Prozess-ExpertInnen aus den Fakultäten und Zentralen Einrichtungen, für Software-EntwicklerInnen und die SAP-Moduladministration. Key User müssen offen für die Belange anderer Arbeitsbereiche sein und Verständnis für andere Module haben – damit auch das Zusammenspiel der integrierten Software klappt. Deswe-gen kommt ihnen eine besondere Bedeutung zu. Sie sind mit ihrem Wissen und ihrer Motivation wichtig für die TU Berlin. Auf diese verantwortungsvolle Aufgabe werden die zukünftigen Key User durch individuelle Weiterbildungen und IT-Workshops vorbereitet und durch das Change Management und das Teilprojekt Schulungen bei ihrer Arbeit unterstützt.

Was Key User nicht tunIn ihrer Funktion als Key User übernehmen sie keine Programmieraufga-ben, keinen First-Level-Support und sie vergeben keine Rollen und Berechtigungen.

Wie wird man denn Key User?Key User sind in der Regel bereits im Projekt eingebunden. Benannt und gefragt werden sie von den TeilprojektleiterInnen und Dienstvorgesetzten.

CAMPUS-MANAGEMENT

ERM SLM

06 | Themen

Erste Ansprechpartnerin des Key User Managements ist Cynthia Galle.

Zu erreichen ist sie unter Telefon: 24470 E-Mail: cynthia.galle@

tu-berlin.de.

Prozess-ExpertInnen in den FakultätenProzess-ExpertInnen sind MitarbeiterInnen in den Fakultäten und Zentra-len Einrichtungen der TU Berlin. Neben den Key Usern werden Prozess-ExpertInnen für diejeniegen Prozesse benannt, die vor allem die Fakultäten betreffen. Die Prozess-ExpertInnen kennen die jeweiligen Arbeitsabläufe und Rahmenbedingungen der dezentralen Bereiche sowie die fachlichen und rechtlichen Anforderungen innerhalb der Fakultäten. Sie bündeln die Anforderungen der KollegInnen aus den Fakultäten und Zentralen Einrich-tungen und treiben Verbesserungen am System voran, indem sie die Ände-rungen an die Key User weitergeben und im regelmäßigen Austausch mit ihnen stehen. Dadurch bringen sie ihre Erfahrungen in die Prozessgestal-tung ein und empfehlen in Abstimmung mit den Fakultäten den Standard für alle Fakultäten. Diese werden wiederum von den Key Usern umgesetzt bzw. an das SAP-Entwicklerteam weitergegeben. In den Fällen, in denen es für Prozesse keine Key User als Ansprechperson gibt (u.a. Promotion, Lehraufträge), sind gesonderte Rückkopplungswege zu entwickeln. Denk-bar ist, dass die Prozess-ExpertInnen direkt mit den SAP-Moduladminist-ratorInnen zusammenarbeiten. Die Prozess-ExpertInnen stehen fakultätsübergreifend als Ansprechperso-nen für ihre KollegInnen und für Key User zur Verfügung. Sie werden wäh-rend der Projektlaufzeit zentral ins Projekt eingebunden, der Arbeitsplatz verändert sich örtlich jedoch nicht.

Was Prozess-ExpertInnen nicht tunIn ihrer Funktion als Prozess-ExpertInnen übernehmen sie keine Anpas-sungen an der Software und keine Programmieraufgaben, keinen First-Level-Support und sie vergeben keine Rollen und Berechtigungen.

Wie wird man denn Prozess-ExpertIn?Wie die Prozess-ExpertInnen benannt werden, wird derzeit mit den Fakul-tätsverwaltungsleiterInnen besprochen.

Erste Anlaufstelle und BegleitungFür die Projektlaufzeit wird ein Key User Management etabliert. Es ist Anlaufstelle und übernimmt Begleitung sowie Organisation für alle Key User und Prozess-ExpertInnen an der TU Berlin. Das Team besteht aus VertreterInnen des Testmanagements, des Teilprojekts Schulungen, des Teilprojekts Change Management und von SLM.

Themen | 07

Newsletter Campusmanagement | Ausgabe 11 | März 2017

Neu in AManDa: eine universitätsweite web-basierte Volltextsuche

AManDa: neues Drittmittelprojekt- Informationssystem mit Volltextsuche Neuentwicklung von SAP für die TU Berlin

AManDa steht für „Anzeige und Management von Projektdaten“ und wird im Zuge der SAP-Einführung die Basis für ein Drittmittelprojekt-Informati-onssystem der TU Berlin. Gleichzeitig ersetzt AManDa die elektronische Projektanzeige (ePA✳), die von und für die TU Berlin entwickelt worden war.

Geplant ist der Einsatz der neuen Lösung im Bereich Forschung. Nicht nur für die TU Berlin, sondern auch für SAP ist AManDa eine Neuentwicklung, die unsere Universität als erste nutzen wird.

Für AManDa soll die neue SAP-Technologie HANA zum Einsatz kommen. Die HANA-Technologie✳ (High Performance Analytic Appliance; übersetzt: Hochleistungsanalyseanwendung) ermöglicht die Auswertung von inhaltli-chen Daten mit höherer Rechenleistung.

Was verbessert sich mit AManDa? Wie bisher werden die für die Anzeige und inhaltliche Beschreibung eines Drittmittelprojektes erforderlichen Projektangaben über eine nutzerfreund-liche Oberfläche von den Fachgebieten eingegeben. Dazugehörige Unter-lagen, wie Antrag, Kostenkalkulation, Angebote oder sonstige Erklärungen, werden darüber ins SAP-System hochgeladen und sollen – das ist neu – in einer elektronischen Projektakte für alle berechtigten Projektbeteiligten nutzbar abgespeichert werden. Die Kalkulationstools, die für trennungs-rechnungsrelevante Projekte benötigt werden, stehen direkt über AManDa

zur Verfügung. Die Daten selbst werden im integrativen SAP-System gespeichert.

Neu in AManDa ist außerdem die Möglichkeit einer universi-tätsweiten webbasierten Volltextsuche nach inhaltlichen Pro-

jektdaten. Wenn beispielsweise KollegInnen zukünftig herausfinden wollen, welche Projekte es bereits zum Thema X, mit ProjektleiterIn Y oder mit Land Z an der TU Berlin gibt oder gab, so kann die Suchfunktion genutzt werden. Für die Fakultäts-Service-Center soll AManDa eine Ressourcen-steuerung ermöglichen: Angaben zu Räumen und Personal werden im Rahmen der Projektanzeige über AManDa erfasst und mit den im System verfügbaren Daten in Bezug gesetzt. Die bereits bisher bekannten Geneh-migungsprozesse bleiben erhalten.

Wann kommt AManDa und wie sind die nächsten Schritte? Bis Februar 2017 wurden die Wünsche und Anforderungen von der TU Berlin im Austausch mit SAP zusammengetragen sowie Felder und Such-funktionen definiert. Ein Prototyp inklusive der HANA-Volltextsuche wurde in einigen Workshops erarbeitet. Seit dem 6. Februar liegt ein erster Ent-wurf eines Fachkonzepts zu AManDa vor. Dieser wird nun gesichtet und muss dann von den Projektgremien und von den Personalräten auf eine

ERM

✳ePA: elektronische Projekt-anzeige zur Anzeige und Auf-nahme von Stammdaten von Forschungsprojekten

✳ Zur Datenspeicherung nutzt die Technologie, anders als herkömmliche Datenbankma-nagementsysteme, nicht Fest-plattenlaufwerke, sondern den Arbeitsspeicher. Der Arbeits-speicher eines Rechners bietet wesentlich höhere Zugriffsge-schwindigkeiten als Festplatten-laufwerke.

08 | Themen

Abnahme geprüft werden. Eingeführt werden kann AManDa mit allen ande-ren Modulen des ERM-Projektes. Siehe dazu auch den Beitrag über den veränderten Projektzeitplan für ERM auf der Seite 03.

Was ist mit AManDa noch möglich? Zukunftsmusik, aber theoretisch machbar: der Aufbau eines Forschungs-informationssystems an der TU Berlin. AManDa und die damit verbundene HANA-Technologie bieten dafür eine Grundlage. Möglich wäre es, mit anderen Einrichtungen der TU Berlin, wie der Universitätsbibliothek, ver-netzt zu werden und dadurch z.B. Angaben zu Publikationen mit Projekt-angaben zu verbinden. Außerdem wäre eine Suche von außen möglich.

Organisationsmanagement Die Abbildung der Organisationsstruktur wird überarbeitet und erweitert

Als eines der ersten ERM-Teilprojekte wird das Organisationsmanagement (OM) zum 1. Januar 2018 im neuen SAP-System an den Start gehen. Denn hier gibt es eine enge Verzahnung zu SLM. Damit der Pilotbetrieb ausge-weitet werden kann, müssen im SAP Modul OM die Organisationstrukturen der TU Berlin abgebildet werden.

Im Teilprojekt wird derzeit, nach dem Aufruf des Teilprojektleiters Jan- Hinrich Ehmer nach unterstützenden und interessierten KollegInnen, ein Team zusammengestellt. Dieses neue Team wird in den zentralen und dezentralen Bereichen die Organisationsstruktur dieser Bereiche und deren Verknüpfungen untereinander recherchieren und Interviews durch-führen. Diese Daten sind entscheidend für die integrativen Aspekte des neuen SAP-Systems, zum Beispiel zur Unterstützung von Workflows (wie-derkehrende, standardisierte Arbeitsabläufe) oder in der Vergabe von Rollen und Berechtigungen.

ERMAnsprechpartner des Organisationsmanagements ist Jan-Hinrich Ehmer.

Zu erreichen ist er unter Telefon: 27318E-Mail: jan-hinrich.ehmer@tu-berlin.de.

Themen | 09

Newsletter Campusmanagement | Ausgabe 11 | März 2017

Zeiterfassung mit SAP? Zwei neue Dienstvereinbarungen im Zuge der SAP-Einführung

Die neue SAP-Software sieht ein Modul „Zeitwirtschaft“ vor. Mit seiner Ein-führung könnten zukünftig Gleitzeittage und Urlaubsplanungen digital an der TU Berlin verwaltet und in Workflows (wiederkehrende, standardisierte Arbeitsabläufe) eingebettet werden.

Zu dem Modul Zeitwirtschaft wurde in Zusammenarbeit mit SAP ein Fachkonzept erstellt, das noch einige Punkte offen ließ, die es zunächst zu klären gilt. Um diese offenen Fragen abzuschließen, wurde die AG Zeitwirtschaft✳ etabliert. Ihr Ziel ist, die Voraussetzungen zu schaffen, die eine Inbetriebnahme des SAP-Moduls Zeitwirtschaft ermöglichen. Dazu gehört unter anderem, die vorhandene Dienstvereinbarung zur Flexi-bilisierung der Arbeitszeit (DV Flex) entsprechend zu novellieren. Außer-dem erarbeitet die AG einen Vorschlag für eine neue, erstmalig zu vereinbarende Dienstvereinbarung für wissenschaftliche MitarbeiterInnen, Lehrkräfte für besondere Aufgaben sowie BeamtInnen in der Laufbahn des Akademischen Rates. Wenn mit SAP die Zeiterfassung eingeführt werden sollte, dann soll die Regelung ein Höchstmaß an Flexibilität ermöglichen, um dem wissenschaftlichen Arbeiten an der Universität Rechnung zu tragen.

Die in der AG entworfenen Dienstvereinbarungen sind Voraussetzung für die Einführung einer Zeitwirtschaft in SAP. Darüber hinaus wird ein geson-derter Beteiligungsantrag zur Einführung einer digitalisierten Zeitwirtschaft bei den Personalräten zu stellen sein.

Wie würde die Arbeitszeit erfasst werden?Vorgesehen ist, dass die Arbeitszeit webbasiert und händisch von jeder/m Beschäftigten selbst im SAP-System eingetragen wird. Weder soll es Terminals und Chipkarten noch ein automatisches Login beim Start des Computers geben.

Wie und was wird eigentlich an der SAP-Software getestet? Vom Fachkonzept zum Testergebnis im ERM-Projekt

In der nächsten Phase des SAP-Projektes wird die Software gemäß der Spezifikationen aus den Fachkonzepten technisch realisiert. Das heißt, die Standard-Software wird angepasst bzw. ergänzt. Im Anschluss an die Realisierung finden Tests an der Software durch die TU Berlin statt. Getestet wird, ob die Anforderungen aus den Fachkonzep-ten in der fertigen Software-Lösung auch erfüllt sind – ein Abgleich von „so soll es sein“ zu „so ist es“. Die gewonnenen Erkenntnisse dienen dazu, Software-Fehler zu erkennen und zu beheben. Ziel von alledem ist, die SAP-Software benutzerfreundlich und in hoher Qualität an der TU Berlin in Betrieb zu nehmen.

CAMPUS-MANAGEMENT

ERM SLM

Ansprechpersonen des Testmanagements sind Michael Pahn und Andreas Lehmann.

Zu erreichen sind sie unter Telefon: 24402 bzw. 25755 E-Mail: michael.pahn@tu-ber-lin.de bzw. andreas.leh-mann@tu-berlin.de.

✳Der Teilnehmerkreis der Arbeitsgemeinschaft ist zusammengesetzt aus Ver-treterInnen des Personalra-tes, der nebenamtlichen Frauenbeauftragten der ZUV, Fachgebietssekretariaten, ProfessorInnen, wissen-schaftlichen MitarbeiterIn-nen, der zentralen Verwaltung, des Change Managements und der Teilprojektleiterin.

ERM

KonzeptphaseDie Funktionalität der Module wird in je einem Fachkonzept definiert.

RealisierungsphaseDie im Fachkonzept spezifizierten Funktionen werden realisiert.

und weitere Testfälle

M1M2M3M4

TestphaseTesten der Funktionen der Integrationsbeziehungen.

10 | Themen

In Vorbereitung der Tests werden zuvor Testfälle anhand der Funktionen✳ aus dem Fachkonzept erstellt (siehe Grafik). Diese Aufgabe übernehmen nach Vorarbeit der SAP die Key User, ggf. unterstützt durch die Prozess-ExpertInnen. In einer Testfallbeschreibung – dies ist ein schriftliches Doku-ment – sind die durchzuführenden Testschritte und das zu erwartende Ergebnis formuliert. Wenn die Testfälle so gewählt wurden, dass jede Anforderung mindestens einem Testfall zugeordnet ist, kann der vollstän-dige Funktionsumfang getestet werden.

Im Laufe der Tests✳ werden für jeden Testfall erwartete Ergebnisse den tatsächlich erreichten Ergebnissen gegenübergestellt. Die Software ist in Ordnung, sobald die vorher definierten Ziele für die jeweilige Teststufe erreicht worden sind.

Beim Testen einer Software werden drei wesentliche, aufeinander aufbau-ende Teststufen unterschieden: Komponententest, Integrationstest sowie System- und Abnahmetest.

KomponententestDer Komponententest ist ein Test auf der Ebene der einzelnen Module der Software, wie bspw. Finanzbuchhaltung (FI) oder Personaladministration (PA-PA). Testgegenstand ist die Funktionalität innerhalb einzelner abgrenz-barer Teile der Software. Ziel des Komponententests ist ein Nachweis der technischen Lauffähigkeit und korrekter fachlicher (Teil-) Ergebnisse.

IntegrationstestDer Integrationstest testet das Zusammenspiel voneinander abhängiger Komponenten. Der Testschwerpunkt liegt auf den Schnittstellen und soll korrekte Ergebnisse über komplette Abläufe nachweisen.

System- und AbnahmetestBei dieser Teststufe wird von der TU Berlin das gesamte System gegen die vollständigen Anforderungen getestet. Im Abnahmetest wird die dann gelie-ferte Software getestet. Der erfolgreiche Abschluss dieser Teststufe ist Vor-aussetzung für die rechtswirksame Übernahme der Software und deren Bezahlung.

✳Z.B. ist eine Funktion »Stammdaten – Bankverbin-dung eingeben«. In dem Test zu dieser Funktion wird also der Ablauf durchgeführt, die Bankverbindung einer/s Beschäftigten ins System ein-zugeben. Der Test ist erfolg-reich, wenn das erwartete Ergebnis eintrifft.

✳Wer neben den Key Usern und Prozess-ExpertInnen außerdem testet, wird derzeit vom Testmanagement erarbeitet.

M2 F1 F2

Newsletter Campusmanagement | Ausgabe 11 | März 2017

Themen | 11

Was ist eigentlich ein Change Request (CR)? Änderungsanforderung der Leistungsbeschreibung im Campusmanagement

Im Campusmanagement ist ein Change Request (CR) ein formeller Antrag zur Durchführung einer Änderung der Leistungsbeschreibung, die auf eine neue Anforderung der TU Berlin als Auftraggeberin zurückgeht. Die Leistungsbeschreibungen von ERM und SLM erläutern diejenigen Sach-leistungen, die zwischen TU Berlin und SAP sowie itelligence✳ vertraglich vereinbart wurden. Das heißt, darin steht, was die Standard-Software kön-nen muss und welche Anpassungsleistung die beiden Implementierungs-firmen durch das sogenannte „Customizing“ liefern werden.

Wie wurden die Leistungsbeschreibungen erarbeitet? Bevor die Leistungsbeschreibungen ausgearbeitet wurden, haben Arbeits-gruppen die Prozesse an der TU Berlin beschrieben und daraus die Soll-Prozesse für die neue Software entwickelt. Diese Prozesse und viele weitere funktionale Anforderungen waren dann Inhalt der Leistungsbe-schreibungen. Nach Vertragsunterzeichnung wurden Schulungen und Workshops an der TU Berlin durchgeführt, um zu klären, wie die Soll-Pro-zesse abgebildet werden können. Dadurch hat das Projektteam ein noch umfassenderes Wissen erlangt – über fachliche Inhalte, Strukturen und neue Arbeitsabläufe. Dieses detaillierte Wissen hat zur Folge, dass das Projektteam sowie die gesamte Universität mehr weiß als ursprünglich bei der Verfassung der Leistungsbeschreibungen und somit Anforderungen nun noch konkreter formulieren kann. Die Anforderungen wurden von SAP und itelligence aufgenommen, teilweise als CR-Vorschlag formuliert und für weitere Verhandlungen dokumentiert.

Welche CRs gibt es? Es gibt CRs, die nur wenige Tage Umsetzungsaufwand bedeuten, und CRs, die einen höheren finanziellen Aufwand nach sich ziehen. Einige CRs sollen sofort nach Beauftragung in der nächsten Phase umgesetzt werden, andere werden zunächst zurückgestellt, und es wird in der Testphase ent-schieden, ob sie realisiert werden. In jedem Fall ist eine Kosten-Nutzen-Abwägung notwendig.

Ist jede Änderung der Leistungsbeschreibung ein CR? Nein, denn es können sich auch für die Auftragnehmer SAP und itelligence neue Erkenntnisse ergeben, die zu einer Anpassung der Leistungsbe-schreibungen führen. Hierbei handelt es sich, gemäß der im Projekt ange-wendeten Projektmanagemenmethode PRINCE 2, nicht um einen CR, sondern um eine Spezifikationsänderung.

Wer entscheidet darüber? Bevor geklärt ist, ob die von der TU Berlin formulierte Anforderung tatsäch-lich ein CR oder eine Spezifikationsänderung ist, wird zwischen Universität und den Implementierungsfirmen viel diskutiert: Ist das neu oder ist das Bestandteil der Leistungsbeschreibungen, ist das Kenntniszuwachs oder

CAMPUS-MANAGEMENT

ERM SLM

✳Es gibt zwei Implementie-rungsfirmen, die die TU Berlin bei der Einführung der SAP-Software begleiten: Das ist SAP für das ERM- Projekt und itelligence für das SLM-Projekt.

12 | Themen

profitieren sogar SAP und itelligence von einer Neuerung ihrer Standard-Software? Denn ein CR ist oft verbunden mit zusätzlichem Aufwand und zusätzlichem Geld. Eine Spezifikationsänderung führt zur Änderung der Leistungsbeschreibungen aufgrund von Kenntniszuwachs während der Projektlaufzeit. Sie ist kostenneutral für die TU Berlin. Am Ende entschei-det der Lenkungsausschuss als höchste Projektinstanz, ob und wie viele CRs tatsächlich von der TU Berlin beauftragt werden sollen.

Arbeitsalltag im Fachgebietssekretariatund welche Aufgaben bald in SAP erledigt werden

Ein Gedankenexperiment: Können Sie sich vorstellen, folgende Aufgaben alle zu bewältigen – gleichzeitig und regelmäßig?

Drittmittelprojekte betreuen, unterschiedlichste Anfragen und Sorgen von Studierenden lösen, Lehrveranstaltungen in LSF planen, Dienstreisen beantragen, telefonische Auskünfte geben, Überwachen von Konten in SuperX, Rechnungsbearbeitung und Vorbereiten von Auszahlungsanord-nungen, Noten in QISPOS eingeben, Fragen von KollegInnen beantwor-ten, JuniorprofessorInnen betreuen, Stellenausschreibungen aufsetzen, Forschungsdaten in LinF eingeben, Unterlagen für den/die Hochschulleh-rerIn vorbereiten, Bürobedarf und -ausstattung bestellen, Webseiten in TYPO3 pflegen, Übersetzungen anfertigen und, und, und.

Können Sie nicht? All das und vieles mehr leistet ein/e Fachgebietssekre-tär/in an der TU Berlin. Ganz schön viel, oder? FachgebietssekretärInnen leisten immens viel für die Universität, ohne Sie… das wollen wir uns gar nicht erst vorstellen.Viele der Tätigkeiten erfolgen IT-gestützt. Mit SAP werden die Fachgebiets-sekretärInnen zukünftig die meisten davon mit der neuen Software

Ein paar Beispiele:▶ QISPOS, um Prüfungen anzulegen und zu verwalten sowie Noten einzutragen▶ LSF, um Lehrveranstaltungen und Räume zu planen▶ LinF, um Forschungsdaten erfassen und kontrollieren zu können▶ SuperX, als Auswertungs- und Auskunftssystem, für den Überblick von Buchungen

Oder auch:▶ Beschaffungen durchführen▶ Dienstreisen beantragen und abrechnen

Veranstaltungen | 13

durchführen. Denn mit ihr werden zahlreiche IT-Fachverfahren abgelöst und somit die dazugehörigen Funktionen integriert.

Beim Übergang von den bisherigen Programmen zu SAP werden einige Herausforderungen auf uns alle zukommen und jede/r Beschäftigte wird sich in das neue System einarbeiten müssen. Damit der Übergang ge- lingt, werden Schulungen für alle NutzerInnen zeitnah zur Umstellung angeboten.

VeranstaltungenOffenes Projektbüro und andere Veranstaltungsformate

In den Veranstaltungen zum Campusmanagement informieren wir die Beschäftigten über aktuelle Entwicklungen in der SAP-Einführung und bie-ten Gelegenheit zum direkten Austausch.

Offenes Projektbüro Wann: Donnerstag, 11. Mai 2017, 12 bis 14 Uhr, in EB 323 Was: Gespräche mit den Projektmanagern, TeilprojektleiterInnen sowie

AnsprechpartnerInnen von SAP und itelligence; Vorstellung von aktuellen Themen und ggf. SAP-Demoversionen

Runder Tisch Wann: Diese Veranstaltungen werden bei aktuellen Fragen und Themen-

stellungen zum Campusmanagement einberufen, die von den Beschäftigen oder einzelnen Gruppen ans Projekt adressiert werden.

Was: Vertrauensvoller Austausch in kleiner Runde mit den beiden Pro-jektleitern und Projektmanagern.

Fakultäts- und Abteilungsbesuche Wann: Diese Veranstaltungen werden bei Bedarf seitens der Fakultäten

bzw. Abteilungen oder bei aktuellen Themen aus dem Projekt her-aus organisiert.

Was: Information und Frage-Antwort-Runden mit den themenbezogenen ProjektexpertInnen und dem Change Management.

Bei Interesse zu einzelnen Terminen organisiert das Team des Change Management auch gerne Infoveranstaltungen für einzelne Bereiche, Abteilungen oder Fakultäten. Sprechen Sie uns einfach an.Weitere themenspezifische Veranstaltungen sind in Planung. Alle Termine und Details sind unter Direktzugang▶ 173168 zu finden.

Mit Fragen und Anregungen können Sie sich jederzeit gerne an das Team des Change Management unter campusmanagement@tu-berlin.de wen-den und in Raum EB 324A und 326.

CAMPUS-MANAGEMENT

ERM SLM

Ansprechpartnerin im Change Management ist Kirsty Otto.

Zu erreichen ist sie unter der Telefonnummer 24407 und per E-Mail unter kirsty.otto@tu-berlin.de.

Terminänderung:

15. Juni 2017

14 | Impressum & Kontakt

Impressum & KontaktTechnische Universität Berlin - CampusmanagementStraße des 17. Juni 13510623 Berlin

Telefon: 030 314-78594Email: campusmanagement@tu-berlin.dewww.tu-berlin.de/campusmanagement

Projektleitung:Lars Oeverdieck (ERM), Leiter des PräsidialamtesProf. Dr. Hans-Ulrich Heiß (SLM), Vizepräsident für Studium und Lehre

Projektmanagement:Michael Jeschke (innoCampus), Projektmanager SLM Michael Wilmes (tuKERP), Projektmanager ERM

Change Management:Dr. Cornelia Raue, Change Managerin Campusmanagement

Redaktion und Layout: Insa BortfeldtCynthia Galle

Bildnachweise:Titelseite TU Berlin/PR/Anna Groh Seite 3 TU Berlin/S. WolkensteinSeiten 3, 9, 10, 12 TU Berlin/Insa Bortfeldt unter Verwendung von Grafiken von freepiks.comSeite 14 TU Berlin/Philipp Arnoldt

Offenes Projektbüro