Wunderbar. Kann man uns auch gut hören. Sehr schön.
Also von unserer Seite auch nochmal ein ganz herzliches Willkommen.
Ja, gefühlt ist dieser Track E-Campus leider nicht mehr
ganz so stark besetzt, wie die Jahre davor.
Vielleicht hängt es ja damit zusammen, dass die Einführung von Campus
Management Systemen oft so erfolgreich ist und so einfach auch ist.
Ich hatte mir eigentlich fast noch mehr Gelächter, was da ein wenig erhofft.
Nein, es zeigt die Erfahrung in den letzten Jahren,
hat ja, glaube ich, wirklich gezeigt,
wie komplex solche Projekte sind und dass es eben wirklich sowohl
für Anbieter als auch für Hochschulen eine enorme Herausforderung darstellt.
Wir wollen ihnen trotzdem heute ein Projekt einmal vorstellen,
was wir mit der FAV-Berg in den letzten zweieinhalb Jahren gemeinsam durchführen durften.
Und wir haben es tatsächlich gemeinsam geschafft, unter,
ja, definitiv gemeinsamer großer Anstrengung, keine Frage,
aber wirklich in unter zweieinhalb Jahren eine komplette Einführung eines Campus-Management-Systems,
in allen Prozessen wirklich in den Live-Betrieb zu bekommen.
Und wie wir das geschafft haben,
weil auch für uns einige ganz neue Ansätze dabei rausgekommen sind,
das wollen wir heute gerne einmal präsentieren und zeigen.
Zunächst nochmal ganz kurz zu den beiden Partnern,
die hier sozusagen vorhin stehen, ich sage auch ganz bewusst,
bewusst Partner, weil so ein Projekt schafft man nur,
gemeinsam in einer Partnerschaft erfolgreich umzusetzen.
Wir, also diese Movative GmbH, entwickelt das Campus-Management-System Academy
5 mittlerweile seit 17 Jahren. Es ist bei,
oder bei knapp 59 oder bei Insgesamt 59 Hochschulen im Einsatz
mit aktuell etwas knapp unter 100.000 Studierenden,
die aktiv an diesen Hochschulen eingeschrieben so mit dem System arbeiten.
In den Verwaltungen sind es etwa über 2000 Mitarbeiter,
die mit dem System arbeiten und umsetzen,
tun wir das in München mit 38 Mitarbeitern aktuell.
So, Handy Dacher, wie sah denn nun die Ausgangssituation
an der FAVA-Werk aus?
Jo, herzlichen Dank
Mein Name ist Stego und Niederracher, ich bin IT-Leiter an der EV-Vorralberg.
Forralberg ist ganz im Westen von Österreich und bildet mit der Ostschweiß Lichtenstein und Deutschland,
also rund um die Region Bodensee und Rheintal,
eine der wirtschaftlich stärksten Regionen in Europas.
Wir sind alle recht junge Hochschule, wir sind stetig gewachsen
und geprägt durch unser Umfeld haben wir einen sehr hohen Professionalitätsanspruch.
Wir betreiben unter anderem eine Reihe von Forschungszentren,
um bilden 1750 Studierende aktuell aus, sehr viele davon, die Hälfte berufsbegleitend.
In Summe sind wir aber eine recht kleine Hochschule,
nur das eigentliche Problem ist,
dass wenn man das mit einem gewissen Professionalität betreiben will,
Anforderungen und Prozesse nicht skalieren.
Und damit ist das so ein Projekt für eine kleine Hochschule,
natürlich eine große Herausforderung. Unser bisheriges Campus-Management-System war eine Eigenentwicklung,
die ist mit uns mitgewachsen und wurde über die Jahre ergänzt durch viele Insellösungen,
Wahlfachmanagement und solche Themen und vor allem sehr viele Excel-Listen, Filemaker-Datenbanken.
Das System und auch die Prozesse sind mittlerweile End of Life,
haben das Ende des Lebenszyklus erreicht und wir haben uns dazu entschlossen,
Campus-Management,
System neu einzuführen.
Zwei Anmerkungen im Vorfeld
Makro-Bay-Entscheidungen. Das kann man rechnen, das zeigt,
das ist jetzt auch hinterher, wo wir wissen, was das gekostet hat.
Die Rechnung war damals sehr gut. Der Hauptgrund,
warum wir uns entschieden haben,
Standard-Software einzusetzen oder eine Ausschreibung zu machen,
gelingt es uns auf dem angespannten Arbeitsmarkt eine Reihe vom Programmieren zu rekrutieren und zu binden,
sind ERP-Projekte oder Campusmanagement-Projekte attraktiv genug,
um die Mitarbeiter auch langfristig und damit das Know-how zu sichern.
Die zweite Anmerkung im Vorfeld Ein professionelles Vergabeverfahren beinhaltet bereits den Vertrag.
Sie sichern sich das A-Team, das war der Hervorbringer selber,
sie definieren die Meilensteine und sie definieren,
und das ist der Gil, alle Termine vor Ort.
So war der Hervorhebringer an und für sich alle zwei Wochen, zwei Tage lang,
in den Kernphasen wirklich vor Ort und stand uns zur Verfügung.
Und das war ein wesentlicher Erfolgsfaktor am Ende des Tages.
Das Simovative-System haben wir jetzt seit sagen wir letzten Jahres im Produktiveinsatz,
wie der Hervorbringer gesagt hat,
die Implementierungsdauer von 26 Monaten, habe ich gehört,
sei sportlich,
es war eine große Herausforderung
Bevor wir allerdings zur Implementierung schreiten konnten, war natürlich eine
ganze Reihe von Aufgaben, Hausaufgaben auf Seiten der Hochschule zu erledigen.
Testerstellen von Anforderungsunterlagen und Ausschreibungsunterlagen ist nicht wirklich agil, sondern ganz klassisch Wasserfall.
Das Wichtigste im Vorfeld ist die Zusammenstellung des Teams.
Und ein Schlüsselfaktor bei uns war eine Entscheidungsbefugte, Prozessverantwortliche,
also Personen aus der Hochschulführung und die notwendigen Expertinnen beizuziehen und
auch die Zeitbudgets für das Projekt von diesen Personen zu sichern.
Gemeinsam haben wir Bezugsrahmen definiert. Eine Prozesslandkarte,
und für solche Dinge braucht man nicht unbedingt eine Ist-Erhebung,
weil es ist relativ zeitintensiv. Eine EFH sind das in Summe 23 Prozesse,
hängt ein bisschen von der Prozesslandkarte ab, könnten ein bisschen weniger sein,
aber irgendwann haben sie sich auf eine Terminologie fixiert und an der orientieren sie sich.
Und diese Prozesse bestimmen die IT-Anforderungen. Und die Unterlagen,
die sie in dieser Phase erstellen,
bestimmen die Basis für die Ausschreibung und ziehen sich,
und da ging es eben darum,
das so effizient wie möglich zu gestalten,
sehen sich auch durch das ganze Projekt
Eine Anmerkung, ich kann es mir nicht vergleifen,
es wurde zu meinem Hobby eine gute Ausschreibung,
führt immer zum Best Beater. Wenn Sie hier unsicher sind,
nehmen Sie einen erfahrenen Juristen, es gibt genügend Juristen,
die laufen große Ausschreibungsprojekte machen und das lohnt sich hinterher.
Was müssen wir jetzt tun für diese 23 Prozesse? Manche Prozesse sind trivial,
dieser hier beschreibt den Quereinstieg,
also Einstieg in ein höheres Semester mit Anerkennung,
Anerkennungen und auch den Mobilitätsprozess für Incoming-Studierende,
der ist nicht so trivial,
für alle Prozesse sind aus der Prozesslandkarte bekannt,
der Zweck,
die Aktoren und die groben Zusammenhänge zwischen den Prozessen
Was aber im Team schon eine Knochenarbeit darstellt,
und sie wissen, wie Hochschulen funktionieren.
Sie müssen gemeinsam die Definition erarbeiten. Und das ist tatsächlich Knochenarbeit,
sehr diskussionsintensiv, bietet aber die Chance,
dass sie diese Diskussionen nicht in die Implementierung schleppen.
Und das gemeinsame Festlegen von Fristen. Fristen sind an
vielen Hochschulen an unserer ganz bestimmten Wahl eine Herausforderung.
Die Fristen sind auch insofern kritisch, weil sie die Abhängigkeiten
zwischen den Prozessen definieren. Also pro Prozess einmal Zweck,
Definition und diese Dinge,
die wir
hier beschrieben haben
Und den Prozess selber zu beschreiben. Wir machen das mit
User Storys, das ist ein Standard in allen agilen Softwareentwicklungen.
Ich empfehle nicht grafische Methoden, so BBM-L und so Hütinge einzusetzen.
Der notwendige Aufwand, um die Detaillierungstiefe zu erreichen und
diese Dokumente aktuell zu halten, ist enorm.
Aus Effizienzgründen ein zweiter Hinweis, wir in der IT
haben diese User Storys alle im Vorfeld alleine erstellt.
Wir in der IT können solche Dinge,
und das hat die Workshops sehr effizient gemacht, es hat sich gezeigt,
dass wir um die letzten zehn Prozent diskutiert haben,
Mit dem Prozess Verantwortlichen, mit den Expertinnen. Und das war schon ein,
das war schon ein wichtiger Schritt, um das effizient durchzuführen.
Für diese Phase haben wir übrigens circa fünf Monate benötigt.
User-Stories, wir haben nicht die Zeit, um hier auf
die Details einzugehen. Ich sage ein einfaches Beispiel. Als
Studierender im Statusunterbrechung völlig ein Online-Formular für den Wiedereinstieg aus.
Damit ergibt sich für den Herrn Fürbringer,
es gibt das Studierendenportal und es gibt einen Workflow für solche Prozesse
Mehr müssen wir in dieser Phase gar nicht sagen,
daraus leiten sich aber sehr viele Anforderungen ab. Genau,
und warum auch gerade für uns eben diese Formulierung im User-Story-Format so wichtig ist,
da kommen wir auch gleich noch mal drauf,
aus wie vielen User-Stories besteht denn jetzt so ein Campus-Management-System?
Das Highlight des Vorträgs. 745 an der FAV Allberg.
Die Prozesse, diese 23 Prozesse sind unterschiedlich in der Komplexität.
Und jede Hochschule hat ein paar Prozesse oder auch Teams,
die kompliziert sind. Wenn wir das bereinigen,
in unserem Fall um einen Ausreißer,
beschreiben wir jeden Prozess mit 27 User-Stories,
das ist eine überschaubare Menge
Der Aufwand für die Erstellung, der Aufwand für die Erstellung
dieser Prozesse war jeweils vier bis acht Stunden in drei Itrationen,
Vorentwurf, Diskussionen mit dem Team oder abschließend nochmal die Freigabe.
Jetzt Herr Fürbringer, das war jetzt nicht sonderlicher Gil bis hierher.
Was ist denn eigentlich Herr Gil? Also wirklich,
die Agilität kommt ja sozusagen erst mit dem, ja eigentlich jetzt,
wenn das Projekt gestartet ist, fängt man an,
sozusagen mal in die Agilität wirklich, was die Projektplanung einzusteigen.
Jetzt, wir entwickeln als Softwareanbieter, das ist, glaube ich,
mittlerweile so der de facto Standard geworden im Bereich Softwareentwicklung, mit Scrum.
Es gibt noch zwei, drei andere Thematiken,
also Cannban zum Beispiel, bei uns hat es Scrum jetzt durchgesetzt.
Was bedeutet das auf der einen Seite? Ganz klar,
wie gerade schon eben erwähnt, eine verständliche Anforderungsdokumentation eben in diesem User-Story-Format. Das hat nicht nur für den Entwickler,
der steckt ja auch nicht bei ihnen an der Hochschule drin,
der Wald kennt also auch nicht jeden Prozess genau,
sondern gerade auch tatsächlich, wie wir festgestellt haben, für die Key-User,
die also mit die Modellierung begleiten sollen und auch wirklich damit definieren,
ob jetzt eine Anforderung entspringt für die Hochschule korrekt umgesetzt wird,
ist man deutlich näher dran, als wenn man das sehr umfassend,
entsprechend vielleicht grafisch in Umfeld anfangreichen Prozessmodellierungsdiagrammen entsprechend das darstellt.
Wir haben, das ist auch ein ganz entscheidender Punkt,
wir haben eine frühe und kontinuierliche Auslieferung, das heißt,
wir haben zwei Wöchige Sprints, der Kunde bekommt alle zwei Wochen eine Version hingestellt,
nach seinen Spezifikationen und kann auch wirklich testen im System,
ob seine Anforderungen damit gerecht wird.
Wir schaffen intern eine wirklich tägliche Zusammenarbeit mit dem sogenannten Product Owner,
also sprich, wenn man so möchte, dem Architekten auf Firmenseite,
der die Vorgaben entsprechend aus den User-Stories abgeleitet hat und kann das mit den Programmieren jeden Tag aufs Neue überprüfen,
wohl, wie der Fortschritt aussieht,
ob auch das wirklich von der fachlichen Seite korrekt umgesetzt ist.
Dadurch können wir natürlich extrem schnell reagieren.
Wir beziehen da mit den Kunden extrem eng ein,
weil wir nicht eben einmal definieren, dann wird sechs Monate entwickelt,
dann liefern wir aus und dann kommt die große Überraschung,
was jetzt dann am Ende bei rausgekommen ist.
Und vor allem auch, ich glaube, das hat immer,
man kann sich vorstellen, für Herrn Nielache war es,
glaube ich, auch das erste Mal, so ein System einzuführen.
Für viele ist es oft das einzige Campus-Management-Projekt,
was man sozusagen in seiner Karriere bestreitet.
Das wollen sie auch nur einmal in ihrer Karriere machen.
Ich hatte gehofft, dass sie jetzt das auch nicht sagen kann.
Nein, aber dass das natürlich eine enorme Knochen, aber eine enorme Leistung.
Beiderseits ist es, glaube ich, klar. Und deswegen
ist auch gerade eines dieser Prinzipien der agilen Softwareentwicklung, diesen permanent sichtbaren Projektfortschritt.
Sie liefern eben alle zwei Wochen was aus und der Kunde ist,
glaube ich, an manchen Stellen doch auch deutlich beruhigt und hat mehr Vertrauen,
wenn er einfach sieht,
dass auch wirklich seinen Anforderungen entsprechend das System weiterentwickelt wird.
Allerdings, das haben wir gerade im Kontext der Hochschulen festgestellt,
reicht es jetzt nicht einfach nur aus,
jedes Projekt zukünftig sozusagen nur noch agil zu machen,
denn auch in den agilen Vorgehensweisen stecken einige Herausforderungen.
Gerade das Thema an Hochschulen, an Campus Management System ist nur mal
ein System mit enormer Komplexität, mit ganz vielen Abhängigkeiten zwischen den Prozessen.
Wenn ich da nur strikt nach dem agilen Prinzip vorgehe,
ich baue schnell einen Teil einer Software,
dann schaue ich es mir an, stelle fest,
ach, passt doch und ich schmeiße es wieder weg,
fange wieder neu an.
Dann habe ich Projektlaufzeiten, die wahrscheinlich wirklich fünf Jahre plus entsprechend ergeben.
Auch diese grundsätzliche Verteilung von Verantwortlichkeiten im Team kann auch mal schnell dazu führen,
wenn am Ende keiner, also wenn alle verantwortlich sind,
ist am Ende keiner verantwortlich,
was auch nicht unbedingt zu schnellen Entscheidungsfreudigen Teams führt
Entsprechend zwei ganz wichtige Punkte, ganz klar Agilität kann nur mit einer
extrem starken Kommunikation auch wirklich funktionieren. Sowohl in den Teammitgliedern
als natürlich auch im Unternehmen diese agilen Werte müssen einfach gelebt werden.
Ein weiteres Problem für die nachhaltige Implementierung von Softwareprojekten ist das Thema Dokumentation,
an ganz vielen Stellen legt man dann nur noch auf die Funktionalität
wert und verlässt eigentlich ein bisschen sozusagen den doch wichtigen Part der Dokumentation,
denn gerade wenn man sich das nachhaltig auf viele,
viele Jahre vorstellt,
wo neue Mitarbeiter herangeführt werden sollen,
ist es natürlich absolut entscheidend,
auch eine vernünftige Systemdokumentation zu haben
Und vielleicht gerade im Bereich auch von Ausschreibungen nicht ganz unrelevant,
rein agil kalkuliert, wird es schwierig,
tatsächlich einen Kostenrahmen und auch eine Laufzeit festzulegen.
Und jetzt sind sie ja in der Hochschule in letzter Instanz ja
doch alle eigentlich zumindest zu Projektbeginn eigentlich fast verpflichtet zu wissen,
was kostet mich das und bis wann habe ich dieses System.
So, dementsprechend haben wir gemeinsam nach einer Lösung gesucht.
Sie ist uns zugegebenermaßen auch ein bisschen von auch dem Rechtsanwalt
ein bisschen aufoktruiert worden. Wir haben also ein hybrides Projektmanagement
als Ansatz gewählt. Hybrid heißt unterm Strich eigentlich nur,
wir kommen mehrere Ansätze und versuchen halt aus den diversen Projektmanagementansätzen,
das Beste für das Gesamtprojekt entsprechend rauszuholen. Entsprechend hat man sich übergeordnet,
für ganz klar voneinander sequenziell abfolgende Projektphasen entschieden,
also ein ganz klares Wasserfallmodell, danach auch nochmal in den einzelnen Projektphasen,
sich ein bisschen aus dem traditionellen Projektmanagement bedient,
nämlich dem Simultanus Engineering.
Und dann die eigentliche Softwareentwicklung ganz konsequent mit Scrum vorangetrieben.
Wie sah das denn jetzt konkret in den einzelnen Prozessbereichen
aus,
Henny Lacher
Oder ich kann, oder wollen Sie dazu noch kurz was sagen, sonst?
Das hier können wir nicht. Machen wir. Dann machen wir
bei der Prozesshammelsierung einfach vielleicht noch einmal weiter, genau.
Also noch einmal ganz kurz grafisch dargestellt.
Wir haben unterm Strich in dem Projekt,
waren die 23 einzelnen Prozesse aufgeteilt in fünf einzelne Prozessbereiche.
Das war Interessenten und Bewerbermanagement. Dann kam der ganze Bereich Stammdaten.
Das ist der ganze Bereich Planung und dann am Ende noch das Prüfungsmanagement.
Für uns ganz entscheidend war, dass wir in der Prozessharmonisierung,
die insgesamt sechs Monate gedauert hat, wirklich diesen Ansatz,
dieses Simultanes Engineering benutzt haben. Das heißt,
wir haben in der Prozessharmonisierung nicht einfach Prozessbereich für Prozessbereich sequenziell abgearbeitet,
sondern einfach, weil es hier so viele Schnittmengen gibt,
ganz bewusst immer geschaut, dass die Bereiche,
wo auch wirklich Schnittmengen da sind,
dass man sich die in der Prozessharmonisierung eben gemeinsam anschaut,
damit man auch möglichst frühzeitig solche Zusammenhänge einfach erkennt und auch in anderen Prozessbereichen dann darauf reagieren kann.
Ganz klar gab es nach der Prozessharmonisierung einen ganz klaren Cut und
auch hier hätte die FAV-Berg nochmal ganz klar entscheiden können,
das macht so keinen Sinn, da haben wir kein Vertrauen,
dass wir das am Ende genauso umsetzen können
Stoppen wir das Projekt nochmal. Das ist glücklicherweise nicht passiert
. Wir haben uns nach sechs Monaten entschieden,
das Projekt gemeinsam weiter voranzutreiben, sind dann in die sogenannte Implementierungsphase,
die ein Jahr ganz genau gelaufen ist.
Hier wurde auch teilweise wieder die Prozessbereiche,
wo es eben auch notwendig war, parallel entwickelt,
in jedem einzelnen Prozessbereich, aber ganz klar in diesem typischen Sprint-Szenarien.
Das heißt, es gab ein ganz klar definiertes Backlog,
welche Aufgaben jetzt entsprechend anhand der User-Stories umgesetzt werden mussten.
Dieses Backlog wurde der FAV-Berg
transparent bereitgestellt
Das heißt, man konnte auch wirklich in jedem einzelnen Bereich genau sehen,
welche Storys sind jetzt im nächsten Sprint, die Key-User konnten sich bereits darauf vorbereiten, dass sie in zwei Wochen folgende Funktionalität sich zumindest schon einmal anschauen können. Genau,
nach der Implementierung, wo wir auch entsprechend final bekannt geben mussten,
dass die Implementierung soweit jetzt abgeschlossen ist,
sind wir gemeinsam in einer Abnahmephase hineingegangen,
das hätte man jetzt prinzipiell auch sequenziell machen können,
die einzelnen Prozessbereiche abzunehmen, wir haben uns trotzdem dafür entschieden,
das möglichst parallel zu machen,
um einfach nicht zu viel Zeit an dieser Stelle zu verlieren und weil natürlich mit jeder Abnahme,
es ist klar, eine Software ist nie ganz fehlerfrei,
auch wieder Punkte, entsprechend Aufkommen,
die man noch optimiert und anpassen muss, wollten wir einfach,
ja, nicht einen Prozess nach dem anderen entsprechend abnehmen,
sondern das auch möglichst parallel tun.
Die Schulung, ganz klar, musste dann entsprechend natürlich sukzessive in Blöcken erfolgen,
bevor wir dann in den Live-Betrieb gegangen sind.
Und jetzt schauen wir uns noch mal kurz die einzelnen Prozessbereiche
noch mal ein bisschen an. Ja, vorher zu lassen,
wenn man einen Führbringer an einen Lacher generiert.
Eine große Herausforderung im Campus-Management-System ist jetzt nicht unbedingt die IT.
Da geht es um Change-Management, da geht es um Kultur,
da geht es um Verbindlichkeiten.
Und es ist eine enorme Stresssituation für alle Beteiligten.
Bei uns hat mal eine Schuldinger Salmistratorin gesagt,
System dann live geht, dann komme ich ins Büro.
Und das einzige, was ich kann, ist Blumengesen und Kaffee machen.
Und die Ängste sind hier, die muss man adressieren.
Ich werde da in der Folge nur ganz kurz mit zwei,
drei Sätzen drauf eingehen. Die erste Phase war,
wie der Hervorbringer gesagt hat, die Prozessharmonisierung.
Vorab noch ein Hinweis, bevor sie loslegen,
migrieren sie so schnell wie möglich ihre Echtdaten.
Ihre Studiengänge, ihre Prüfungen, ihre Studierenden. Das erleichtert ihnen
das Erkennen von Problemen, weil sie mit vertrauten Daten arbeiten.
Die Methode, wie wir das durchgeführt haben,
in diesen Workshops, in langen Workshops mit dem Anbieter
Und unsere Experten haben wir unsere Anforderungen mit dem Funktionsumfang der Standardsoftware verglichen.
Diese Abweichungen bilden am Ende des Tages das Pflichtenhilft.
Screenshots und Morkups definieren diese Lösung, sieht man,
glaube ich, den Beamer nicht so toll.
Der Aufwand für diese Phase war sechs Monate.
Und sie sehen hier, wir haben diese User-Stories wiederverwendet.
Definieren hier, wie das System ausschauen soll und da,
wo Verbindlichkeiten notwendig sind, gibt es in der To-Do-Spalte etwas,
was der Hervorbringer und sein Team zu realisieren hat.
Es gibt aber auch ganz viele Dinge in der Spalte davor,
die die Hochschule noch organisieren muss
Und dann kommen wir mal zur eigentlichen Implementierungsphase.
So agiles Thema, die Durchführung bei der Semovative ist,
sie werden schon ein bisschen warten müssen, bevor sie,
bevor sie das im Gesamtfunksumfang testen können.
Der Bieter muss diese Dinge noch fertigstellen.
Wir sehen sehr früh Zwischenergebnisse können eingreifen, können sagen,
super, das hat sehr gut funktioniert.
Es muss ihnen in dieser Phase bewusst sein,
dass jede Verzögerung in dem Projekt ein Jahr Verlust bedeutet,
weil sie werden ein Campusmanagement-System nicht
unterjährig einführen können
Parallel dazu, während der Fürerbringer programmiert, haben sie immer wichtige Aufgaben.
Also mit dem Fürbrigen Holzer Team. Erweitern Sie Ihr Team,
bauen Sie eine Supportmannschaft auf, motivieren Sie die Supportmannschaft.
Optimieren Sie weit Ihre Prozesse, die Organisation und die Migration.
Und programmieren Sie die notwendigen Schnittstellen. Und egal wie perfekt
Sie bisher waren, Sie reichen jetzt die kritische Phase.
Training, GoLife und Support im ersten Produktivjahr.
Sie haben ganz viele Prozesse, die machen Sie
nur einmal im Jahr
Aufnahmeverfahren, Heilungstests. Da sind sie zwar im September
live gegangen, können sie aber erstmalige Mai testen.
Und sichern sie sich ab, erstellen sie eine
sehr gute Dokumentation und führen sie perfekte Schulungen durch.
Zu den Schulungen, der Gesamtaufwand an der EV,
Verzeihung zu den Schulungen komme ich noch.
Eine Grundvoraussetzung ist, dass sie ein perfektes Prozess- und Systemhandbuch machen.
Wir haben bisher mit abstrakten User-Stories aus der Ausschreibung gearbeitet.
Das gilt auch für die Abnahme im Nachgang.
Für die Schulung und den Betrieb brauchen sie aber User-Stories,
die konkret
dieses System beschreiben
Wir haben uns dafür entschieden, das war nicht populär,
aber das hat sich sehr bewährt, dass die Prozessverantwortlichen und das Supportteam,
diese User-Stories und Screenshots schreiben müssen,
weil sie müssen das System vertreten,
sie müssen das System betreiben und supporten.
Schulungsaufwand gesamt waren bei uns zehn Tage, für mehr oder weniger alle Personen.
Wir haben das sehr breit geschult, es war auch wichtig,
aber noch einmal, die Schwierigkeiten kommen im ersten Jahr,
sie müssen die Leute begleiten,
sie müssen ihnen die Ängste nehmen und natürlich jetzt den einen oder anderen Softwarefäller auch geben.
Zum Ergebnis an der EFA Voralberg,
was haben wir erreicht
Für uns überraschend, dass die Ausschreibung liegt bei vielen Beatern
tatsächlich in unseren Funktionsumfang abgedeckt hat. Das hätte für uns bedeutet,
dass wir viele Schnittstellen und eigene Entwicklungen oder Fremdsysteme integrieren müssen hätten.
Oder das Risiko eingegangen wären, dass dann doch
einige Teillösungen damit Excel und ähnliche Lösungen weiter etabliert wurden.
Der hohe Deckungsgrad des Systems erlaubt uns, die Prozesse langfristig zu sichern.
Das Gleiche gilt für die Entscheidung, Standardsoftware.
Wir sind überzeugt, dass wir damit bis zu meiner Pensionierung.
Einen sehr guten Partner haben. Und die Standardsoftware wird
sich weiterentwickeln und wir können mit ihr wittwachsen.
Wir haben jetzt schon viele Dinge gesehen,
die sie movative könnte, die wir noch nicht eingesetzt haben.
Das werden wir in den nächsten Jahren tun.
Und Herr Fürbringer, was kann denn eigentlich ein modernes Campusmanagement-System?
Also zunächst mal hoffe ich natürlich, dass es bis zu
ihrer Pensionierung dementsprechend noch ganz, ganz lange hin ist.
Also es gibt ja viel in einigen Projekten, haben wir teilweise auch den Vorteil,
dass wir ein Campusmanagement-System auch wirklich modular und sukzessive einführen können.
Das war an der Verfolgerberg nicht nur aufgrund des Ausschreibungsprojektes nicht möglich,
sondern an der Verfolger gab es einen definitiv absolut ausgewachsenes System,
damals noch basierend auf Oracle Forms.
Das wirklich das absolute Herzstück sozusagen der Hochschule dargestellt hat.
Hierüber wurden alle Prozesse bis hin zur Heizungssteuerung, Lüftungssteuerung, natürlich Zutrittssysteme,
Anbindung an HR, SAP, alles lief über dieses System.
Das heißt, es war in keinster Weise möglich,
jetzt nur einzelne Teile sozusagen in einen Live-Betrieb zu überführen.
Das geht wirklich los im Bereich CRM-Interessenten,
Bewerbermanagement bis hin zur Online-Bewerbung, die Abbildung von Quereinstiegen,
die ganzen Themen, Aufnahmeverfahren, das Zulassungsmanagement,
was wirklich in jedem Studiengang extrem unterschiedlich auch gehandhabt wird an der FAVA-Berg.
Selbstverständlich der ganze Bereich der Studierenden und Stammdaten, Imatrikulationsprozess, Beurlaubung,
Teilstudium, Stipendien, aber auch bis hin auch zum Thema Antragsmanagement.
Ein Riesenpunkt hat natürlich das ganze Thema Lehrveranstaltungsmanagement mit eingenommen,
ganz klar mit der kompletten Stundenplanung. Thema Wahlfachmanagement,
auch ein Bereich waren Lehraufträge und die ganze Abrechnung der Dozierenden.
Natürlich der ganze Bereich Prüfungsmanagement, was mich vorhin ein bisschen gewundert hat,
dass gerade das eines der Themen wäre,
wo besonders viele sich im nächsten Jahr auch Weiterentwicklungen wünschen.
Denn also wenn das schon perfekt überall läuft,
dann sollte das ja eigentlich ein Thema sein,
was eigentlich fast schon gesetzt ist sozusagen,
waren auf jeden Fall hier ganz spannende Anforderungen auch nochmal,
die auf uns zugekommen sind, gerade im Bereich International Office, Anerkennungsprozess.
Und man sieht es auf der rechten Seite tatsächlich aufgrund dieser extremen Integration des alten Bestandssystems,
war das natürlich auch eine riesige Herausforderung für uns,
wieder eine Unmenge an Schnittstellen zu realisieren.
Thema Mobility Online, natürlich auch die Anbindung an SAP,
in dem Fall an Elias,
als E-Learning-System und wie man oben rechts auch nochmal sieht,
es wurden insgesamt etwas über 400 einzelne Berichte und Auswertungen für die Studiengangsmitarbeiter und über 200 Dokumentvorlagen erstellt,
an Bescheiden, an Transcripts, an Diplomas Supplements.
Dazu hatten wir im letzten Jahr auch mal einen kleinen Vortrag gemacht,
auf welcher Basis das sozusagen funktioniert hat. Ja,
diese Dokumente, also wir sind wirklich relativ weit in der Digitalisierung,
die werden auch digital signiert, nach EU-Vorschrift,
also nicht mit irgendeiner freien Signatur
Paar Dinge waren für uns schon ganz entscheidende Anbindung eines SAP-Systems.
Wir legen zwar Wert darauf, dass wir sehr viele interne Lernende haben aus Qualitätsgründen.
Wir haben aber auch ein paar hundert Externe.
Und das sind Prozesskosten. Wir müssen Verträge anlegen.
Sie müssen es bei der Sozialversicherung anhand und haben melden.
Sie müssen die Honorarehauszahlen teilweise in Metallzahlungen. Da war für
uns zum Beispiel entscheidend, dass wir professionelle SAP-Schnittstelle haben,
weil wir FIH ja mit der SAP machen. Office 365,
Reländersystem, ja, das Portal, das im Movetifisch responsive,
wird in einer zukünftigen Version quasi auch via App zu behandeln sein.
Uns ist auch ganz wichtig, dass die Termine ja auch für die Studierenden,
damit sie sich an einen Arbeitsprozess gewöhnen,
in einem Office-Kalender eingetragen sind, dass sie eben sehen,
wann ist mein Kollege frei, wann ist mein Hochschullehrer frei,
wann kann ich Arbeitsgruppen bilden und so weiter.
Also es sind trotzdem großen Deckungsgrad natürlich eine Handvoll Schnittschnell
übrig geblieben. Die waren uns aber strategisch wichtig.
Genau, die haben wir auch alle entsprechend entwickelt.
Wir hatten auch keine andere Wahl sozusagen in dem Projekt,
aber es sind echt spannende Module bei rausgekommen und einfach nur nochmal ganz kurz subsumierend,
also was waren unsere wichtigsten Erkenntnisse, die wir daraus gezogen haben?
Auch nochmal ganz kurz Datenmigration. Je früher sie das machen,
dass du früher können sie mit Echtdaten arbeiten,
desto früher können sie testen und ihre Mitarbeiter bekommen ein viel besseres Gefühl für die Software.
Genau, dass eben auch die unterschiedlichen Prozessbereiche eben nicht sequenziell,
sondern wirklich parallel betrachtet werden. Die Prozessharmonisierung sollte idealerweise nicht
auf der grünen Wiese, sondern anhand eines möglichst ausgereiften Produktes erfolgen.
Denn dann haben die Mitarbeiter eine viel bessere Vorstellungskraft,
wie am Ende ein System oder ein Prozess besser gesagt in einem System abgebildet werden kann.
Diese User-Story, das User-Story-Format haben wir vorhin gerade schon mal erwähnt,
zwei sagen sie mir noch besonders wichtig,
die auf der einen Seite, da möchte ich mich auch nochmal bedanken,
es braucht ein starkes Projektmanagement auf Kundenseite, wirklich auch mit Entscheidungskompetenz, wo Entscheidungen auch getragen werden können.
Sie sollten, wenn sie sich für ein Entwicklungsprojekt entscheiden,
einen Product Owner des Anbieters mit in die Prozessharmonisierung mit reinbringen,
denn sie werden bei der Komplexität Architektur und Entscheidungskompetenz benötigen,
wenn es um die Weiterentwicklung der Software geht.
Und das vielleicht eher noch dann so ein bisschen jetzt ins Auditurm auch nochmal gesagt,
wir haben uns damals für den Hardcuts sozusagen entschieden,
es war wirklich der große Schlag, der eine Tag,
an dem das gesamte System sozusagen umgestellt worden ist,
das wurde auch intern heftig diskutiert, wir haben im Nachhinein immer gesagt,
es war die richtige Entscheidung, aber Ein ganz spannender Punkt ist dieser Tag der Systemeinführung sozusagen.
Und der will wohl überlegt und wohl kommuniziert sein. Und damit,
glaube ich, können wir den Vortrag jetzt beschließen und hoffen,
sie haben einige spannende Anregungen mitgenommen und freuen uns natürlich auf
die Fragen