Der Software Update Irrtum

Warum es nicht so clever ist mit Software Updates zu warten

Dieser Beitrag eröffnet interne Einblicke eines Partners von Softwareherstellern für Digitalisierungsprojekte. Er lässt sich in seinen Grundzügen übertragen auf jede andere Applikation oder Software die Sie täglich im Betrieb benutzen. Das Kreuz mit den Software Updates.

Fast jeder kennt das. Sie arbeiten mit einer Version, die veraltet ist. Auf dem Markt gibt es längst eine neuere Version mit Verbesserungen und Erweiterungen aber auf Ihrem Computer oder in Ihrem Betrieb ist noch eine ältere Version installiert.

Das kann verschiedene Gründe haben. Oft ist mangelnde Planung oder falsche Priorisierung die Ursache, manchmal auch schlicht fehlende Zeit oder Resourcen. Wobei letzteres wiederum auch auf die falsche Priosierung zurückzuführen ist.

Oft glaubt man aber auch, es wäre eine kluge Idee, mit dem Update noch zu warten. Besonders wenn das Release gerade erst herausgekommen ist, denkt man: Lass doch die anderen die Fehler finden und wir sind dann fein raus. Wir updaten erst, wenn das System stabil ist und die anderen machen die Arbeit der Qalitätssicherung.

Das naheliegende zuerst: In Unternehmen werden tagtäglich Entscheidungen gefällt und jeder ist bemüht, mit seiner Arbeit möglichst gut den Anforderungen nachzukommen. Spätestens am Jahresende oder beim Zielgespräch wird Bilanz gezogen und die Ergebnisse hinterfragt. Das gilt auch für Versäumtes. Aber niemand mag gerne zugeben, dass etwas übersehen oder gar fahrlässig unterlassen wurde. Dann wird ein Versäumnis auch gern mal als bewusste Entscheidung dargestellt.

Die neue Version der Anwendung für die man zuständig ist, wird dann gerne als instabil oder nicht ausgereift dargestellt. Mit dem Betriebssystem des Herstellers Microsoft hat sich das zur Mode entwickelt. Es gibt zahllose Witze, Memes, Foren und Usergroups, die sich nur damit befassen, wie schlecht Windows schon wieder ist. Zuweilen versucht man sich sogar zu profilieren indem man die Schwachpunkte mit den ebenfalls bestens informierten Kollegen genüsslich auskostet.

Damit lässt sich wunderbar beschönigen, dass die unvermeidbare Arbeit zum Update auf die neue Version noch nicht getan wurde. Das ist menschlich. Aber clever ist es nur bei sehr kurzfristiger Betrachtung. Die Hürden die mit dem Update zu nehmen sind, schiebt man vor sich her. Und der vermeintliche Vorteil, später eine bessere Version zu installieren, ist in Wirklichkeit gar keiner. Warum das so ist, sehen wir wenn wir uns die Prozesse der Software-Herstellung genauer anschauen.

In anderen Betrieben wo eigentlich gut geplant und organisiert wird, werden die alten Versionen auch ganz bewusst in Kauf genommen. Hier herrscht tatsächlich die Vorstellung mit den in monate- oder jahrelanger Arbeit erstellten Applikationen so am besten zu fahren. Oft wird sich sogar der Softwareupdate-Vertrag gespart weil man denkt, dadurch Kosten einzusparen. Die Applikationen laufen stabil im Betrieb und es gibt keinen Grund, daran etwas zu ändern. Es läuft doch alles. Wozu nun Neuerungen in der zugrundeliegenden Software reinbringen? Das macht alles instabil und kostet Zeit, Aufwand und Nerven.

Das ist verständlich, aber nur vermeintlich von Vorteil. Nicht nur für den Nutzer. Es ist sogar für den Hersteller nachteilig. Und das nicht nur, weil er weniger Softwareupdates verkauft. Es bremst ihn auch bei der Weiterenwicklung.

Die Sicht des Software Herstellers

