Ja. Dankeschön. Ja, das sind natürlich jetzt sozusagen
große Fußstapfen, in die ich mit dem Talk treten muss.
Das wird jetzt in die nächsten 20 Minuten werden vielleicht
ein bisschen profaner werden. Also das,
was Sie gerade gehört haben, das entspricht auch dem,
dass ich hier der einzige Sprecher in der Session bin, ohne Professorentitel.
Forschungsinformationen, Standardisierung und Professionalisierung. Das ist der Titel,
aber zunächst will ich Sie in bester Corporate-Manier mit ein paar Buzzwords,
die in den Kopf schmeißen.
Wie Webinterface, 22-7 Support, Software-as-a-Service,
Scalability, easy to use.
Woran denken Sie da
Enterprise IT, SAP, IBM. Sicherlich auch,
aber auch das hier, sogenannte Exploit-Kids,
deren Ziel es ist, fremde Rechnermaßenhaft zu infizieren.
Das ist der Marktführer, der heißt Sweet Orange und sehen,
dass zum Beispiel die Infektionen bei 66 Prozent aller Expi-Rechner erfolgreich waren.
Sowas kostet 1400 Dollar die Woche ungefähr,
aber dafür müssen sie nicht in ihre eigene Virenschleuder programmieren
Das heißt, das ist also der Bereich Crimeware.
Und nach Wikipedia ist Crimeware eine von Wirtschaftskriminellen weiterentwickelte Formen der Melware,
die kriminologisch zur Computerkriminalität zählt und rechtlich unter Internetbetrug anzusiedeln ist.
Es geht also hier nicht um Elsevier,
auch wenn die sich die beste Mühe gegeben haben,
unsere Corporate Colors zu üben, zu imitieren.
Das war jetzt ein Beispiel für Professionalisierung und Standardisierung im Sinne
von Standardsoftware in einem ziemlich abseitigen Bereich der IT.
Im folgenden Saison zum Hochschul-IT gehen und um Standardisierung dort.
Und die Begrifflichkeiten sind, Am einen Ende der Skala kotzt Commercial of the Shelf-Software.
Das klingt nicht wahnsinnig sexy, da denken sie wahrscheinlich an
Microsoft Word oder vielleicht auch an ihr Personalsystem oder so.
Das ist eine Extrem, das andere Extrem ist,
Individualsoftware oder angepasste Lösungen, bei denen sie sozusagen für sich alleine kämpfen.
Und in der Praxis ist es natürlich ein Spektrum,
wo Richtung Commercial of the Shelf Richtung Standard-Software wir eben angepasste Standardsoftware
haben und auf der anderen Seite haben wir Plattformen mit Bibliotheken und so weiter,
auf denen Individuallösungen aufbauen
Konkret sprechen wir jetzt über Forschungsinformationssysteme und werden auch sehen sozusagen,
wie die sich dort gewissermaßen verorten lassen auf dieser Skala.
Das heißt, Systeme,
die der Zusammenführung aller Forschungsrelevanten Daten an ihre Einrichtung,
die ein Drittmittelanträge, Bewilligungen, Projekte, Publikationen,
Organisationen,
Informationen über die Wissenschaftler
und so weiter
Die wesentlichen Use-Cases, wie es so schön heißt,
sind dort einerseits Compliance, also die Möglichkeit,
Berichte und Daten in den geforderten Formaten und im geforderten Umfang bereitzustellen für Fördergeber,
Ministerien, die Hamburger Bürgerschaft und so weiter.
Andererseits die Möglichkeit, die Analytischen Fähigkeiten des Systems zu nutzen,
um einen Überblick über die eigenen Forschungsaktivitäten zu bekommen,
zu Zwecken der Steuerung der Hochschulentwicklung
und so weiter
Hier unternehmen, unter dem Begriff Analytics zusammengefasst und dann auch die Möglichkeit,
diese Dinge nach außen darstellen zu können, Showcasing.
Und zu dem Zweck nehmen Forschungsinformationssysteme Daten aus verschiedenen Quellen entgegen,
unter anderem auch die manuelle Eingabe,
aber auch eine Integration mit Systemen wie in einem Finanzsystem,
einem Personalsystem und so weiter und so fort.
Das heißt,
das sind im Umfang Enterprise-Systeme und wir hatten schon gehört,
Produkte oder sagen wir mal die verbreitesten Produkte auf dem Markt sind,
sind eben Pure von uns,
Konveres,
derzeit Thompson Reuters und Fact Science von Kollegum
So, jetzt geht es aber wieder ein bisschen Schritt zurück
von Forschungsinformationssystemen im Speziellen, so ein bisschen im Allgemeineren.
Diese Unterscheidung zwischen nämlich einer Standardlösung einerseits und wahrscheinlich repräsentiert Pure
am ehesten diesen Ansatz und einer angepassten Lösung.
Auf der anderen Seite, der ist relativ fundamental.
Und im Prinzip soll das Ziel dieses Talk-Sendar ein paar Handreichungen
zugeben für eine Entscheidungsfindung. Und da werden wir drei,
werde ich drei Dimensionen kurz kommentieren,
das sind einerseits die Kosten, die in der Regel,
das ist die Faustregel für Standardlösungen niedriger sind,
das ist in manchen Fällen ganz klar,
mal Entwicklung von Microsoft Word, würde sie natürlich Unmengen kosten.
Das kommt gar nicht in Frage,
aber auch da gibt es ein paar Bedingungen,
unter denen das gilt.
Und darauf komme ich auch gleich noch zurück
Zum anderen sozusagen der Abdeckungsgrad dessen,
was so eine Software zu leisten imstande ist,
mit den Anforderungen, die sie als Kunde ihm haben.
Da ist es natürlich so,
dass quasi das Ideal der Angepassten oder den Individuallösung,
das ist, dass die Anforderungen komplett abgedeckt werden.
Auch das gilt abgestuft nur in einer gewissen Voraussetzung,
die ich auch noch kommentieren werde.
Und die Einführungszeit, die bei Standardlösungen auch geringer ist.
Natürlich gibt es auch da auf jedem Projekt Punkte,
die zu dem Verzug führen können und so weiter,
aber die sind individueller Natur,
sozusagen nicht struktureller Natur
Wenn wir über die Kosten sprechen,
dann ist ja im Prinzip das Versprechen einer Standardsoftware,
dass die Kosten von der gesamten User-Community getragen werden.
Dazu ist es aber notwendig, dass eine gewisse Homogenität herrscht offensichtlich.
Der Kerndatensatz, unter anderem schafft auch so eine Art von Homogenität.
Wenn also ihr Systemanbieter ihnen sozusagen ihr angepasstes eigenes,
wie auch immer, Forschungsinformationssystem verspricht, dann ist die Wahrscheinlichkeit groß,
dass ein Guter dieses Kostenvorteils wieder dahin ist und das merken sie vielleicht nicht sofort,
aber dann vielleicht irgendwann nach dem fünften Change Request oder so.
Andererseits gibt es eine Software, Standardsoftware natürlich auch die Situation,
dass sie Features mitbezahlen, die sie nicht nutzen.
Dem kann man begegnen, indem man eine modulare Struktur bietet,
wo nur benötigte Module lizenziert werden und so weiter.
Trotzdem, das ist ein Punkt,
der dich nicht ganz vermeiden lässt
Bei einer Individualösung oder einer angepassten Lösung werden die Kosten offenbar vom Kunden getragen.
Und das ist halt schon ein großer Zyklus,
den man, den man im Kopf haben muss.
Also das können interne Kosten sein bei der Analyse. Das heißt,
bei der Sammlung und bei der Formulierung von Anforderungen,
bei deren Priorisierung und so weiter, dann im Design der Frage,
wie werden die Anforderungen in Software gegossen und dann natürlich in der Entwicklung,
im Test und so weiter.
Das ist ganz klar. Potenziell der Vorteil,
dass nur bezahlt wird, was eben gebraucht wird.
Trotzdem muss man Ja, ich komme gleich nochmal drauf zurück,
hier an dem Punkt. Die Frage ist jetzt,
ob diese sozusagen Kostennachteile von angepassten oder Individuallösungen nicht davon überwogen werden,
dass eben so eine Lösung sich im Idealfall an die Bedürfnisse und Prozesse genau anpasst.
Es ist so, dass man der Standardsoftware sie damit rechnen
müssen, dass Geschäftsprozesse geändert werden müssen.
Während bei der angepassten Lösung im Idealfall die Bedarfe besser abgedeckt sind.
Aber In der Praxis hat sich zum einen gezeigt,
dass die Änderung von Geschäftsprozessen oft kein großes Problem ist oder sogar erwünscht ist,
weil in der Regel System ein Systemeinführungen durch ein Organisationsentwicklungsprojekt begleitet oder Teil dessen sind.
Andererseits hat er sich auch gezeigt, und das sehen wir auch regelmäßig,
dass Einrichtungen zum Teil erhebliche Probleme haben,
ihren Anforderungsprozess und den Anforderungskatalog unter Kontrolle zu halten.
Das ufert sehr schnell massiv aus
Und selbst wenn sie in der Lage sind,
das in dem vertretbaren Rahmen zu halten, ist es eben so,
dass Softwarehersteller auch einfach verstehen müssen, was sie damit wollen.
Das muss schon klar definiert sein,
damit es in ihrem Sinne umgesetzt wird. Das heißt,
ein bisschen, sagen wir mal, ein bisschen kontrovers,
dass zwar ein gewisses Maß an Flexibilität natürlich notwendig ist,
zu viel Flexibilität, sich aber oft als Fluch herausstellt.
Ein weiterer Punkt, der natürlich ein bisschen bei der Standardsoftware zu beachten ist,
ist dass wir als Software-Hersteller natürlich auch ständig mit wechselnden Anforderungen konfrontiert sind,
auch aus verschiedenen Ländern und so weiter.
Dadurch besteht die Gefahr, dass die Volatilität so einer Lösung höher ist,
als die von einer angepassten Lösung, weil man als Softwarehersteller
natürlich auch ein bisschen opportunistisch agiert und sozusagen den nächsten Kunden befriedigen will.
Das heißt, wenn es blöd läuft, besteht die Gefahr,
dass sozusagen ihre Anforderungen und das System irgendwann auseinanderdriften.
Da gibt es zwei wichtige Bausteine, um sowas zu verhindern.
Der eine wichtige Baustein sind starke Nutzergruppen oder eine starke Nutzergruppe,
die die Entwicklung des Produkts mit begleitet.
Und wir stellen eigentlich regelmäßig fest, dass die Unterschiede zwischen
ihnen aus der Einrichtung und Universitäten nicht so groß sind,
wie sie glauben.
Und es treibt unserem Produktmanagement regelmäßig Tränen der Freude in die Augen.
Wenn wir uns gemeinsam mit einigen Kunden zusammensetzen,
uns gemeinsam in den Raum einsperren und am Ende des Tages
unsere Kunden sich offene Liste von Priorität von Prioritäten
einigen können
Das ist also ein Baustein. Der andere Baustein ist sozusagen die externe Kraft,
die die Systementwicklung auf Kurs halten soll, ist eben Standardisierung.
In Form von Zerrif, Ephrason Hornbosslatz angesprochen,
Castry Arquid Vivo des Research Excellence Framework, der Kerndatensatz,
hier vertreten die Wissenschaftsrat und IFQ und so weiter.
Deshalb sind die wichtig für uns und noch wichtiger für sie
als als als potenzielle Kunden dann eben auch potenzielle sozusagen Bestandskunden.
Noch ein paar Faustregeln und das ist Sie schauen auf
die Uhr, aber das ist meine letzte Folie.
Mit Inhalt. Die Faustregel ist die,
dass eine Standardsoftware ungefähr 80 Prozent ihrer Anforderungen abdecken sollte.
Da kann man dann von ganz gutem Abdeckungsgrad sprechen.
Andererseits ist es auch so, dass ihre Anforderungen ungefähr
80 Prozent der Fähigkeiten der Software abdecken sollten.
Was ein bisschen schwieriger ist tatsächlich, weil die Systeme sich
ja natürlich weiterentwickeln. Der Grund für Ersteres ist natürlich,
das System soll gut passen. Der Grund für Letzteres ist,
dass überbordende Komplexität irgendwann Probleme machen wird oder zumindest das Potenzial dazu hat.
Was auch eine Faustregel ist, ist die,
dass Dinge wie Compliance, Berichterstattung und so weiter,
dafür kaufen sie tendenziellen Systemen noch fünf Minuten, danke.
Dafür kaufen sie tendenziell ein System. Das sind Sachen,
die müssen eben gemacht werden. Andererseits gibt es Dinge,
die sozusagen zu ihrer Wettbewerbsfähigkeit, um sozusagen ein bisschen in
der Sprache zu bleiben, beitragen.
Das kann zum Beispiel sein, wie sie ihre Forschungsaktivitäten
nach außen darstellen oder so weiter. Das sind Dinge,
bei denen sie eine Eigenentwicklung oder eine Auftragsentwicklung,
wie auch immer oder eine Anpassung in Erwägung
ziehen sollten
Im Pure, und das ist das einzige Mal,
wo ich mich konkret hier drauf beziehe,
es ist ein bisschen so abgebildet.
Also diese Zahl hier, das ist nicht die Anzahl der
Bugs in Pure, sondern das ist die Anzahl von Co-Zeilen.
Und davon sind 56% Prozent der Code-Basis werden von allen
unseren Kunden mithalten, all unseren Kunden genutzt.
17% sind in der Untergruppe aus verschiedenen Gründen,
gehe ich nicht darauf ein, 27% Prozent sind Anpassungen für einzelne Kunden.
Und das sind in der Regel Portale, Forschungsportale,
die eben im Corporate Layout der Universität und
so weiter und mit spezifischen Funktionalitäten
entwickelt werden
Gut, zuletzt entlasse ich sie sozusagen noch mit
ein paar Bildern von unserer Pure International Conference,
die wir jetzt Anfang des Monats in Amsterdam hatten,
wo wir Kunden aus oder Vertreter aus 70 Einrichtungen,
die die Pure nutzen, zusammen hatten.
Das ist ungefähr die Hälfte unserer Kundenbasis. Und ich hoffe natürlich,
dass ich den einen oder anderen von ihnen dort auch mal sehe.
So hat das Ganze dann geendet.
Und ja, damit komme ich zum Ende