Schönen guten Tag, Damen ist mein Name.
Guten Tag, Herr Damen. Ich bin der Projektleiter der Kleosheinski
MbH. Wir haben bei Ihnen gerade die Ausschreibung für das Campusmanagement gewonnen.
Das freut mich. Mein Name ist Marco Link.
Ich bin Projektleiterin auf Seiten der Uni Bern.
Und freue mich jetzt auf unser Projekt. Das ist ja
schön. Ich habe Ihnen etwas mitgebracht. Das ist DCC
, unseres Campusmanagements. Sie können das den Informatikdiensten übergeben.
Die können das dann in der nächsten Woche installieren.
Und wir sehen uns dann in sechs Monaten wieder,
wenn das ganze System läuft und kommen dann zur Abnahme.
Ja, aber Moment bitte, wir haben doch noch Fragen und
ein paar Anpassungswünsche und wir wollten uns das doch zusammen anschauen.
Nein, also wir haben eine Ausschreibung gewonnen, in der
ganz klar war, dass sie ein Produkt gekauft haben.
Und das werden wir
jetzt durchführen
Das können sie nur neuen Storys. Achso, war das
doch nicht gemeint? Meine Damen und Herren, genau das
ist, dass wir ein Compuse-Management-Projekt natürlich nicht laufen sollte.
Deswegen haben wir diesen etwas bösen Titel genommen.
Heute Morgen hat es einen Vortrag gegeben aus der Universität Paderborn,
wo es auch schon darum ging, wie schwierig es eigentlich ist, diese Projekte durchzuführen.
Wir werden jetzt ein bisschen aus dem Nähkästchen versuchen zu plaudern und
ein paar Tipps und Tricks und so weiter, ihnen zu zeigen,
das ist nicht allumfassend, was wir hier vorstellen können.
Zum Inhalt, wir werden das Projekt kurz vorstellen
Größe Uni, was die Projektfeatures sind und so weiter.
Dann geht es darum, die Frage,
warum sprechen wir von Individualentwicklung beim Campusmanagement? Haben wir vielleicht
die falsche Vorstellung von Produkten? Dann kommt die Frage,
wie man ein solches System erfolgreich eingeführt werden kann.
Sie sprechen sehr oft von Prozessen, Organisationsprozessen und so weiter.
Wir gehen mal auf Use Cases ein. Es ist aber
im Grunde genommen dasselbe Wort. Es kommt nur aus der IT
. Und zum Schluss, wenn wir noch Zeit haben,
kommen wir mit drei Folien zu Tipps und Tricks.
Da der Vortrag nachher zum Download zur Verfügung stellt,
können Sie die Trips sich natürlich später auch noch angucken
Somit möchte ich hingehen, zuerst einen kleinen Überblick über
die Größenordnung der Universität Bären und des Projektes Carsell geben.
Die Universität Bären ist eine Volluniversität mit acht Fakultäten und circa 65,
60 Fächern. Wir haben 15.000 immatrilimatikulierte Studierende. Und für
das Projekt sind auf Seiten Cleo 3.500 Personentage investiert worden.
Auch auf unserer Seite sind wir auf 2.500 Tage gekommen
oder werden wir kommen
Auch eigenen Hinweise auf die Größenordnung geben die Altdaten,
die wir von den bestehenden Systemen in das neue System übertragen.
Das sind einerseits 75.000 Veranstaltungen aus 20 Jahren und andererseits werden es bis Herbst,
sind das jetzt bis Herbst 2012, 730.000 Noten.
Wir haben zu Beginn des Projektes uns entscheiden müssen,
ob wir die Einführung modular oder mit einem Big Bang machen
Risikominimierung einerseits und auch da ist eigentlich die Aufstrittung der bestehenden Systeme bereits nahegelegt haben,
haben wir uns für ein iteratives, modulares Vorgehen entschieden.
Dies bedeutet für die Arbeitsschwerpunkte, was ihre Kurven zeigen.
Am Anfang war die Konzeption natürlich im Vordergrund.
Und dann ist das Rollout, die ist der Arbeitspunkt Rollout
immer wichtiger geworden oder wird immer wichtiger.
Es gibt aber durchaus am Beginn des Projektes eine Phase,
wo beide Punkte
sehr intensiv bearbeitet wurden
Bei der Planung ist natürlich wichtig, dass man die Modularität gut plant.
Es gibt viele Abhängigkeiten und Vorarbeitende, die geleistet werden müssen,
bevor das eine Modul nach dem anderen eingeführt werden kann.
Dies hat zu folgende Aufteilung geführt. Wir haben 2010
mit dem Studienprogrammen begonnen. Diese mussten ja modelliert werden.
Das sind 400 Studienprogramme, die modelliert werden mussten.
Von diesen abhängig sind es dann im vierten Schritt die Anrechenbarkeit,
die Gefäße. Also wir können die Anrechenbarkeit erst eingeben,
wenn die Studienprogramme modelliert sind
In der Zwischenzeit wurde dann das Veranstaltungsverzeichnis und die Raumverwaltung abgelöst.
Auch diese zwei Module sind stark abhängig voneinander,
da die Veranstaltungen ja in Römen stattfinden und auch in den
Nahlssystemen bereits eine Schnittstelle bestand.
Was uns jetzt, heute, sind wir bei der Anrechenbarkeit
daran, die einzugeben.
Das sind jetzt noch ein Restarbeiten und im nächsten Jahr
wird nun der Teil
Anmeldungen und Noten eingeführt
Okay. Vielleicht etwas dazu zu dem Projektverlauf noch von mir,
die Ausschreibung ist in 2008 gewesen, 2009,
ungefähr im Mai wurde mit dem Projekt wirklich begonnen.
Und die Projektplanung hat sich erstreckt, wenn man ganz ehrlich ist,
von Mai 2009 bis in den Januar 2010 hinein,
weil wir genau die Planspielchen gemacht haben,
wie man die Studienprogramme und zu welchem Zeitpunkt man zum Beispiel diese Module als erstes anführt,
damit man nachher Anmeldungen und Noten einfach in das System hineinbekommt.
Das heißt, wir haben sehr viele Planspiele gemacht,
um diese Module überhaupt so aufzuteilen, dass es auch machbar ist.
Da hängt ja vieles dran, wenn die Veranstaltung nicht funktionieren,
dann haben sie irgendwie keinen Veranstaltungsmanagement, die Studenten wissen nicht mehr,
wohin sie in die Vorlesung gehen können.
Die Notenvergabe muss auch funktionieren. Das heißt, diese Ineinanderverzahnung haben wir gemacht.
Die roten Balken, die hier zu sehen sind,
sind im Grunde genommen immer die Abschaltung eines Altsystems.
Warum sprechen wir von Individualentwicklung beim Campusmanagement?
Was meinen wir damit überhaupt? Wir müssen bei den Individualisierungen
Rücksicht nehmen
Auf Unterschiede und trotzdem Dinge vereinheitlichen, weil wir eine Software bauen.
Meine Uni läuft wie eine Kaserne. Ich höre ja keinen,
der mich jetzt mit Eiern bewirft. Wir haben eine klare
Befehlshierarchie, absolut einheitliche Abläufe, keine individuellen Bedürfnisse.
Das ist Software. Oder ist es vielleicht so,
eine Uni hat eine flache Hierarchie, viele Fakultäten,
sehr heterogene Abläufe und anscheinend, ich sage extra anscheinend,
unzählige individuelle Bedürfnisse, da ist das untauglich für Software.
Und jetzt haben wir
einen Campus
Wir müssen es also schaffen, eine flache Hierarchie abzubilden und
mit Konfigurationen von Regeln individuelle Bedürfnisse unterstützen.
Viele Formen von Abläufen durch Regeln, um einbauen und
dann können wir wieder von Software sprechen.
Das ist das Problem, was wir haben,
wenn wir uns mit Campusystemen in Software unterhalten.
Gibt es überhaupt das Produkt? Alle sprechen vom Student-Life-Cycle.
Es ist eigentlich vollkommen egal, ob wir diesen Life-Cycle hier
aus Amerika nehmen, der heißt gleich.
Es gibt die gleichen Bubbles, es gibt Veranstaltungen,
Prüfungsoffennotenzeugnisse oder wir nehmen den aus
der Uni in Nordrhein-Westfalen oder aus der Schweiz
Das Problem ist eigentlich immer, dass es interne Prozesse gibt,
die an jeder Universität anders sind.
Und dazu kommt noch, dass sie diverseste Dinge drumherum haben.
Ob das jetzt andere in der Trikulationsdaten sind,
ob sie ein SAP für die Personenverwaltung haben,
ob sie ein Berichtswesen haben, anderes E-Learning oder was auch immer,
das kann man jetzt beliebig aufbauen.
Das ist nie gleich. Das heißt,
wenn die nächste Uni kommt, sieht das so aus.
Dann kommt die nächste Uni, sieht das so aus.
Das heißt, das Problem ist, wir haben einen identischen
Kern in der Software. Und unmadning an standortspezifischen Alleinstellungsmerkmalen.
Das heißt, die Integration in diese Systemlandschaften an den Uni
, es wird komplett Überschätzt oder unterschätzt.
Und zwar in der Planung, als auch in der Entwicklung. Das heißt,
wir haben einen Spagat in diesen Projekten zwischen einer Dienstleistung,
die wir machen, einer Anpassung, die wir an die Uni machen müssen.
Wir müssen eventuell noch Organisationsstrukturen ändern. Und das Ganze soll
auch noch in Software abgebildet werden. Hier ist das Problem
, man in Compass-Management-Projekten. Stellen wir uns die Frage,
wie wir das im Projekt umgesetzt haben. Ziel war es ja,
dass wir drei Systeme außer Betrieb nehmen und mit einem System ersetzen.
Und zwar hat ein System das für alle Fakultäten funktionieren soll.
Und eigentlich hätten wir auch acht Systeme einführen können,
Wäre sicher auch gut angekommen, aber das war eben nicht das Ziel.
Um die Fachanforderungen zu definieren, haben wir aber durchaus die Altsysteme berücksichtigt,
berücksichtigt, angeschaut, was funktioniert hier gut, was weniger gut.
Es ist auch wichtig, dass man immer wieder ein wenig
Abstand nimmt, damit man nicht das bestehende abbildet.
Aber auch nicht unbedingt bewährt, es über Bord wirft.
Zum detaillierenden Prozess haben wir es herreng mit Fachleuten als den Fakultäten zusammengearbeitet.
Wir haben die Prozesse geprüft, beurteilt, vereinheitlicht, generalisiert.
Das war sehr wichtig, dass wir versucht haben,
unterschiedlichen Prozesse so zu stückeln, dass sie zu einem,
je nachdem, ja nach Fall anwendbaren Werk zusammengeführt werden konnten.
Bei den individuellen Wünschen hat es auch viel Diskussion gegeben,
da waren auch sehr viele Nice-to-Have-Funktionen darunter,
aber in der Kommunikation mit den Betroffenen konnten wir auch immer wieder eigentlich zu einem guten Ergebnis kommen,
dass wir uns jetzt aufgrund Funktionen konzentrieren und das vielleicht dann
später auch noch das eine oder andere Nice-to-Have folgen kann
Die Aufteilung der Module, das hat sich sehr bewährt,
die Stufen weisser Einführung, hat auch die Möglichkeit gegeben,
zu reagieren, wenn irgendwo etwas vergessen ging bei seinem umfangreichen Projekt,
war das fast nicht anders möglich.
Auch wenn wir uns sehr bemüht haben, eine detaillierte Spezifikation zu machen.
Auf eine neue Organisation der Universität haben wir verzichtet. Wir waren auch die Meinung,
dass das nicht unbedingt von einer Software ausgelöst werden soll,
aber die eine oder andere Anpassung erfolgt durchaus,
da kann ich nur der Aussage im Vorangehenden Vortrag beipflichten.
Das hat damit zu tun,
dass schon jetzt einfach größeres Wissen nötig ist,
um Veranstaltungen einzugeben und auch die IT-Affinität sehr viel wichtiger geworden ist.
Früher war es einfach eingeben von Daten und heute ist ein gewisses Wissen Voraussetzung.
Welche Meilensteine gab es im Vorgehen und welche Tragenbeiz zum Erfolg,
also zum bisherigen. Wir sind ja noch nicht ganz am
Ende des Projektes. Zentral sind sicher die fachlichen Anforderungen,
die müssen da sein,
die müssen
klar formuliert sein
Und wir haben das mit Use Cases, mit Prozessen gemacht.
Die Benutzerinnen einbinden, das war von Anfang an ein großes Anliegen von uns.
Und wir haben das in verschiedenen Stellen des Projektes immer wieder gemacht.
Nach der Konzeptionsphase, in den Testphasen, Pilotphasen etc.
Auch die Politik ist wichtig, die Ansiedelung in
der Hierarchie an der richtigen Stelle war sehr wichtig.
Wir brauchen Rückhalt für sein Projekt durchzuführen,
sonst ist die Akzeptanz einfach auch nicht da.
Projektmarketing und Kommunikation sollen in keinem Projekt vernachlässigt werden,
das gilt auch für KSL
Kommen wir zu den fachlichen Anforderungen. Ich glaube,
das ist der Dreh- und Angelpunkt, wenn wir jetzt mal
nicht davon ausgehen, dass wir noch kulturelle Geschichten haben.
Ich denke mal, das Projekt läuft deswegen so gut,
weil es in der Schweiz läuft.
Das ist jetzt ganz böse. Aber da ist einfach eine,
gerade was die Projektleitung angeht, geht es die Prozesse,
es ist etwas einfacher, den ich hatte,
ja einige Einzelgespräche geführt.
Da kommt das auch heraus. Bei den Use-Cases. Wir bauen
eine Software bzw. wir liefern ihnen eine Software und die muss laufen.
Das heißt, die brauchen absolut genaue Vorstellungen von dem,
was sie haben wollen
Das ist das Fundament, stellen Sie sich einen Betonboden vor,
auf dem haben Sie die genauen Prozesse vorher,
dann können Sie die spezifizieren, Sie können sie entwickeln,
Sie können die in Labors vortesten mit den Benutzern.
Sie können das Rollout läuft und nachher läuft das Ganze auch in echt.
Das heißt, die Studierenden können damit arbeiten oder die Deganate
oder wer auch immer. Das ist aber leider so,
dass über 70 Prozent von Projekten heute aufgrund von falschen Annahmen fehlschlagen.
Das sind Zahlen, die können Sie überall nachlesen.
Die Projekte, die brauchen länger, als man angenommen hat.
Sie kosten mehr und die Realisierung geben über den Benefits,
die passt meistens nicht
Sie können jetzt das Beispiel Berliner Flughafen nehmen,
ist eins, Sie können den Europatunden,
den Tunnel nach England drüber nehmen im Zug.
Ist ein ähnliches, ähnliche Geschichte. Wenn Sie Lust haben,
lesen Sie einfach auf jeden Fall mal was hier über Ben Flifeberg.
Der ist ein Professor, der da seit Jahren drüber forscht.
Was ist denn ein genauer Use Case? Studierende sollen sich
für Veranstaltungen anmelden können. Wenn ich das einem Programmierer in
die Hand gebe, dann macht er das da draus.
So, darauf passiert aber auch meine Schätzung.
Sie müssen die richtigen Fragen stellen
Wenn studieren Sie sich für Veranstaltungen anmelden können, dann brauchen wir
irgendwo einen Prozessablauf. Und wir müssen uns Fragen stellen,
mit welchen Mitteln kann man sich anmelden mit dem Handy?
Oder mit einer Karte? Oder gehe ich hin und
muss irgendwo eine Unterschrift leisten? Woran Anmeldeverfahren, Quittung,
Verfahrenskompolitik, Libilität? All diese Fragen müssten sich stellen.
Das haben wir gemacht zu Beginn des Projektes,
um dann eben Use Cases zu haben, die bis heute noch funktionieren.
Wenn Sie die Auswirkung sehen von solchen Use Cases auf Projektrisiken
und nehmen einfach mal an,
wir hätten 200 Euro für so eine Projektsumme und sie haben
kaum abschätzbare grobe Vorgaben
Oder sie können das Detail auf 80 Stunden Arbeit abschätzen,
dann kann ihnen Folgendes passieren, dass sie,
wenn sie kaum abschätzbare, grobe Vorgaben haben,
dass sie 100 Prozent oben drüber liegen mit ihrem Projekt.
Oder sie bauen mal eben an einem Airbus-Terminal 838 in Berlin,
mal eben das von West nach Ost, dann passiert genau sowas.
Deswegen wird auch immer von Prozessen gesprochen.
Also das muss vorher sein, vorher sein,
bevor wir überhaupt die Modularisierung von so einem Projekt anfangen können.
Ich glaube, vorträgen schon die Verankerung in
der Hierarchie des Projektes erwähnt.
Auch wichtig ist eine flache Hierarchie
Wir haben einen Lenkungsausschuss, wo die Universitätsleitung mit zwei Rektoren
vertreten ist, also Verwaltungsdirektor und der Fitterektor lehre.
Der Leiter der Informatikdienst ist dabei und die beiden Projektleiter.
Im Projektteam zusätzlich sind dann ein technischer Projektleiter, der Leiterabteilung, Verwaltungssysteme lehren.
Das ist die Abteilung, die das System im Betrieb übernehmen wird.
Die Informatikdienste noch einmal und während der Konzeptionsphase waren eben auch noch zwei Vertreter der Fakultäten dabei.
Die Zusammenarbeit mit dem Lenkungsausschuss ist relativ eng,
also wir haben ein monatliches Treffen,
da wir im Rücken Meldungen geben und gegebenenfalls uns auch ruhig versichern können,
über unsere Entscheide und auch andere Entscheide einholen,
wozu wir die Kompetenz dann vielleicht nicht haben.
Es gibt ja noch ein Supporting, das gehört eben zur Abteilung Verwaltungssysteme, Lehre.
Zuerst hat das Projektteam selber sehr viel Support gemacht bei der Einführung,
der Teilen, Raumverwaltung und Veranstaltungsverzeichnis, nun sind wir abgelöst worden vom Betriebsteam.
Sind zwar insgesamt zehn Personen, aber auf Vollzeit,
äh Querent ausgerechnet werden das dann ziemlich viel weniger,
das hat Vor- und Nachteile,
ein kleines Team Gibt auch mehr Flexibilität und zum Teil ist das auch nötig,
dass einzelne Personen einfach sehr viel das ganze Konzept im Kopf haben.
Das Ganze ja zusammenspielen muss. Dazu kommen dann noch
die verschiedenen zusätzlichen Gremien und Teilnehmer von Workshops und Fachbereichen.
Das sind dann auch weitere 20 bis 100 Personen,
die sich dann jeweils gemeldet haben, Rückmeldung gegeben haben.
Und da waren die Kontakte mehr oder weniger intensiv.
Damit kommen wir schon zu den Tipps und Tricks
Die gemeinsame, fachliche Erarbeitung durch die Uni und den Lieferanten
war sicher sehr, sehr wichtig.
Das half auch Kommunikationsprobleme zu mindern. Es gab in der ersten Phase,
musste man sich finden, dass man vom Selben spricht,
dass es auch so formuliert, dass es beide Seiten gleich verstehen.
Der Lenkungsausschuss hat sich auch sehr bewährt. Ein gemeinsames Risikomanagement
, das gehört sowieso dazu. Eine enge Zusammenarbeiter,
Informatik und der Lehrer resultiert auch in eine gute Lösung,
weil es muss immer berücksichtigt werden,
dass das Modell des Systems auch mit den Anforderungen in
einen Einklang gebracht wird
Und ja, dazu sind einfach beide Seiten
auch nötig in der Diskussion. Auch wir hatten Hausaufgaben,
wir haben eben nicht nur einfach eine Zätige Krieg,
die wieder ausgepackt, eingespült haben und es ging, sondern ja,
wir haben auch unseren Teil dazu beigetragen oder zwei ertragene ihn dazu bei.
Die Benutzerinnen müssen auch wissen, dass es immer ein Mehraufwand
ist, wenn ein neues System eingeführt wird.
Es ist nicht so, dass da sofort Arbeitserleichterungen folgen,
die folgen mit der Zeit,
aber sicher nicht bei der Einführung
Das iterative Vorgehen hat sich ebenfalls bewährt und die vorhandenen Prozesse einzubeziehen,
ist eigentlich auch ein Muss. Wichtig ist vielleicht auch noch
der zweitletzte Punkt hier, das wird nie möglich sein,
so in einem Projekt das allen Recht zu machen.
Also es gibt immer Kritiker und wir haben aber auch festgestellt,
wenn man sich etwas Zeit nimmt, mit den Leuten spricht und argumentiert,
dass man sich dann in den meisten Fällen eigentlich schon findet.
Manchmal ist auch eine geile Angst dahinter und die Herausforderung
eben auf ein neues System umzusteigen. Wichtig ist auch,
dass man die Felder der alten Systeme nicht wiederholt,
es kommen in der Regel
genug Neue dazu
Mit bei der Zusammenarbeit, mit den Benutzerinnen war auch sehr wichtig,
dass wir haben dann mit der Zeit gemeldet, nach der Konzeptvernehmlassung,
dass es für die Benutzerin nicht ganz einfach ist,
zur Konzepte zu lesen.
Wir waren natürlich vertraut damit, es waren auch Prince Screens drin,
aber das wirkliche Look and Feel ist dann doch sehr wichtig.
Also die wirklich nützlichen Rückmeldungen, also weitere nützliche Rückmeldungen haben
wir dann auch aus der Testphase gekriegt und der Pilotphase.
Und ja, eben, es braucht eine Umgewöhnungszeit,
in der man sich auch teilnimmt für die Leute
Ich komme auf den Projektplan, das glaubt uns wahrscheinlich keiner,
aber wir haben Folgendes gemacht.
Wir haben tatsächlich einen von Juristen, vorgegebenen,
also wir haben den mit den Juristen zusammen erarbeitet,
den Projektplan, da sind Pinalen drin.
Wir haben Vertragsbegründende, Meilensteine und irgendwo ist es auf einer Unterschrift von uns drunter.
Das heißt, es gibt einen Wasserfallprojekt-Plan, somit man sich das vorstellt.
Modul 1, dann und dann eingeführt, dann kommt die Schulung,
da ist das Go-Life und bis dahin muss alles funktionieren.
Das braucht so ein Projekt. Damit stehe ich im Widerspruch
zu deiner Diskussion von heute Morgen.
Das funktioniert aber nur, wenn da auch die Uni mitspielt
Die Schweizer tun das. Da sitzen nämlich die Entscheider mit
in unseren, in unserem Lenkungsausschuss. Die können auch sagen,
wir verschieben das Projekt um ein halbes Jahr oder eben nicht.
Das heißt, sie haben einen Widerspruch, sie haben einmal einen Wasserfallplan,
so wie er auch überall in den Projektleiter Zertifizierung vorgegeben wird.
Und innen drin arbeiten wir aber agil, weil wir ja Software entwickeln. Das heißt,
wir haben ein Team und wenn Change-Requests kommen oder in einer Moduländerungen drin vorkommen,
dann können wir darauf reagieren und innerhalb des Moduls,
weil wir einen bestimmten Puffer an Entwicklungszeit haben, die Sachen einzubauen.
Das Problem ist immer, dass die meisten Kunden davor zurückschrecken,
dass man mit Kanban oder mit Scrum oder mit Scrum-Bun oder mit Agile
arbeitet, in der Softwareentwicklung.
Ich denke, das wird noch eine Zeit dauern.
Und machen Sie bitte nicht den Flughafen Berlin-Fehler, wenn Sie sowas einführen.
Die haben das Terminal mit dem A38. Einmal kurz verschoben.
Und was ist dabei rausgekommen? Na gut, der Flieger landet jetzt woanders. Das,
was da hinten rauskommt an Änderungen durch diesen kleinen Change,
den Flieger irgendwo anders zu hängen, war,
dass die ganzen Händler woanders hinwollten.
Mercedes-Benz hat gesagt, nö, wir wollen da,
wo die 800 Leute aussteigen und so weiter.
Damit musste der ganze Flughafen ändern
Umgebaut werden. Ich kann nur sagen,
machen Sie einen Plan am Anfang, gucken Sie,
wie das System ungefähr laufen soll, arbeiten Sie dann in Modulen,
gucken Sie in den Modulen rein,
was können wir dann noch weich ändern,
aber leben Sie mit dem neuen System und planen Sie große Änderungen auf eine zweite Release danach.
Es geht nicht anders. Irrationale Zeitvorgaben, wir haben am Anfang gesagt,
wir brauchen vier Jahre und das hat am Anfang zu Zähneknirschen geführt,
wir sind heute im Plan, es gibt Stress, selbstverständlich,
aber wir haben es jetzt jedes Modul genau dann eingeführt,
wenn es auch eingeführt werden sollte.
Einfaches Beispiel, wir planen, wir testen jetzt schon den
Import der 800.000 Noten für den 28.08.2013, damit wir wissen,
dass wir an diesem Wochenende dann auch tatsächlich nur die vier,
fünf Stunden Zeit brauchen.
Gucken Sie das nicht irgendwer, das Projekt alleine stemmt,
sondern Entscheider in der Uni mitmachen. Achten Sie Projektmanagement. Ich denke mal,
das hat jeder von uns schon mal gehört, diese Haltung,
wir sind ja in der Uni, deswegen ist das so,
wir brauchen kein Projektmanagement, wir arbeiten per Handschlag,
das funktioniert einfach nicht.
Und unterschätzen Sie weder Migration noch Schnittstellen? Also es gibt,
ich kaum aus dem Kreditkartenumfeld und aus dem Mobilfunk Ich habe noch nie erlebt,
dass dasselbe System, selbst vom selben Hersteller,
bei einem anderen Hersteller, genau dieselbe Schnittstelle hatte.
Und wenn es nur das ist, dass Personaldaten oder Namen
anders eingepflegt werden und man die nachkorrigieren muss.
Das heißt, rächen Sie da mit großen Faktoren
und dann sind Sie bei den Migration und Schnittstellen
auch richtig