Nicht nur bei einer Entwicklungs-Suite wie Intrexx ist das so. Ein Hersteller eines Produkts, das lange auf dem Markt ist, ist seinen Kunden eng verbunden und verpflichtet. Das Feedback der Nutzer ist ein wichtiger Input für die Verbesserung und Weiterentwicklung der Software.

Gelegentlich hört der Hersteller dann Klagen, dass neue Technologien oder Features, die bei anderen Apps selbtverständlich sind, nicht oder erst sehr spät eingebaut wurden. Ein paar Beispiele.

Responsive Benutzeroberfläche: Endlich! ist der Tenor, als die App dies endlich auch konnte. Viele Sprüche gingen in diese Richtung und es wurde verglichen mit Web-Umgebungen, die das seit Langem können. Dann wird verglichen mit den grossen Social Media Platzhirschen Facebook, Twitter und Co.

Videos hochladen: Wie umständlich ist dass denn! Bei YouTube geht dies oder das doch auch! Und viel einfacher.

Chats: Wir möchten “doch einfach” so chatten wie bei WhatsApp. Warum sieht das so schrecklich aus? Wieso geht dies nicht einfacher und out-of-the-box?

Video-Konferenzen: Das ist doch eine Collaboration Software! Warum können wir nicht einfach eine Telko einrichten und die Gespräche als Protokolle in einem Stream speichern, so wie bei Teams oder Circuit? Warum könnt ihr das nicht? Das ist doch heutzutage Standard!

Das ist ein wenig plakativ, aber es zeigt im Kern, wie Software für Unternehmen heute funktioniert. Aus den grossen Apps des Internets werden Erwartungen formuliert, die den Hersteller vor sich hertreiben. Umgekehrt im Unternehmen passiert genau das Gegenteil: Hier wird mit der alten Version so lange gearbeitet, bis es nicht mehr anders geht. Und das bei enger Betrachtung auch noch als Vorteil angesehen.

Um zu verstehen, wie dieser Widerspruch entsteht ist ein Einblick in die Arbeitsweise eines Softwareherstellers hilfreich.

Solide Softwareentwicklung ist agil

Wer gegenüber der mächtigen Konkurrenz der datensammel-, abo- oder werbefinanzierten Internetgiganten bestehen will, muss agil entwickeln. Der heute als Modewort genutzte Begriff agil stammt genau daher: Aus der Entwicklung von Software für betriebliche Anwendungen. Es bedeutet in unserem Kontext etwas vereinfacht formuliert, dass diejenigen Änderungen als nächstes in die Software eingebaut werden, die die höchste Priorität haben.

Das heisst, Änderungen werden möglichst kleinformatig definiert (“Features, Stories”), in einer Liste gesammelt und priorisiert (“Backlog”) und dann häppchenweise je nach Machbarkeit eingebaut. Das ganze Produkt wird täglich oder kontinuierlich compiliert, zusammengebaut und weitgehend automatisch getestet. Das kennt man von der Build-Nummer, die oft als letzte Stelle in der langen Versionsnummer mit den vielen Punkten angezeigt wird.

Mit dem nächsten Release oder Update werden diese Features dann ausgeliefert. Je nachdem wie sichtbar die Änderungen nach aussen sind, wird die Versions-Nummer weiter vorne oder hinten hochgezählt.

Was hat die agile Entwicklung mit den Versionen bei Ihnen als Nutzer zu tun

Der Zusammenhang ist eben dieser Backlog. Hier laufen alle Änderungsideen für die nächsten Software Updates rein. Diese kommen allenfalls aus dem Marketing des Herstellers oder den technischen Ideen und Notwendigkeiten der Entwicklung. Im Idealfall kommen sie aber von den Nutzern selbst. Verbesserungswünsche sind dann am besten, wenn sie den Nutzern direkt weiterhelfen.

Wie aber kommen diese Wünsche vom Kunden zum Hersteller?

Das ist keine triviale Frage und nicht auf die Informatik beschränkt. Erfolgreiche Unternehmen haben diese Frage für sich gut beantwortet und organisiert.

