Guten Tag. Wunderbar. Mein Name ist Nils Bauer,
ein Datenlotse, kleine Firma hier in Hamburg,
die sich auch mit Hochschulen vor allem und eigentlich nur mit Hochschulen beschäftigt.
Wir sind heute zu ihnen gekommen,
weil wir im Moment als Unternehmen uns in einer sehr lernenden Phase befinden,
nachdem wir circa 80 Hochschulen in Deutschland, Österreich,
Schweiz, Türkei mit einer Campus-Management-Lösung unterstützen,
haben wir intern einen Generationswechsel unserer Software eingeleitet vor zwei,
drei Jahren und machen mit diesem Generationswechsel im Moment erste Erfahrungen.
Und über die wollen wir ein bisschen berichten bzw. mit
ihnen sprechen
Dabei ist Herr Maas, der seit einigen Jahren bei den Datenlotsen
ist und der Kopf hinter der neuen Software-Technologie NT als Chefentwickler.
Und mit dabei ist Herr George, der als Projektleiter und Berater
in verschiedenen Hochschulen Campus nett und Campus nett in Tee einführt.
Herr Maas, erste Frage an Sie. Bei unserer neuen
Software-Generation sprechen wir von adaptiver Software. Was heißt das?
Im Grunde bedeutet es das, dass wir nicht mehr
jede einzelne kleine Anforderung in einem Kundenprojekt spezifisch umsetzen müssen.
Wir erlauben es, die Vorteile einer Individualsoftware in den Oberflächen,
in unseren Präsentationsschichten durch den Kunden zu konfigurieren.
Stell dir vor, in der Vergangenheit hatten wir neue Anforderungen
im Bereich zum Beispiel des Prüfungsmanagements. Anforderungen,
die ausgesagt haben, dass zum Beispiel Leistungen vollständig bestanden werden müssen,
wenn sie zwei Leistungen haben im zweiten Versuch, entsprechend Geschäftsregeln hinterlegt haben,
dass der erste Versuch in bestimmten Kontexten ungültig wird.
Solche Regelungen haben wir in den vergangenen Jahren fest implementiert,
in Software kodiert
Das haben wir in unterschiedlichsten Varianten gemacht, weil wir unterschiedliche Kundentypen unterstützen,
sodass es sehr große Prozessvarianten gibt, die unsere Software unterstützt.
Wir aber tatsächlich in der Usability die Spezifika für den einzelnen Kunden,
für den einzelnen Endanwender nicht mehr so optimal darstellen konnten,
dass ein Endanwender ohne Anleitung, ohne Prozessbeschreibung sich in der Software selber wiederfindet.
Das heißt, wir haben sehr viel Funktionen gebaut,
sehr viel Knöpfe, sehr viel Algorithmen in die Software gebracht.
Und was machen wir jetzt anders? Was wir jetzt anders machen lässt,
dass wir die Funktion und die Knöpfe,
die wir in der Vergangenheit in die Software gebracht haben,
Schlicht und ergreifend auf einem Orchestrationslayer in den Oberflächen,
Benutzer spezifisch zu konfigurieren.
Stell dir vor, eine bestimmte,
in einem bestimmten Prozess wie dem Akzeptieren von Bewerbungen sind bestimmte Geschäftsprozesse,
die der Kunde unterschiedlich einsetzt.
Zum Beispiel Regelwerke wie eine Bewerbung akzeptiert wird, die sehr kundenspezifisch ausgeprägt sein können.
Die Kommunikation mit dem Bewerber, das ist die Fragestellung,
welche Dokumente übersandt werden und wie das tatsächlich in der Software realisiert wird.
In der Vergangenheit und in vielen Enterprise-Software-Systemen ist es einfach
schlicht und ergreifend der Fall,
dass dann durch den Endanwender die Funktion in der Software
geklickt werden müssen
Serien-E-Mail verschicken, Bestätigung der Überprüfung des Bewerbungsformulars und ähnliche Daten.
Wir haben uns gesagt, das ist nicht das, was der Enter anwenden möchte.
Der Endanwender möchte von seinem Geschäftsanwendungsfall eine Bewerbung akzeptieren oder beziehungsweise
den Prozess hinter dem Akzeptieren einer Bewerbung durchführen,
mit der Prüfung der Bewerbung, mit der Kommunikation,
mit all diesen Dingen. Unser Ziel war es,
genau das, dem Endanwender Transparenz zumal zu bieten,
ohne dass er die technische Komplexität der einzelnen Domain,
die erhebliche Geschäftslogik enthalten und der komplexen Technologie,
die sich hier verbirgt, von Serverinfrastrukturen, Cloud-Szenarien und entsprechend zu Astrahieren.
Dass wir gesagt haben, Wir integrieren den Benutzerprozess in der Oberfläche.
So, jetzt müssen wir das mal versuchen, konkret zu machen.
Können wir mal einen weiter springen in der Folie?
Dieses Konfigurieren versus Programmieren. So habe ich dich verstanden.
Also bevor haben wir hart codiert in den Code, jetzt konfigurieren wir.
Tobias, das machst du im Moment mit Kunden.
Das machen wir an verschiedenen Stellen mit Kunden und nutzen diese neue Software-Generation.
Kannst du uns mal an einem Beispiel erläutern,
was ihr da genau tut?
Das geht nicht. Im ersten Mal geworden.
Sekunden gibt es
Ja, klar. Warten Sie kurz. So, das
kann man eigentlich sehr wunderbar machen. Wir betrachten Folgendes.
Wenn wir jetzt aus dem Bereich des Bewerbungsmanagement unterwegs bleiben,
da haben wir die Situation,
dass jeder Kunde sein eigenes Bewerbungsformular einsetzen möchte,
mindestens eins zum Teil auch eine beliebige Anzahl von Bewerbungsformularen,
die dazu führen, dass für unterschiedliche Bewerbungsverfahren die Anforderungen und Prozesse sehr unterschiedlich aussehen.
Das führt zum Beispiel dazu,
dass wir in der Vergangenheit Hochschulen haben,
die haben vielleicht fünf Abschnitte in ihrem Formular,
andere haben bis zu
Was alle gemeinsam tun müssen, ist natürlich die Bewerbung,
nachdem sie eingegangen sind, zu prüfen.
In diesem Bereich haben wir drei unterschiedliche Szenarien, die wir kennen.
Der erste Fall wäre, sie wollen die Bewerbung vollständig prüfen. Das heißt,
sie gucken sich die eingegangenen Unterlagen an und prüfen,
fällt für Feld, ob alles übereinstimmt, bevor sie später entscheiden,
ob die Person einen Studienplatz bekommen kann oder nicht.
Das andere Szenario auf der anderen Seite ist,
wir verzichten auf die Prüfung am Anfang,
lassen die Personen zu und prüfen im Rahmen der Imatrikulation
Und haben dort gegebenenfalls den Nachteil,
dass die Person falsche Angaben gemacht hat oder unplausible Angaben,
die im schlimmsten Fall zu einem Widerruf der Bewerbung führen.
Wir haben uns jetzt in dem konkreten Beispiel für den dritten
Weg entschieden und gesagt, wir wollen nicht alles prüfen.
Wir wollen aber jetzt für diese spezifische Bewerbungsverfahren
ganz klare Regeln definieren, nach denen wir prüfen.
Und zwar faltgruppenbasiert. Und diese Fallgruppen werden durch den Kunden
definiert und die können pro Kunde und pro Bewerbungsverfahren
vollkommen unterschiedlich aussehen
Das heißt, wir haben hier eher so einen stochastischen Ansatz.
Wir versuchen, die knappen Ressourcen der Hochschule so optimal zu nutzen,
dass der Sachbearbeiter sich auf die Fälle konzentrieren kann,
die tatsächlich problematisch sind. Während die Fälle,
die unproblematisch sind, durch den Prozess komplett durchgebunken werden können.
Und dafür haben wir am Anfang ein Z an Regeln definiert.
Und das würden wir Ihnen gerne an einem Beispiel mal zeigen.
Ja, ich habe jetzt verstanden, wir haben genau das,
was wir jetzt hier mal aufgemalt haben, einfach mal im Kundenkontext konfiguriert.
Das würde ich jetzt einfach mal zeigen in einem Cloud-Szenario.
Ja, ist natürlich über das Internet
Und ihn einfach mal an der Software präsentieren.
Mit dazu muss ich einmal unsere wunderschöne Präsentation hier beenden.
So, ich hoffe, Sie können meinen Bildschirm jetzt sehen.
So, in der Software drin, ich habe mich schon
mal angemeldet, aufgrund der Squats und Slots.
Also Sie sehen, es ist das benutzerzentrierte Dashboard-Team. Ich habe verstanden,
dass auch nach den Benutzeranforderungen konfiguriert worden von euch im Projekt,
wo wir tatsächlich hier unterschiedlich einen Geschäftsprozessablauf in der Software sehen.
Die Software läuft bei mir, lokal der Verwaltungskleid auf meinem Rechner,
die Serverinfrastruktur mit der komplexen IT-Landschaft bei einem Kunden über das
Internet,
also nicht lokal hier
Was Sie sehen, ist tatsächlich, dass dieser Stashboard den
kompletten Prozess abbildet, den dieser Kunde entsprechend konfiguriert hat.
Wir sehen für Bewerbung im ersten Fachsemester. Das heißt,
als Bewerber als Person, als Sektalitärz-Mitarbeiter im Bewerbungs- und Zulassungsmanagement,
ziehe ich meine Prozesse hier. Ich sehe die Bewerbung,
die aktuell eingegangen sind, die abgeschickten Bewerbung. Die Bewerbung,
mit denen ich heute arbeiten muss, der direkte Zugriff in die Software,
ohne über komplexe Menüstrukturen navigieren zu müssen oder ähnliches.
Ich kann in die Software direkt ansteigen hier. Das Ganze funktioniert natürlich
auch wunderbar mit Touch. Mein Stärkerechner hat Touch und wir sehen hier,
dass tatsächlich auf dem zweiten Dashboard Für höherem Fachbesemester ein ähnliches Dashboard eingerichtet worden ist,
dann für die Prozesse, aus dem für höhere Fachsemester,
sodass der Mitarbeiter, der sich jeweils mit der Software verbunden hat,
direkt in der Software arbeiten kann.
Heißt, benutzerzentrierte Ausgestaltung dieser komplexen Infrastruktur, dieser komplexen Geschäftsregeln
in einer Standardsoftware. So, jetzt wollen wir lernen,
ihr habt jetzt Geschäftsregeln definiert, so habe ich euch verstanden.
Also die Hochschule hat vorher unser altes System genutzt,
hat bestimmte Knöpfe gedruckt beim Akzeptieren irgendwelcher Bewerbung beim Prüfen.
Und ihr habt euch jetzt überlegt,
nach irgendwelchen Kriterien können wir diese bestimmten Bewerbungen abfangen und können
sie automatisch weiterleiten oder einer besonderen Bearbeitung zu führen.
Und diese Geschäftsregeln habt ihr hinterlegt, Macht ihr das und
wie macht ihr das? Ja, ganz kurz zur Orientierung.
Wir haben hier vom Prinzip abgeschickte Bewerbungen, die gehen ein,
die werden im Campusnetz-Standard akzeptiert im ersten Schritt.
Das führt dazu, dass wir entweder hier auf den rosa-violettfarbenen
Kacheln landen, wo wir Bewerbungen sperren. Das heißt,
das sind diejenigen, die die Sachbearbeitung nochmal prüfen möge.
Oder in Abhängigkeit der Verfahrensschritte, dass wir im Bereich eine
Ereignungsprüfung einsteigen oder falls es sich um ein zulassungsfreies Verfahren handelt,
direkt zu den akzeptierten Bewerbungen weitergehen können.
Das heißt, die Bewerbung wird direkt gelotst
Wir jetzt zum Beispiel rausgesucht, wo wir bei einer Sperre
gelandet sind, das ist eine fachlich inhaltliche Festlegung.
Und wir haben für Sie heute das Beispiel einfach mitgebracht,
der Bewerber gibt das Datum der Hochschulzugangsberechtigung an und ergibt in
dem Fall einen Wert an der nicht plausibel ist.
Und deswegen neue Geschäftsregel, die jetzt gekommen ist,
ich sage bestimmte Bewerbungen, untersuche ich auf das Kriterium,
nicht plausible HZB.
Das ist etwas, was wir bisher in Camposnet als algorithmisch
kodiert nicht hatten. Das habt ihr jetzt konfiguriert als Geschäftsregel
und führt jetzt was durch mit dem Nutzer
Wir haben hier die Bedingungen konfiguriert, dass die ausgegeben wird im Rahmen einer Sperre.
Wir sehen hier, der oberste Fall ist das Datum der Hochschulzugangsberechtigung.
Das ist unplausibel und es wird hier auf der Liste dargestellt.
Wir haben uns im Vorfeld überlegt, was kann man
in einem solchen Fall machen? Und wir haben gesagt,
okay, wir hinterlegen dort einen Entscheidungsbaum,
den wir gemeinsam in der Prozessdefinition festgelegt haben und haben gesagt,
okay, es gibt unterschiedliche Möglichkeiten.
Eine der Antworten führt dazu, dass ich den Datensatz korrigieren
kann und er am Verfahren weiterhin teilnehmen kann.
Die zweite Antwort würde dazu führen, dass wir sagen,
die Angabe Ist so unmöglich,
dass die Person nicht am Verfahren teilnehmen kann und wir sie deswegen vorläufig ausschließen.
Und die dritte Option ist, wir können keine Entscheidung treffen,
da uns unklar ist auf Basis der Aktenlage,
wie wir entscheiden können.
Und wir müssen mit dem Bewerber in Kontakt reden.
Wir haben jetzt an der Stelle einen Assistenten gestartet.
Das ist was jetzt mit der neuen Softwaregeneration neu hinzugekommen ist.
Im Gegensatz zu der funktionsgetriebenen Arbeit in der Classic-Infrastruktur
führt dieser Assistent uns jetzt ganz bewusst dahin.
Der Assistent hat hier gewusst,
es handelt sich um die Sperre
Datum der Hochschulzugangsberechtigung ist falsch. Die sehen,
der Assistent ist aufgerufen. Sie sehen an der Stelle,
dass das Datum der Hochschulzugangsberechtigung hier handelt es sich drum.
Und wir sehen jetzt aus der Bewerbung der Konkreten nur die Informationen, die prozessrelevant ist.
Alle weiteren Abschnitte des Bewerbungsformulars werden nicht angeboten, sondern ausschließt die Informationen,
die wir benötigen, um eine Entscheidung zu treffen.
Bedeutet das, dass tatsächlich der Wizard,
dieser Assistent von der Liste der Sperren,
wo wir gerade draufgestanden sind, hier die Daten genau anzeigt,
die der Nutzer benötigt aus der Bewerbung?
Genau. Wir haben genau das überlegt, was brauchen wir,
was müssen wir tatsächlich sehen und nicht mehr und nicht weniger an dieser Stelle.
Dominik, jetzt interessiert mich folgendes. Ich habe so ein
Wizard hier. Hier steht irgendwie E-Mail bearbeiten. Kann ich
das jetzt als Kunde sagen? Nee, in dem Schritt
will ich das. Ich will da was anderes machen?
Genau das. Der Wizard entscheidet aufgrund deiner Entscheidungen, was
du tatsächlich tun willst. Wir automatisieren Prozesse. Das bedeutet,
das, was hinter dem Akzeptieren ist oder jetzt einer falsch eingegebenen Bewerbung,
wird durch den entsprechenden Sachbearbeiter ausschließlich abgefragt, was er benötigt.
Er macht keine Systemaktionen mehr. Sowas wie die Serien-E-Mails senden oder irgendwie so etwas,
sondern ausschließlich gibt er das Ergebnis der Prüfung ein und sagt jetzt,
dass die entsprechende Halbzeit B korrigiert worden ist oder nicht
Und bitte konfiguriert, wie es in diesem unterschiedlichen Fällen entsprechend
weitergeht und abgebildet wird. Und diese Regeln habt ihr euch
im Projekt ausgedacht und habt zur Echtzeit konfiguriert. Das heißt,
du hast dich mit dem Kunden hingesetzt und hast gesagt,
wir wollen jetzt mit den Bewerbungen, die wir noch checken wollen,
wollen wir durch diese fünf Dinge gehen.
Wie lange brauchst du dafür? Um so ein Wizard aufzubauen und die Geschäftsregeln,
die der Kunde dir frei diktiert hat,
weil er das seit fünf, drei Jahren mit unserer Software alt bearbeitet,
sich das so optimieren will, wie lange habt ihr dafür gebraucht?
Dafür haben wir an sich gar nicht lang gebraucht.
Das Wichtigste und Schwierigste an der Stelle war,
einmal festzulegen, wie soll der Prozess genau aussehen?
Wir mussten entsprechende Dokumenttemplates abstimmen und danach ist das eine Sache
des Doings.
Wir sind da
extrem fix unterwegs
Dominik, wenn wir früher sowas programmiert hätten, ja.
Heute konfigurieren wir. Ja. Hätten wir das komplett ausprägen müssen für einen spezifischen Kunden,
hätten sie in den Standard überführen müssen und hätten im Long-Term-Release-Management das schiffen müssen an die Hochschulen.
Noch nicht mal das tatsächlich. Ein solcher Prozess wäre nicht
einfach abbildbar gewesen, weil wir Standard-Software herstellen. Das heißt,
welche Entscheidungen und was passiert abhängig von der Entscheidung, können wir in unserer Software nicht hardcodieren,
beziehungsweise müssen wir mit sehr vielen Systemparametern dann an die unterschiedlichen Hochschulen von 50 Studierenden bis 100.000 Studierenden anpassen, wo die Bewerbungsverfahren natürlich sehr unterschiedlich gestaltet sind. Jetzt haben wir die Möglichkeit,
das zu konfigurieren, eine entsprechende Programmierung einer solchen Funktion,
hätte den kompletten Release-Zyklus, der bedeutet, mit Qualitätssicherung,
mit Dokumentation und Ähnlichem und hier tatsächlich eine Konfiguration,
die natürlich auch qualitätsgesichert wird von der Fachlichkeit,
aber in einer Standard-Software die Vorteile eine Individualsoftware hebt und die Kundenprozesse,
also den Endanwender, der davor sitzt, das zeigt,
was er benötigt, um seinen Geschäftsprozess durchzuführen,
wie hier schlicht und ergreifend die Informationen anzuzeigen,
welche Informationen brauche ich aus der Bewerbung,
um jetzt die Entscheidung zu treffen,
ob diese Informationen aufgrund des Sperrtyps, den wir hatten,
entsprechend positiv oder negativ sind und den Prozess,
der dahinter läuft, die Dokumentarstellung,
Versand von E-Mails und,
und,
Abzubilden. Danke. Können wir einmal zurückspringen in die Präsentation?
Weil wir noch fünf Minuten haben und ich würde jetzt gerne
die eigentliche Frage unseres Vortrages oder unserer kleinen Impression hier ganz am Ende,
wenn du da einmal hinklickst, stellen.
Nämlich, wie ist das mit dem Henne-und-Ei-Problem?
Was ich gerade oder was wir gerade verstanden haben und was
wir als Unternehmen gerade verstehen, ist folgendes.
Unsere Berater, unser Professional Service Team kann zum Kunden gehen
und ist in einer Hinsicht freier geworden,
in der anderen Hinsicht belasteter
Die sind freier von den Systemanwendungsfällen,
die wir vorher in der Software hatten,
weil wir bestimmte Funktionen zur Verfügung gestellt haben in den Workshops,
die Mitarbeiter aus den verschiedenen Dezernaten sich hingesetzt haben und geguckt haben,
was können wir jetzt hier einrichten,
was können wir hier machen, wie läuft der Prozess,
haben sich aber entlang gehangelt an Funktionen,
das stellen wir jetzt mehr in den Hintergrund,
wir werden freier und die Frage ist,
was brauchen wir dann eigentlich im Projekt,
um jetzt wirklich auf die Prozessdefinition,
die Anwendung der Geschäftsanwendefälle zu kommen,
die ich dann frei im System zu Systemanwendungsfällen werden lassen kann,
wie ich es gerade gesehen habe,
nach meinem Wunsch,
nach meiner Konfiguration
Wie habt ihr das gemacht? Wie seid ihr vorgegangen?
Und auf welche Hürden seid ihr da gestoßen? Ja,
also in dem Fall haben wir eine ganz klare Situation.
Wir haben jetzt nicht, wie zum Beispiel im Vortrag,
weiter vorne schon mal gehört, die Södertön Zirks Cola beispielsweise.
Das war eine Universitätsgründung auf der grünen Wiese, wo man komplett Softwaresysteme hinstellen konnte.
Wir haben hier die Situation, dass wir auf bestehende Systeme,
bestehende Prozesse drauf zurückgreifen mussten und die berücksichtigen.
Das war ja unsere Ausgangslage. Wir sind dort,
da die Prozesse im BPNM-Format vorlagen, die Bestehenden,
Die sind wir einmal durchgegangen, haben uns aber mal losgelöst von dem,
was ist. Und sind diskutiv damit umgegangen,
was sind denn unsere tatsächlichen Prozesse und was sind Aspekte,
die dem Aufruf von Funktionen geschuldet sind.
Im Wesentlichen haben wir das zusammen fast, sagen wir mal, Autobahnen gesucht.
Abkürzungen, wie gehen Sachen schneller? Wie gehören Sachen,
die zusammengehören? Wie kriegt man die auch zusammen? Und das,
was wir jetzt hier in einem Assistenten gesehen haben,
dass der zum Beispiel automatisch einen Brief verschickt,
automatisch eine Bewerbung ausschließt und automatisch noch eine E-Mail zusätzlich versendet,
während früher in der Darstellung einzelne Funktionsschritte gewesen,
die wir aufgerufen haben.
Und das war einfach nicht mehr nötig.
Neben diesem Aspekt haben wir den pragmatischen,
haben wir natürlich auch Best Practices mitgebracht und gesagt,
okay, so könnte das sein.
Und dann haben wir das entschieden, einmal verprobt und dann bestätigt,
dass der Prozess so durchgeführt werden soll.
Dominik, du und ich machen gerade was Spannendes.
Wir managen zu zweit eine Küche. Haben wir so genannt
. Dort haben wir einen großen Kunden,
der hat tausend Mitarbeiter und bearbeitet mit diesem Kunden 30.000 Bildungsmaßnahmen mit 150 Millionen Euro Umsatz pro Jahr.
Und reist vier Altsysteme raus und stellt diese Lösung dort rein
Ja. Wir haben das Problem,
dass dieser Kunde schon sehr alt ist, sehr lange arbeitet,
sehr tradiert arbeitet und wir im Rahmen der Soll-Konzeption eigentlich die verschiedenen Fachabteilungen vom Kundenmanager,
vom Produktportfolio-Manager sind immer Bildungsprodukte, Seminare, Fortbildung, Zertifizierung,
dass wir die nicht so richtig unter einen Hut gekriegt haben und unsere Soll-Konzeption hat auf so einem oberen Level geendet,
woran eigentlich kein System ausbringen kann,
weil man nicht genau sagen kann, wie jetzt genau,
welche Attribute braucht ihr,
wann soll die E-Mail jetzt genau verschickt werden und wie sah das im Altsystem aus,
denn sagen die Chefs immer, nein,
das wollen wir ja nicht nachbauen, wir wollen was Neues machen.
Diese Küche stellt uns zwar Herausforderungen, weil wir mit dem Kunden,
deswegen haben wir es Küche genannt,
an die Software gehen und zur Echtzeit konfigurieren und dabei Dinge klären
Welchen Sinn machen noch Sollkonzepte? Welchen Sinn machen Prozessfestlegungen vor so
einer Softwarekonfiguration, müssen die detaillierter werden, weniger detailliert sein?
Was erlernen wir da in der Küche? Also tatsächlich gibt es
einen großen Shift in der Frage, wie soll Konzeptionen gestaltet werden?
Software, Implementierer und Softwarehersteller neigen dazu,
den Kunden tatsächlich von seinem konkreten Problem auf eine spezielle Funktion,
die die Software dadurch durchsetzen kann, die den Prozess durchführbar macht,
zu leiten.
Was wir tun, ist tatsächlich mit der Technologie
den Geschäftsprozess zu analysieren. Wir brauchen den Geschäftsprozess,
also was will der Kunde eigentlich
Und welche Schnittstellen gibt es zum Beispiel für Entscheidungen oder ähnliche Parameter
, aus den unterschiedlichen Kategorien. Das können Fremdsysteme sein,
das können entsprechende Entscheidungen von Sekretärinnen und Ähnlichem sein. Das bedeutet,
die Geschäftsprozesse und deren Optimierung stehen im Vordergrund, nicht mehr die Softwarefunktionalität,
auf die dann tatsächlich das System und die Prozesse hin,
sagen wir mal, angepasst werden müssen.
Okay. Dann sind wir sozusagen bei unserem Henne-Ei-Problem schlussendlich angekommen. Die Frage,
wenn ich freier werde, was das definieren und konfigurieren,
im Rahmen solcher adaptiver Softwarelösungen anbelangt, kann ich mich freier
mit dem Definieren des Geschäftsanwendungsfalls und weniger mit den Limitierungen der Technik befassen.
Insofern lösen wir, glauben wir,
durch diese neue Generation das Henne-Ei-Problem so, dass wir sagen,
als erstes kommt der Geschäftsanwendungsfall und dann setzen wir den Systemanwendungsfall konfigurativ im System um.
Das lernen wir gerade, weil das ein Generationenwechsel ist von Software,
Lösungen für solche Prozessmanagement, Unternehmenssoftware,
mit der wir an der einen oder anderen Stelle für uns in neues Fahrwasser kommen,
mit den Hochschulen in neues Fahrwasser kommen und bestimmte Referenzen,
Art Vorlagen auch ausprägen werden.
Kann man solche Wizards eigentlich übernehmen? Kann man das nächste Geschäft mit rübernehmen,
sagen, die Hochschule sieht den und sagt, ja,
so wollen wir das auch machen?
Oder wir wollen da zwei Schritte weniger haben. Also,
die kann man übernehmen. Tatsächlich ist das ein großes Baukassensystem für schnellere Einführungen,
die tatsächlich aber auch einen angepasst werden können an den einzelnen Anwendungsfall.
Das Entscheidende im Projektvorgehen ist, dass sie direkt angepasst werden können.
Das heißt, man kann im Rahmen des Workshops zu der Geschäftsprozessanalyse,
dass es dementsprechend umsetzen und dem Kunden reflektieren.
Das sorgt dafür, dass Endanwender ein viel besser widerspiegeln können,
was sie tatsächlich benötigen
Warum ein Pusch-Zerschritt sinnvoll oder nicht sinnvoll ist. Das ist ein entscheidender Punkt,
der in der Vergangenheit durch die Software-Implementierung nur in sehr geringem Maßen möglich war.
Vielen Dank. Wir haben angeknüpft an das, was Herr Sachse
letztes Jahr hier vorgestellt hat, die Vision einer adaptiven Software.
Jetzt ist sie da, wir rollen sie aus bei Kunden,
diese Lösung, die Sie gerade gesehen haben,
geht Montag mit in einer 25.000er Hochschule in den Live-Betrieb
und wird dann in den nächsten acht Wochen 40.000,
20.000, 25.000 Bewerbungen abfeiern.
Und wir werden sehen, was die ersten Erfahrungen sind.
Vielen Dank für Ihre Aufmerksamkeit