So, und da ist das, was uns jetzt der Experte gesagt hat. Der hat uns gesagt, insbesondere Benutzerfreundlichkeit ist wichtig. Wenn diese, wenn wir mit diesem System nicht arbeiten können, insbesondere wenn Kunden damit keine Rechnungen, keine Reparaturen beauftragen, dann haben wir ein echtes Problem. Und das wird halt nur funktionieren, wenn das benutzerfreundlich ist. Das heißt also, wir wollen gerne ein benutzerfreundliches System haben. In erster Linie für Kunden, aber auch für die Leute in der Werkstatt. Und da gibt es noch eine andere Story. Und die andere Story ist, wenn dieses System hat besonders gut funktioniert, dann wollen wir halt eine SaaS-Lösung draus machen. Also dann wollen wir halt irgendwie dieses System anbieten in diesem Internet. Und dann wollen wir halt dafür sorgen, dass andere Leute es benutzen können. Das heißt, von den Themen, die wir hier haben, haben wir in erster Linie etwas in Bezug auf Benutzbarkeit. So und das ist, finde ich jetzt, erstmal eine spannende Aussage und vielleicht auch gar eine atypische. Also ich finde halt, dass Benutzerfreundlichkeit oder ich vermute, dass Benutzerfreundlichkeit in vielen Kontexten ein sehr wichtiger Punkt ist. Weil ohne Benutzerfreundlichkeit will eben jemand das System benutzen. Und dann stellt sich die Frage, warum zum Teufel entwickeln wir das überhaupt?

zwischen 9 und 18 Uhr für die Sachen im Shop. Das wäre also etwas, wo ich noch sagen könnte, okay, wir haben halt irgendwie eine Entwicklerin, die sich um das Thema im Wesentlichen kümmern kann. Die kümmern sich eben um das jetzt mit. Hier wird es dann schwierig, weil das ist von 7 bis 24 Uhr und von 24 bis 7 Uhr, das ist also ein 24-7-Support. Das heißt, ich brauche jetzt hier irgendwie spätestens an dieser Stelle, brauche ich irgendwie einen 24-7-Support. Ich brauche jemanden, der in Rufbereitschaft ist. Und das bedeutet jetzt wieder ein ganz anderes Thema. Das bedeutet nämlich, dass ich tatsächlich jemanden haben müsste, der eben nachts um 2 Uhr sich rausklingeln lässt. Und das wird wahrscheinlich keine Entwicklerin sein.

Es steht spätestens nach 30 Minuten wieder zur Verfügung. Das heißt, die Annahme ist, dass man nur 30 Minuten mit Zettel und Bleistift überbrücken kann. Wo man jetzt noch irgendwie drüber diskutieren könnte, nicht? Ernsthaft? Wirklich? Ist das tatsächlich so? So, und dann könnte man halt eine Diskussion führen und könnte halt sagen, naja, okay, also wenn eine Reparatur angenommen wird, dann kann ich das vielleicht länger. Aber wenn ich das jetzt irgendwie abhole, muss ich ja dem Menschen das Geld abknöpfen. Dafür brauche ich halt diese Information. Aha, okay. Das heißt, ich könnte jetzt das nochmal weiter detaillieren und könnte halt sagen, okay, die Information, wie viel diese Reparatur tatsächlich gekostet hat, wenn das Fahrrad abgeholt wird, das ist sogar noch wichtiger. Das muss halt, da darf es halt höchstens zwei Minuten ausfallen oder so. Können wir jetzt auch aufschreiben, nicht spätestens nach zwei Minuten kann man den Preis einer erfolgten Reparatur wieder ermitteln. So, und jetzt habe ich wieder was fachlich über dieses System gelernt, nicht? Also Annahme von Reparaturen nicht so kritisch wie irgendwie dieses Ermitteln von dem Preis. Und eine profane Möglichkeit, das zu lösen, ist, dass ich halt an der Stelle, wo die Reparatur fertig ist, irgendwie so ein Ding ausdrücke, das halt ans Fahrrad kleben. Und da steht irgendwie dran, diese Reparatur hat übrigens zehn Euro gekostet. Dann hätte ich das halt in gewisser Weise erledigt. Oder ich habe irgendwo eine Tabelle, die fest abgelegt ist, wo das eben drauf drin steht oder weiß da drauf was. Da kann man sich halt was ausdenken, nicht? Also das kriege ich halt irgendwie hin.

