Ich wollte mir vor ein paar Tagen eine neue Lampe für das Rad kaufen. Es ging mir darum, nicht nur gesehen zu werden sondern auch eine gute Sicht zu haben, wenn ich im Dunkeln mit dem Rad unterwegs bin. Die Auswahl im Geschäft war überschaubar, also entschied ich mich sehr schnell für eine LED-Lampe mit aufladbarer Batterie. Praktischerweise war auch das Lade-Gerät inkludiert und ich fuhr zufrieden nach Hause. Ich montierte die Lampe auf mein Fahrrad und verstaute das Lade-Gerät an dem erstbesten Ort. Die Lampe war voll aufgeladen, daher machte ich mir keine weiteren Gedanken. Auch bei der ersten Betriebnahme ging alles nach Plan, die Helligkeit entsprach meinen Vorstellungen und die Lampe war felsenfest montiert. Erst als erstmals die Batterie schwach wurde, begannen die Probleme. Der Anschluss für das Lade-Gerät, war nicht – wie von mir fix angenommen – der weit verbreitete mini-USB-Standard, sondern etwas kleiner. Und – natürlich konnte ich das spezifische Lade-Gerät für die neu gekaufte Rad-Lampe nicht mehr finden. Ich hatte also Dutzende Lade-Geräte, mit der ich mein Smart-Phone, Tablet, Baby-Phone, E-Reader und was der Geier aufladen konnte – nur nicht meine neue tolle LED-Lampe. Denn für diese hatten die Hersteller – aus welchen Gründen auch immer entschieden, einen spezifischen Anschluss fürs Laden hinzuzufügen. Mir war nicht klar, ob ich mich nun primär über meine Nachlässigkeit oder über den Hersteller ärgern sollte.
Warum erzähle ich diese Episode?
Bei Gesprächen mit Kunden in der IT-Abteilung fiel mir immer wieder diese Geschichte ein, weil es meiner Meinung nach eine treffende Analogie für ein verbreitetes, komplexes Problem in der IT ist:
Wenn Unternehmen Software von Drittanbietern (“Commercial off the shelf”) angeschaffen, dann zählen bei der Auswahl oftmals primär funktionale Kriterien. Das ist nachvollziehbar, denn man möchte als Anwender mit der Software ein Problem lösen. Z.B. als Finanzabteilung eine Software für die Buchhaltung und Jahresabschluss. als Vertriebsabteilung ein Customer-Relationship-Management-System, als Industriebetrieb eine Software für die Produktionssteuerung.
Wenn (überhaupt) der Betrieb eingebunden wird, dann stehen auch von Betriebsseite oft Fragen rund um die “einfache Installation”, “Ressourcen-Verbrauch” und natürlich der Anschaffungs-Preis im Vordergrund. Anforderungen, die sich aus dem späteren “Betriebs-Alltag” (heutzutage oftmals auch “Day 2 Operation” genannt), fallen dabei unter den Tisch. Das schafft allerdings mittel- und langsfristig enorme Probleme, genauso wie bei meinem ungeschickten Lampenkauf:
Natürlich interessiert mich als Radfahrer in dem Kaufmoment primär die Wirkungsweise der Lampe, d.h. die Helligkeit, die Einfachheit der Montage, die Stabilität und der Preis. Im Geschäft wäre ich also gar nicht auf die Idee zu kommen, zu fragen, ob für das Aufladen Standard-Ladekabel unterstützt werden. Und selbst wenn – das Ladekabel war ja im Packungs-Umfang enthalten. Die tatsächlichen Aufwände und Schwierigkeiten kristallisierten sich erst Monate nach dem Kauf heraus.
Ist das ein unvermeidliches Problem, quasi aus der Natur der Sache gottgegeben?
Ich war beeindruckt, als ich in einem Gespräch mit einem Kunden in Österreich eine sehr klare Ansage hörte. Der – vermutlich durch lange Jahre schmerzvoller Erfahrung – geprägte Service-Verantwortliche artikulierte sehr klar: “Wenn ein bestehender oder neuer Software-Lieferant nicht mit unserem Betriebsmodell kompatibel ist, dann beenden wir die Zusammenarbeit!” Das klingt nach Überreaktion. Bei genauer Betrachtung ist es aber eine konsequente, ganzheitliche Sicht auf den Software-Betrieb. Und oftmals eine absolute Notwendigkeit, wenn man mit einer schlanken IT-Mannschaft der stetig steigenden Komplexität Herr werden möchte.
Also nett gesagt: „Lieber Software-Lieferant! Wir wollen mit Dir eine längere Zusammenarbeit und nicht nur einmal die Software über den Zaun geworfen. Deswegen bitten wir Dich auf Industrie-Standards zu setzen. Wir tun das auch! Bitte erspare uns Diskussionen, ob sich wirklich die besten Technologien als Industrie-Standards durchgesetzt haben. Das interessiert uns wenig. Wir wollen einfach nur unser Leben vereinfachen!“
Und weniger nett gesagt: „Entweder so oder Tschüss mit ‚ü‘!“
Viele Software-Lieferanten verstehen das, werden mehr und mehr in diese Richtung sensibilisiert. Die Prozesse rund um die Übergabe (“Delivery”) und Betrieb von Software müssen für beide Seiten effizient sein. Dies wird primär durch Standardisierung erreicht, durch wohl erprobte und allgemein verbreitete Konzepte. Derzeit sind das z.B. Container für die Paketierung, Kubernetes als Betriebsplattform, Helm bzw. Operator für die Installation und Upgrade. Das kann morgen schon was anderes sein. Aber Stand heute ist das industrieweit mehr und mehr der Standard.
Wenn Software-Lieferanten primär ihre eigene Perspektive sehen, dann werden sie möglicherweise hin und wieder kurzsichtige Kunden (so wie mich im Radgeschäft) blenden können. Die Kunden werden aber mittelfristig zu anderen Anbietern wechseln, die eine Antwort für Day 1 (“Installation”) UND Day 2 (“Betriebs-Alltag) haben.
Ich habe mein Ladegerät mittlerweile wieder gefunden und verwende die LED-Lampe immer noch. Derzeit habe ich auch keine Motivation zu wechseln, ich habe es geschafft diese Lampe in meinen “Betriebs-Alltag” zu integrieren. Allerdings mit Zusatzaufwänden, ich muss nämlich das spezielle Ladegerät immer in der Fahrrad-Schublade belassen und muss bei jedem längeren Rad-Ausflug extra daran denken. Das nehme ich dem Hersteller übel und beim nächsten Kauf wird die erste Frage sein: “Kann ich diese Lampe mit jedem üblichen Lade-Kabel laden?”
Digi-Versationen 