Bei einer Software wie Intrexx ist einer dieser Kanäle der Kundendienst, sprich der Software-Support. Hier schlagen Probleme auf, die beim Nutzer aufgedeckt werden und die sofort Nutzen bringen, wenn sie gelöst werden. Hier ist eine Quelle für Verbesserungs- und Erweiterungsideen für die nächsten Versionen.

Solange der Käufer seiner Software keine Neuerungen oder Verbesserungen will, bleibt es erst mal, wie es ist. Die Welt um uns rum bleibt aber nicht stehen. Andere Apps sind vielleicht schon weiter. Es ist für den Nutzer aber nicht clever, das einfach abzuwarten. Er hilft dem Hersteller seiner Software damit nicht.

Das gilt sogar für den Fall, wenn ein Betrieb die einfache Anforderung hat, dass die Software “nur” fehlerfrei sein soll.

Denn selbst das können die anderen die früher updaten gar nicht unbedingt herausfinden. Die technische Funktionsfähigkeit des Software Updates wird natürlich beim Hersteller getestet. Und das zumeist automatisch. Eine erste Qualitätssicherung ist also gewährleistet, sobald die neue Version auf den Markt kommt.

Warum findet man als Nutzer immer wieder Fehler?

Benutzer finden Fehler beim Anwenden und ärgern sich über die vermeintlich geringe Qualität. In diesem Moment passiert es sogar, dass man sich ärgert, die Version zu früh eingeführt zu haben. Hätte man doch noch etwas zugewartet!

Und hier ist der Irrtum: Genau dieses Problem, in genau dieser Konfiguration, in genau dieser IT-Umgebung mit genau diesen Benutzern und Rollen in genau diesem Prozess in genau diesem Betrieb. Genau dieses Problem kann nirgendwo anders gefunden werden, weil es nirgendwo anders existiert.

Das ist der Knackpunkt. Die Anzahl sämtlicher Fälle aller möglichen Konstellationen ist so gross, dass sie nicht alle aufgelistet und schon gar nicht ökonomisch sinnvoll getestet werden kann. Das ist ein Fakt, den Ihnen vielleicht noch keiner gesagt hat, weil es unattraktiv ist und leicht missverstanden werden kann. Selbst in der Luft- und Raumfahrt passieren Fehler, die Menschenleben kosten. Und hier werden Milliardenbeträge in das Testen investiert. Bei einer Business Software, wo es eher um eine Erhöhung von Rentabilität oder Mehrwert geht, ist dies um so weniger angezeigt, eben weil es sich schlicht nicht lohnt. Die Software würde zu teuer.

Wenn wir diesen Fakt akzeptiert haben stellt sich die Frage, wie mache ich das beste daraus für mich und meine IT?

Und jetzt liegt die Antwort klar vor uns: Je früher ich die neue Software nutze und je besser ich eine eigene Methode habe, um meine eigenen
Anwendungsfälle meines eigenen Betriebes auszuprobieren, desto besser werden meine Applikationen.

Je früher ein Unternehmen ein Problem an den Hersteller weitergibt, desto grösser ist die Chance, dass für dieses Problem eine frühzeitige Lösung geliefert wird. Arbeite ich mit einer alten Version, dann ist die Chance gering, dass das Problem überhaupt noch gelöst wird. Habe ich gar eine Version im Einsatz, die aus der Wartung gefallen ist, dann kann ich sicher sein, dass mein Problem nicht mehr gelöst wird. Wenn das dann ein gravierendes Problem ist, sehe ich endlich, wie gross der Berg ist, den ich vor mir herschiebe.

Wenn ich einen Workaround gebaut habe, muss ich damit rechnen, dass dieser in der neuen Version gar nicht mehr funktioniert. Ich habe mir also selbst ein Arbeitspaket gebaut, das ich nun selbst wieder lösen muss. Im anderen Fall hätte das der Hersteller getan.

Eine Testumgebung ist heute mit virtuellen Servern schnell aufgebaut, ein aktueller Klon der Produktion dient als Testumgebung. Damit öffnen sich Chancen, auch neue Abläufe und Prozesse frühzeitig zu probieren und daraus resultierende Wünsche an den Hersteller weiterzugeben.

Eine Chance, die man sich nicht entgehen lassen sollte.