Sanierung, Kauf oder Neubau - was tun, wenn Software in die Jahre kommt?
| dc.contributor.author | Rehm, Simone | |
| dc.contributor.editor | Brandt-Pook, Hans | |
| dc.contributor.editor | Fleer, André | |
| dc.contributor.editor | Spitta, Thorsten | |
| dc.contributor.editor | Wattenberg, Malte | |
| dc.date.accessioned | 2018-11-06T11:35:12Z | |
| dc.date.available | 2018-11-06T11:35:12Z | |
| dc.date.issued | 2012 | |
| dc.description.abstract | Menschen, die nicht aus der Software-Branche kommen, mag das überraschen, aber Software altert. Softwareexperten wissen das zwar, stehen aber dennoch vor einer schwierigen Aufgabe, wenn sich abzeichnet, dass eine Sanierung oder Modernisierung ansteht. Meist sind es gar nicht die Anwender, die diesen Handlungsbedarf erkennen. Vor allem bei Eigenentwicklungen, die über Jahre und Jahrzehnte immer wieder an die Bedürfnisse der Anwender angepasst worden sind, zeigen sich die „Alterserscheinungen“ eher in begrenzter Erweiterbarkeit oder mangelnder Wartbarkeit der Software als in der Funktionalität. Das heißt, der Impuls für die Erneuerung kommt meist aus der IT. Trotzdem muss man die Anwender für ein solches Projekt gewinnen, denn häufig ist mit dem Renovieren ein Einfrieren des bestehenden Systems verbunden. Das heißt, die Anwender müssen ihre Anforderungen nach Weiterentwicklung vorerst zurück stellen. Hinzu kommt die Furcht, dass sie sich von Alt-Vertrautem verabschieden müssen und der erworbene Komfort bei einer Neugestaltung möglicherweise verloren geht. Beides erfordert ein hohes Maß an Überzeugungsarbeit im Vorfeld eines solchen Projekts. Hat man erst einmal die Zustimmung aus der Anwenderschaft, so stellt sich die Frage: Sanierung, Neubau oder gar Neukauf? Am realen Beispiel eines eigenentwickelten Systems zur Planung und Durchführung von Servicetechnikereinsätzen zeigt der Vortrag auf, in welchen Stufen bei TRUMPF eine Bestandssoftware systematisch analysiert wurde und welche Aspekte im vorliegenden Fall gegen ein Software-Refactoring und für eine komplette Neuentwicklung auf Basis einer Smart-Client-Zielarchitektur sprachen. Die geschätzten Kosten für den Neubau lagen allerdings in derselben Größenordnung wie die Kosten für die Einführung eines Standardprodukts. Deshalb gilt es nun, weitere Kriterien für die Entscheidung „Make-or-Buy“ herauszuarbeiten. Dazu zählen zum einen strategische Aspekte, wie etwa die Abhängigkeit vom Hersteller. Da von diesem Hersteller auch die ERP-Software stammt, die TRUMPF einsetzt, würde sich das neue Softwareprodukt leicht mit den ERP-Prozessen integrieren lassen. Auf der anderen Seite steigt dadurch die Abhängigkeit vom Hersteller. Wer hat die Weiterentwicklung in der Hand? Wie flexibel kann der Anbieter auf neue Anforderungen eingehen? Welche Flexibilität wird aus fachlicher Sicht überhaupt gebraucht? Wie schnell kann der Anbieter auf technologischen Wandel eingehen? Diese und weitere qualitative Kriterien fließen nun in eine Nutzwertanalyse ein. Gemeinsam mit dem Fachbereich werden sie zusammengetragen, gewichtet und bewertet. Parallel dazu wird der Funktionsumfang des Bestandssystems durchleuchtet. Ziel dabei ist es, ebenfalls gemeinsam mit dem Fachbereich zu ermitteln, welche Use Cases das System ausmachen, in welchen dieser Use Cases bereits heute ein hoher Grad an Individualität steckt und wo diese Individualität für den Geschäftserfolg entscheidend ist und daher beibehalten werden soll. In einem weiteren Schritt wird dann für alle Use Cases mit hohem Individualisierungsgrad Fall für Fall bewertet, a) ob und wie sich in der Zielarchitektur für das eigenentwickelte Neusystem diese Individualität abbilden ließe, b) ob sie sich auch beim Einsatz eines Standardprodukts im Rahmen eines Customizings abbilden ließe und c) wie hoch der Aufwand dafür wäre und ob er die Grenzen eines vertretbaren Customizings sprengen würde. Auf Basis dieser Bewertungen wird dann in einem finalen Schritt entschieden, welchen Weg das Unternehmen TRUMPF bei der Ablösung des Bestandssystems gehen wird. Im Vortrag werden die sich ergänzenden Bewertungsschemata detailliert vorgestellt. Auf die Ergebnisse der Bewertung wird ebenso wie auf die vorstellbaren Migrationsszenarien beim Übergang auf ein neues System näher eingegangen. | de |
| dc.identifier.isbn | 978-3-88579-603-9 | |
| dc.identifier.pissn | 1617-5468 | |
| dc.identifier.uri | https://dl.gi.de/handle/20.500.12116/17929 | |
| dc.language.iso | de | |
| dc.publisher | Gesellschaft für Informatik e.V. | |
| dc.relation.ispartof | Nachhaltiges Software Management | |
| dc.relation.ispartofseries | Lecture Notes in Informatics (LNI) - Proceedings, Volume P-209 | |
| dc.title | Sanierung, Kauf oder Neubau - was tun, wenn Software in die Jahre kommt? | de |
| dc.type | Text/Conference Paper | |
| gi.citation.endPage | 16 | |
| gi.citation.publisherPlace | Bonn | |
| gi.citation.startPage | 15 | |
| gi.conference.date | 14.-16. November 2012 | |
| gi.conference.location | Bielefeld | |
| gi.conference.sessiontitle | Regular Research Papers |
Dateien
Originalbündel
1 - 1 von 1