Nach unserer Erfahrung nutzt das nur bedingt. Zum einen werden Disclaimer nicht unbedingt gelesen zum anderen werden diese - auch über längere Zeit hinweg - durch einen eigenen Glauben darüber ersetzt, was dort beinhaltet war.
Folgendes (typisches) Szenario:
1. Der Nutzer hat gerade eine Änderung vorgenommen+
2. Zeitnah dazu spielt der Nutzer ein Update der Software ein
3. Relativ Zeitnah stellt der Nutzer ein Problem fest am Server.
Welcher Änderung wird der durchschnittliche Nutzer nun als Ursache vermuten? Seine eigene Änderung oder die Änderungen durch die eingespielte neue Software. Nach unserer Erfahrung: zu 95% der neu installierten Software. Und so wird es der Nutzer dann auch hier im Forum oder gar gleich im Support adressieren "seit dem Update....". Die eigene Änderung wird dabei womöglich gar nicht mehr erwähnt.
Worauf ich hinaus möchte ist, dass wenn der Nutzer ein Problem mit dem Server hat, das er im Moment nicht beheben kann (oder ihm nicht bewusst ist, welcher seiner eigenen Änderungen davor das bewirkt hat) dann wünscht er eine Lösung und damit wendet er sich an das Forum und je nach Schweregrad direkt an uns (was er eigentlich nicht soll, wenn kein Supportvertrag besteht, weil sonst machen wir Support über das Forum) und will nun Hilfe. Da ist es ihm egal, was im Disclaimer gestanden hat, denn für sich subjektiv hat er alles richtig gemacht und erwartet nun Hilfe.
Und dabei spielt auch die Art und Weise der Störung eine Rolle, wie emotional die Unterstützung eingefordert wird. Nehmen wir an, wir stellen nun ein Objekt zum Herunterfahren des Servers zur Verfügung und in Verbindung mit der beliebigen Verknüpfung hat er es mit einem KNX Objekt verknüpft auf dem sich zu diesem Zeitpunkt nichts tut (etwas weil es Sommer ist und dieses Objekt nur im Winter genutzt wird). Dann wird es Winter und eine Logik springt an und fängt nun an auf das Objekt zu feuern...... Und kurz davor gab es ein Update von uns....
Das ist alles ganz menschlich und ganz normal, aber für uns als Hersteller eines komplexen Produktes ist es eine immense Herausforderung, wie wir Supportaufwändungen im Griff behalten. Weil wenn dann so ein Server dreimal am Tag herunterfährt und der Kunde beteuert nichts gemacht zu haben (den Zusammenhang mit im Sommer falsch eingestellt auf ein Objekt das im Winter feuert ist nicht bekannt) dann will der Kunde dass ihm geholfen wird. Wir können ja schlecht das eMail nicht beantworten. Finden wir dann nach längerer Analyse heraus (die beliebig kompliziert sein kann, wenn der Server schon vom nächsten Paket heruntergefahren wird) dass es ein Konfigurationsfehler ist, wer zahlt uns dann den Aufwand?
Ich kenne solche Diskussionen mit Kunden schon. Da kann man gleich für den selben Aufwand nochmal diskutieren.....
Es ist also nicht so einfach, solche Funktionen mit so gewaltigem Impakt zur Verfügung zu stellen und hoffen, dass jeder damit auch vollverantwortlich umgehen kann damit und im Zweifelsfall den Aufwand der vergeblichen Entstörung auch bereit ist zu bezahlen.
Ja, aber was hilft das? Es ermöglicht uns eine Beweisführung, deren Kosten wir eher nicht erstattet bekommen werden.gbglace hat geschrieben: ↑So Dez 12, 2021 12:39 pmZur weiteren Absicherung seitens Elabnet-Support würde ich da noch an Aufwand erkennen, dass man bei solchen elementaren aktiven Systemobjekten, auch ein separiertes Log über die Verknüpfungen hat. Quasi so einen Zwangs Doktormodus an diese Objekte und deren Verlinkungen. Damit sollte schnell klar werden welcher Trigger das ausgelöst hat.
Deswegen bitte ich um Verständnis, dass wir uns das gut überlegen wollen, ob wir solch mächtige Statusobjekte, mit Einfluss auf die Verfügbarkeit des Servers, zur Verfügung stellen wollen.
lg
Stefan