Software Modernisierung

Das ehrlichste Warnsignal ist kein technisches, sondern ein personelles: Wenn das Wissen über Ihr System auf ein, zwei Köpfe konzentriert ist – und diese Personen ihre Arbeitszeit fast vollständig damit verbringen, das System am Laufen zu halten, statt es weiterzuentwickeln – dann ist der Zeitpunkt gekommen. Fallen sie aus oder gehen sie in Pension, steht ein Teil Ihres Geschäfts still.

Weitere Anzeichen, die wir in der Praxis regelmässig sehen:

• Eine Anpassung an einer Stelle führt an einer anderen zu einem Fehler. Niemand traut sich mehr, etwas zu ändern.
• Die Anwendung ist über die Jahre zu einem Monolithen gewachsen, zusammengehalten von Workarounds, die niemand dokumentiert hat.
• Schnittstellen brechen weg, weil sich Ihre Umsysteme weiterentwickelt haben und die eingesetzte Technologie nicht mehr mithält.
• Framework, Datenbank, Betriebssystem oder Server haben ihr End-of-Life erreicht oder verlieren den Herstellersupport.

Ob daraus eine Modernisierung oder eine Neuentwicklung wird, entscheiden wir nicht vorab. Am Anfang steht immer eine ergebnisoffene Analyse Ihres Systems.

Aus der Praxis: Bei der PFIFFNER Messwandler AG lief eine zentrale Anwendung auf Visual Basic. Das Wissen darüber war auf wenige Personen konzentriert, die kaum noch zum Tagesgeschäft kamen, und Schnittstellen funktionierten nach Änderungen an den Umsystemen nicht mehr. Heute läuft das Backend auf C#/.NET, das Frontend auf Angular.

In der Praxis ist das selten ein Entweder-oder. Meist bleibt die Fachlogik erhalten – sie ist das, was Ihr Unternehmen über Jahre aufgebaut hat – während die Technologie darunter ersetzt wird.

Die Entscheidung hängt dabei weniger an der Qualität Ihres Codes als an der Zukunft der eingesetzten Technologie. Eine über Jahre unübersichtlich gewachsene C#-Anwendung modernisieren wir innerhalb von .NET – die Plattform hat Zukunft, und Sie finden dafür auch in zehn Jahren noch Entwickler. Eine Anwendung in einer Technologie, die vom Markt verschwindet und für die kaum noch jemand ausgebildet wird, entwickeln wir dagegen neu. Nicht weil der Code schlecht wäre, sondern weil Sie sonst in wenigen Jahren wieder am selben Punkt stehen.

Zwei Fragen prüfen wir deshalb zuerst:

1. Wird die eingesetzte Technologie am Markt weiterhin unterstützt, und finden Sie dafür künftig noch Entwickler?
2. Und wie viel Fachwissen steckt in der bestehenden Anwendung, das nirgendwo sonst dokumentiert ist?

Bei der PFIFFNER Messwandler AG fiel die Antwort auf Neuentwicklung, weil Visual Basic keine Zukunft hat. Die bestehenden Abläufe haben wir dabei bewusst zuerst eins zu eins abgebildet und erst in einem zweiten Schritt verbessert. So war früh belegt, dass der neue Weg trägt.

Schrittweise – und zwar fast immer. Einen Big Bang, bei dem an einem Stichtag das alte System ab- und das neue eingeschaltet wird, vermeiden wir, wo immer es geht. Das Risiko trägt in diesem Moment allein Ihr Betrieb.

Stattdessen bauen wir einen Parallelbetrieb auf. Ein klar abgegrenzter Teil Ihres Geschäfts läuft über die neue Software, während alles andere unverändert im Altsystem bleibt. Bei der PFIFFNER Messwandler AG haben wir das Auftragssystem neu entwickelt und zunächst die Auftragsabwicklung eines einzelnen Spannungswandler-Typs umgestellt. Aufträge dieses Typs liefen ab diesem Zeitpunkt über die neue Software, alle übrigen unverändert weiter. Erst wenn ein solcher Schritt im Alltag stabil läuft, kommt der nächste dazu.

Am Anfang steht dabei ein Durchstich, meist in Form eines MVP – eine schmale, aber vollständige Funktion durch alle Ebenen des neuen Systems – von der Oberfläche über die Datenbank bis zu den Schnittstellen. Je nach Grösse sind das wenige Monate. Danach ist an echten Daten belegt, dass der eingeschlagene Weg trägt, bevor grosse Budgets gebunden sind.

Ihr Betrieb läuft weiter. Wir schalten eine bestehende Funktion nicht ab, wenn die neue in Betrieb geht – beide stehen eine Zeit lang nebeneinander. Damit gibt es keinen Stichtag, an dem etwas stillstehen könnte, und keinen Punkt, an dem es kein Zurück mehr gäbe.

Daraus ergibt sich eine Kontrolle, die nicht von unserem Wort abhängt. Sie können denselben Auftrag im alten und im neuen System erfassen und die Ergebnisse vergleichen. Solange Sie nicht überzeugt sind, arbeiten Sie einfach weiter wie bisher.

Bei den Daten wählen wir den Weg mit dem geringsten Risiko. Häufig arbeiten beide Systeme auf derselben Datenbasis – dann gibt es weder doppelte Datenhaltung noch Abweichungen zwischen alt und neu. Wo das nicht möglich ist, planen wir eine Datenmigration und einen echten Parallelbetrieb ein. Welcher Weg für Sie der richtige ist, zeigt die Analyse zu Beginn.

Ja. Das ist nicht der Ausnahmefall, sondern der Normalfall. Gewachsene Software ist praktisch nie vollständig dokumentiert.