Und das ist also dort eben ein Thema. Der Jan fragt jetzt, wenn das System in der Cloud läuft und der Router im Laden ausfällt, ist das System aus Sicht des Kunden nicht erreichbar. Wie adressieren wir das? Genau, damit sind wir so zwei Schritte weiter. Also erstmal bedeutet das, meine Lösungsstrategie wäre halt irgendwie Cloud. Und das, was der Jan jetzt irgendwie sagt, ist ja nachvollziehbar. Das heißt also, wenn ich jetzt sage, ich habe exakt einen Router bei diesem Fahrradladen, dann würde das eben dafür sorgen, dass, wenn der Router ausfällt, eben das gesamte System ausfällt. Also das ist die Strategie, die mir jetzt eigentlich eingefallen ist. Es muss ja auch nicht nur eine Cloud-Strategie sein. Es könnte auch sein, dass wir am externen Rechenzentrum das machen. Ich glaube auf jeden Fall, also ich persönlich würde jedenfalls ableiten, dass wir einen Server in dem Laden selber ausschließen können. Das heißt, wir müssen dann in der Netzwerkverbindung kommen und dann kommen wir eben zu dem Thema, was der Jan dort zitiert hat. Und das ist jetzt tatsächlich, finde ich, eine spannende Sache. Eine mögliche Antwort darauf wäre, ich entwickle ja irgendwie Software. Dass es einen Router gibt, der mir dafür sorgt, dass mein System nicht erreichbar ist, ist nicht mein Problem, was soll’s. Das finde ich nicht wirklich hilfreich. Und das ist auch nicht die Art und Weise, wie ich denke, wie man diese Qualitätsszenarien interpretieren sollte. Also das Qualitätsszenario sagt er jetzt nicht. Also das Qualitätsszenario sagt, das ist die Erwartungshaltung, die ein Kunde hat. Die ist da jetzt irgendwie formuliert. Das heißt, die Erwartungshaltung ist in diesem speziellen Fall, das System fällt aus. Und spätestens nach zwei Minuten kann man den Preis einer erfolgten Reparatur wieder ermitteln. Und jetzt gibt es halt bestimmte Szenarien, also zum Beispiel Ausfall der Netzwerkinterfrastruktur. Also zum Beispiel Ausfall eines Routers, aber auch zum Beispiel Ausfall eines Internetproviders und so weiter. Die mir jetzt dort wahrscheinlich ein Problem bereiten. Und meine Strategie dagegen wäre eigentlich zu sagen, naja, wir können jetzt eine Lösung bauen, die erwartungsgemäß das üblicherweise auf die Reihe bekommt. Ich bin da vielleicht noch etwas auf der glücklichen Seite. Ich weiß nicht, wann ich hier das letzte Mal einen Internetausfall hatte. Und für den Notfall habe ich halt irgendwie noch einen mobilen Router. Sowas könnte ich ja jetzt in dem Fahrradshop irgendwie auch machen. Ich könnte also sagen, okay, es gibt einen mobilen Router, der über LTE oder über 5G oder sowas eben die Internetverbindung zur Not redundant hält. Und ich habe dann eben einen festen Router. Und ich gehe davon aus, dass das halt üblicherweise funktionieren sollte. Aber an bestimmten Stellen ist es dann eben einfach vorbei. Also wenn jetzt irgendwie beide Router ausfallen oder wenn irgendwo in dem Stadtteil das Internet insgesamt von einem Provider ausfällt, weil irgendwo ein Teil der Netzwerkinfrastruktur auf einer anderen Ebene kaputt geht. Dann habe ich halt irgendwie habe ich ein Problem. Und das wäre jetzt etwas, was ich diskutieren würde. Glaube ich, offen mit dem Kunden und würde sagen, okay, wir haben dann das Risiko eines Netzwerkausfalls und wir können das versuchen zu lösen. Also wir könnten jetzt ein Stück Software bauen, was wir bei dir installieren in deinem Server, den du nicht hast. Und was wir, was dann in der Lage ist, diese Preise der erfolgten Reparaturen zu cashen. Das führt zu einer bestimmten Menge an Aufwand und Geld, das wir investieren. Wollen wir das tun? Sondern das ist, finde ich, ein valides Feedback. Also meine Aufgabe ist es, technisch zu bewerten, wie ich das umsetzen kann. Und die variable Größe dabei ist Preis eigentlich. Das heißt also, ich kann jetzt eben durch entsprechende Entwicklungsmaßnahmen, Infrastrukturmaßnahmen versuchen, das noch unwahrscheinlicher zu machen. Auch auf der Ebene von Dingen, die außerhalb meines Einflussbereichs sitzen. Also ich kann jetzt sagen, okay, wir können noch einen mobilen Router daneben stellen. Wir können eine Netzwerkinfrastruktur machen, die automatisch auf den mobilen Router zurückfällt. Wir können, das kostet halt irgendwie einen Router und Netzwerktricks. Das ist also wahrscheinlich nicht so wahnsinnig teuer. Wir können bei dir einen Server installieren, der in Cash ist, mit den Preisen der erfolgten Reparatur. Das würde bedeuten, wir installieren einen Server. Das würde bedeuten, wir müssen den irgendwie warten. Das kriegen wir schwierig hin, weil wir müssen innerhalb von 30 Minuten da sein, sagst du. Das kostet also deutlich mehr Geld. Ich kann es nicht genau beziffern, aber es kostet halt deutlich mehr Geld. Und da kann man, glaube ich, dann in eine offene Diskussion gehen. Meine Erwartungshaltung wäre, dass wir halt über einen Fahrradshop gehen und wir wahrscheinlich irgendwie da landen, dass man sagt, okay, dieses Risiko, dass die Verbindung zur Cloud abbricht, ist irgendwie akzeptabel. Und vielleicht bauen wir dann einen mobilen Router als Fallback ein. Das wäre etwas anderes, wenn wir über die Maschinensteuerung eines Atomkraftwerks reden oder sowas. Oder über die Produktionssteuerung in einer Fabrik, wo irgendwie der Ausfall des IT-Systems dazu führt, dass wir halt massive Verluste haben. Und das wäre, glaube ich, das, was man da sozusagen als Feedback liefern kann.