Wir rekonstruieren das fehlende Wissen aus zwei Quellen: aus dem System selbst und aus den Menschen, die täglich damit arbeiten. In Gesprächen und strukturierter Anforderungsanalyse tragen wir zusammen, was Ihre Anwendung heute tatsächlich leistet und was die neue leisten muss. Viele unserer Kunden sagen uns, dass sie diese Übersicht damit zum ersten Mal überhaupt haben.

Dabei stossen wir regelmässig auf Sonderfälle, die vor Jahren als Workaround entstanden sind und die heute niemand mehr erklären kann. Diese übernehmen wir nicht ungeprüft. Wir verstehen uns als Softwareingenieure und denken in Ihrer Domäne mit. Wir fragen nicht nur, wie etwas funktioniert, sondern ob es so noch richtig ist. Denn neue Software allein macht einen unsauberen Prozess nicht besser – sie führt ihn nur schneller aus.

Wir wählen bewusst nicht die neueste Technologie, sondern die bewährte. Unsere Kunden sind überwiegend Industriebetriebe, deren Software auch in zehn Jahren noch laufen und wartbar sein muss. Deshalb setzen wir auf Plattformen mit langer Perspektive und einem grossen Entwicklermarkt, etwa C#/.NET oder Java. Ebenso wichtig ist, was Ihr eigenes Team bereits beherrscht – und auf Wunsch binden wir Ihre Mitarbeitenden von Beginn an ins Projekt ein.

An uns gebunden sind Sie nicht. Wir setzen keine proprietären Frameworks und keine selbst geschriebenen Bibliotheken ein, die eine Abhängigkeit zu uns oder Fragen zu Schutzrechten erzeugen würden. Am liebsten entwickeln wir direkt in Ihrer Umgebung: Dann haben Sie vom ersten Tag an Zugriff auf Quellcode und Deployment – nicht erst bei der Übergabe.

Die Frage, wem das Ergebnis gehört, stellt sich für uns ohnehin nicht. Sie erteilen den Auftrag, also gehört Ihnen das Resultat – Quellcode, Dokumentation und Umgebung inklusive.

Eine seriöse Antwort gibt es nur für Ihr konkretes System. Pauschale Zeitangaben nennen wir bewusst nicht. Sie wären für Sie wertlos und für uns unhaltbar. Was wir sagen können, ist, wann Sie den ersten Nutzen sehen – und das ist nicht am Ende des Projekts. Wir setzen früh einen ersten, klar abgegrenzten Prozess produktiv; je nach Grösse dauert dieser Schritt wenige Monate. Ab diesem Zeitpunkt arbeitet ein Teil Ihres Betriebs bereits mit der neuen Software, während der Rest unverändert weiterläuft.

Den grössten Einfluss auf die Gesamtdauer hat erfahrungsgemäss weder die Technologie noch die Systemgrösse, sondern etwas anderes. Sobald das neue System sichtbar wird, entstehen neue Wünsche. Das ist ein gutes Zeichen – es bedeutet, dass die Lösung angenommen wird. Es braucht aber jemanden, der entscheidet, was jetzt dazugehört und was in eine spätere Etappe. Diese Rolle übernimmt bei uns der Success Lead, der feste Ansprechpartner für Ihr Projekt. Er nimmt Ihre Anliegen auf und behält zugleich Umfang und Termine im Blick.

Einen belastbaren Rahmen können wir erst nach der Analyse nennen. Und selbst dann kaufen Sie kein grosses Ganzes, sondern einzelne Etappen.

Wir arbeiten agil. In kurzen Etappen legen wir gemeinsam mit Ihnen fest, was als Nächstes umgesetzt wird. Der Aufwand je Etappe steht vorher fest, und die Reihenfolge bestimmen Sie. Damit entscheiden Sie laufend selbst, wofür Ihr Budget eingesetzt wird – und weil das Wichtigste zuerst entsteht, haben Sie nach jeder Etappe ein Ergebnis, das bereits im Betrieb nutzbar ist. Den Überblick über den Gesamtfortschritt behält unser Success Lead. Er meldet sich, bevor eine Abweichung entsteht, nicht danach.
Sie sind dabei nicht auf Jahre gebunden, und alles bereits Entwickelte gehört Ihnen – lauffähig und in Ihrer Umgebung.

Ein Kostenfaktor wird oft übersehen, und wir sprechen ihn lieber früh an. Ihre eigene Zeit. Ein agiles Projekt braucht auf Ihrer Seite eine verantwortliche Person, die fachlich entscheidet und intern als Schnittstelle wirkt. Ohne sie wird ein Projekt nicht günstiger, sondern teurer. Sie ist der wichtigste Beitrag, den Sie selbst leisten.

Am Anfang steht immer eine Analyse Ihrer Software und ihrer Umsysteme. Je nach Grösse und Zustand dauert sie zwei bis vier Wochen. Sie erhalten eine dokumentierte Empfehlung mit Systemübersicht, Zielarchitektur und einer Aufwandschätzung für die nächsten Schritte. Von Ihrer Seite brauchen wir im Wesentlichen zwei bis drei Workshops sowie Zugang zu System und Quellcode.

Die Analyse ist ein eigenständiges, kostenpflichtiges Mandat – und sie verpflichtet Sie zu nichts. Das Ergebnis gehört Ihnen, und Sie können die Umsetzung ebenso gut mit einem anderen Dienstleister angehen. Natürlich hoffen wir, dass Sie sich für uns entscheiden. Aber eine Analyse, die nur mit uns weiterverwendbar wäre, wäre keine neutrale Analyse.