Wenn Sicherheit unwirtschaftlich wird

Manchmal beginnt eine technische Überlegung mit einem sehr einfachen wirtschaftlichen Gedanken:

Wenn eine Leistung ohnehin erbracht wird, sollte möglichst wenig davon ungenutzt bleiben.

Das klingt selbstverständlich. In technischen Systemen kann daraus jedoch eine erstaunlich schwierige Frage entstehen.

Besonders dann, wenn die eigene Messung und die Messung eines anderen Systems nicht synchron laufen.

Genau an diesem Punkt beginnt die Geschichte eines kleinen technischen Versuchs zur automatisierten Verwaltung von Zählmarken.

Der Versuch war technisch erfolgreich.

Die wirtschaftliche Idee dahinter war es nicht.

Nicht, weil die Idee grundsätzlich falsch gewesen wäre.

Sondern weil eine Information fehlte, die für ihre Umsetzung entscheidend war.

Der Brunnen

Stellen wir uns einen Brunnen vor.

Aus diesem Brunnen fließt fortlaufend Wasser. Das Wasser gehört der Besitzerin des Brunnens. Sie hat die Quelle erschlossen und den Brunnen auf eigene Kosten errichtet.

Eine Magd steht am Brunnen und stellt Eimer darunter.

Ein Käufer bezahlt einen Eimer allerdings nicht für jeden beliebigen Füllstand. Vergütet wird ein vollständig gefüllter Eimer.

Nehmen wir an, ein Eimer fasst 1.500 Einheiten Wasser.

Erst wenn diese 1.500 Einheiten erreicht sind, entsteht der wirtschaftliche Wert des Eimers.

Ein Eimer mit 1.499 Einheiten ist in diesem Gedankenmodell wirtschaftlich etwas grundlegend anderes als ein voller Eimer:

Der eine wird vergütet. Der andere wird nicht vergütet.

Damit entsteht eine ungewöhnliche Situation.

Die Magd muss nicht mehr Wasser aus dem Brunnen holen. Sie muss lediglich ihre Arbeit so organisieren, dass das vorhandene Wasser möglichst zuverlässig in vollständig gefüllten Eimern ankommt.

Das Wasser, das danebenläuft

Angenommen, die Magd schafft es, einen Eimer exakt bei 1.500 Einheiten wegzunehmen und den nächsten darunterzustellen.

Dann ist ihre Arbeit wirtschaftlich effizient.

Der Eimer wird genau bis zur Vergütungsschwelle gefüllt.

Nichts Wesentliches läuft über.

Nun kann die Magd aber auch vorsichtiger arbeiten.

Sie wartet nicht bis 1.500, sondern bis 1.600 Einheiten, bevor sie den Eimer entfernt.

Die zusätzlichen 100 Einheiten erhöhen in diesem Modell die Vergütung nicht.

Sie dienen lediglich als Sicherheit dafür, dass der Eimer mit hoher Wahrscheinlichkeit tatsächlich als voll gilt.

Das ist der entscheidende Punkt der Metapher:

Die zusätzlichen 100 Einheiten sind kein zusätzlicher wirtschaftlicher Ertrag. Sie sind der Preis für die Sicherheit.

Je größer dieser Sicherheitsabstand wird, desto mehr Wasser wird zwar in den Eimer geleitet, ohne dass sich dadurch dessen Vergütung erhöht.

Bei 1.600 Einheiten beträgt der Puffer gegenüber 1.500 Einheiten rund 6 Prozent.

Bei 3.00 Einheiten wären es bereits 100 Prozent zusätzliche Menge.

Die Magd müsste also doppelt so viel Wasser in einen Eimer laufen lassen, um eine hohe Sicherheit für eine Vergütung zu erreichen, die weiterhin nur auf einem vollen Eimer beruht.

Die perfekte Welt wäre synchron

Die wirtschaftlich interessanteste Situation wäre deshalb eine andere.

Die Magd müsste genau wissen, wann der Käufer seinen Eimer als voll betrachtet.

Wenn beide Zähler synchron laufen, wäre die Sache einfach:

• 1.500 Einheiten werden in den Eimer geleitet;
• der Eimer erreicht die Vergütungsschwelle;
• der Eimer wird gewechselt;
• der nächste Eimer beginnt.

Es gäbe keinen nennenswerten Sicherheitsabstand.

Das vorhandene Wasser würde möglichst effizient auf die vergüteten Einheiten verteilt.

Genau diese Synchronität wäre das eigentliche Optimum.

Und genau sie war technisch nicht sicher herstellbar.

Die Übertragung auf Zählmarken

Das Gedankenmodell lässt sich auf die Verwaltung von Zählmarken übertragen.

Für die technische Machbarkeitsstudie wurde angenommen, dass eine Zählmarke eine bestimmte Anzahl von Aufrufen erreichen muss, damit überhaupt eine Vergütung entstehen kann. Im untersuchten Modell liegt diese Schwelle bei 1.500 Aufrufen.

Aus betriebswirtschaftlicher Sicht wäre das ideale Verhalten eindeutig:

Eine Zählmarke wird so lange verwendet, bis sie möglichst genau die erforderliche Schwelle erreicht. Danach wird die nächste Zählmarke eingesetzt.

Würde der eigene Zähler exakt mit dem maßgeblichen Zähler der VG WORT übereinstimmen, wäre die Sache relativ einfach.

1.500 Aufrufe.

Zählmarke erfüllt.

Nächste Zählmarke.

Die eigene Website würde damit nicht mehr Aufrufe erzeugen. Sie würde lediglich ihre vorhandenen Zählmarken möglichst effizient verwalten.

Das eigentliche Problem ist die Unsicherheit

Nun entsteht die entscheidende Schwierigkeit.

Der Betreiber der Website kann feststellen, wie oft sein eigenes System einen Trackingvorgang ausgelöst hat.

Er kann diesen Vorgang lokal zählen.

Er kann seine Zählmarken verwalten.

Was er nicht zuverlässig feststellen kann, ist der exakte Zählerstand des externen Systems.

Damit weiß er nicht sicher, ob beispielsweise 1.500 lokale Aufrufe tatsächlich 1.500 für die Vergütung relevante Aufrufe beim externen System darstellen.

Vielleicht sind es weniger.

Vielleicht fehlen einzelne Abrufe.

Vielleicht werden bestimmte Vorgänge auf der anderen Seite anders bewertet.

Für die lokale Software sind diese Vorgänge trotzdem Teil ihrer eigenen Statistik.

Die beiden Zähler können deshalb auseinanderlaufen.

Das Problem ist nicht, dass der eigene Zähler ungenau wäre. Das Problem ist, dass er eine andere Wirklichkeit misst.

Warum 1.600 zunächst vernünftig erscheinen

Eine naheliegende Reaktion auf diese Unsicherheit ist ein Sicherheitspuffer.

Statt bei exakt 1.500 lokalen Aufrufen zu wechseln, wird eine Zählmarke beispielsweise erst bei 1.600 Aufrufen gewechselt.

Die zusätzlichen 100 Aufrufe sollen die mögliche Differenz zwischen den beiden Systemen auffangen.

Auf den ersten Blick ist das vernünftig.

Man kauft sich Sicherheit durch einen kleinen zusätzlichen Verbrauch.

Im Brunnenbild bedeutet das:

Die Magd lässt etwas mehr Wasser in den Eimer laufen, weil sie nicht genau weiß, wann der Käufer seinen Eimer als voll betrachtet.

Ein solcher Puffer kann sinnvoll sein, wenn die Unsicherheit klein und bekannt ist.

Doch genau hier liegt das Problem.

Die Größe der tatsächlichen Abweichung ist nicht zuverlässig bekannt.

Der Preis der Sicherheit

Je größer die angenommene Unsicherheit wird, desto größer muss der Sicherheitsabstand werden.

Und damit verschlechtert sich die Wirtschaftlichkeit.

Nehmen wir als Gedankenexperiment eine Abweichung von 50 Prozent an.

Wenn der Betreiber mit ausreichender Wahrscheinlichkeit sicherstellen möchte, dass die externe Zählung die Schwelle von 1.500 erreicht, könnte ein lokaler Schwellenwert von 3.00 erforderlich erscheinen.

Damit würde jede Zählmarke lokal doppelt so viele Aufrufe aufnehmen, wie für die eigentliche Vergütungsschwelle notwendig wären.

Das ist der entscheidende wirtschaftliche Zielkonflikt.

Bei 1.500 besteht das Risiko, dass die externe Zählung darunter bleibt und damit keine Vergütung entsteht.

Bei 3.00 wird dieses Risiko möglicherweise deutlich reduziert, aber der Preis dafür ist eine erhebliche Verschlechterung der Nutzungseffizienz der Zählmarke.

Die Sicherheit wird mit zusätzlicher Nutzung bezahlt, die selbst keinen zusätzlichen Vergütungsanspruch erzeugt.

Die Optimierung ist damit paradox geworden.

Je mehr Sicherheit man gegen die Unsicherheit einbaut, desto unwirtschaftlicher kann die Lösung werden.

Das Problem ist nicht zwischen 1.500 und 1.600

Es wäre deshalb zu kurz gegriffen, die Untersuchung als Frage nach dem richtigen Schwellenwert zu verstehen.

Vielleicht sind 1.600 richtig.

Vielleicht wären 1.550 besser.

Vielleicht 1.700.

Vielleicht 1.900.

Die eigentliche Frage lautet:

Woher weiß das lokale System, wie groß die tatsächliche Abweichung zwischen seinem Zähler und dem externen Zähler ist?

Wenn diese Information fehlt, wird jeder Sicherheitswert zu einer Annahme.

Und je größer die Unsicherheit angenommen wird, desto größer wird die wirtschaftliche Belastung dieser Annahme.

Die technische Lösung kann die Unsicherheit verwalten.

Sie kann sie aber nicht aus der eigenen Statistik heraus beseitigen.

Eine Optimierung, die kein Optimum kennt

Damit wird sichtbar, warum die ursprüngliche Idee letztlich kein belastbares Optimierungsproblem mehr ist.

Ein Optimierungsproblem benötigt Größen, die beobachtet oder zumindest hinreichend zuverlässig geschätzt werden können.

Hier gibt es jedoch zwei Größen:

• den lokal beobachtbaren Aufruf;
• den extern bewerteten Aufruf.

Zwischen beiden besteht eine unbekannte Differenz.

Solange diese Differenz nicht zuverlässig bestimmt werden kann, kann auch der optimale Wechselpunkt nicht zuverlässig bestimmt werden.

Man kann einen konservativen Wert wählen.

Man kann einen aggressiven Wert wählen.

Man kann einen Sicherheitsfaktor definieren.

Aber man kann nicht behaupten, damit das wirtschaftliche Optimum gefunden zu haben.

Ein Sicherheitsfaktor ist keine Messung.

Das Risiko ist asymmetrisch

Besonders interessant ist, dass die beiden Fehler nicht wirtschaftlich gleichwertig sind.

Wird eine Zählmarke zu früh gewechselt, besteht das Risiko, dass die notwendige externe Schwelle von 1.500 nicht erreicht wird.

Die Folge kann im untersuchten Vergütungsmodell sein:

Die Zählmarke wird verwendet, ohne dass daraus eine Vergütung entsteht.

Wird dagegen zu spät gewechselt, wird die Schwelle zwar mit höherer Wahrscheinlichkeit erreicht, aber ein Teil der zusätzlichen Aufrufe wird nicht effizient auf die nächste vergütungsfähige Einheit verteilt.

Das ist betriebswirtschaftlich ebenfalls ungünstig.

Die beiden Fehler lassen sich deshalb nicht einfach gegeneinander aufrechnen.

Der eine Fehler kann den gesamten wirtschaftlichen Ertrag einer Zählmarke gefährden.

Der andere verschlechtert die Effizienz, mit der vorhandene Nutzung auf vergütungsfähige Zählmarken verteilt wird.

Die technische Machbarkeitsstudie

Aus dieser Überlegung entstand der technische Versuch.

Die Zählmarken wurden als eigenständige Datensätze organisiert. Jede UUID erhielt ein eigenes Verzeichnis. Die benötigten Werte wurden direkt in PHP-Dateien gespeichert.

Eine Datenbank war nicht erforderlich.

Das System konnte verfügbare UUIDs erkennen, Zählerstände führen, Jahreswechsel verarbeiten und historische Werte erhalten.

Ein Dashboard machte den Zustand des Systems sichtbar.

Parallele Zugriffe wurden über Dateisperren berücksichtigt.

Die technische Verwaltung funktionierte.

Gerade deshalb wurde die entscheidende Grenze so deutlich sichtbar.

Das System scheitert nicht an der Technik

Der entscheidende Befund war kein Programmierfehler.

Es war auch kein Problem der Dateiverwaltung.

Die lokale Anwendung konnte sehr genau wissen, was sie selbst getan hatte.

Sie konnte jedoch nicht zuverlässig wissen, was das externe System daraus gemacht hatte.

Damit war eine zentrale Information für die wirtschaftliche Optimierung nicht verfügbar.

Das ist eine andere Art von Grenze als ein fehlendes Feature.

Ein fehlendes Feature kann programmiert werden.

Eine fehlende Information kann nur dann technisch ergänzt werden, wenn es eine verlässliche Quelle für diese Information gibt.

Wenn diese Quelle nicht verfügbar ist, bleibt nur die Schätzung.

Und eine Schätzung kann für eine wirtschaftlich relevante Entscheidung zu unsicher sein.

Das größere Problem hinter dem kleinen Problem

An dieser Stelle wird aus einer Untersuchung von Zählmarken eine allgemeine Frage über Systeme.

Technische Systeme arbeiten häufig mit Stellvertretergrößen.

Wir messen eine Größe, weil die eigentlich interessierende Größe nicht direkt zugänglich ist.

Solange beide Größen hinreichend gut miteinander korrelieren, fällt das nicht weiter auf.

Erst wenn die Differenz relevant wird, zeigt sich die Grenze des Modells.

Genau das ist hier geschehen.

Der lokale Zähler war nicht falsch.

Er war nur nicht identisch mit der Größe, die für die wirtschaftliche Entscheidung entscheidend war.

Eine korrekte Messung kann für eine Entscheidung trotzdem die falsche Messung sein.

Warum mehr Sicherheit nicht automatisch besser ist

In vielen Bereichen gilt Sicherheit als uneingeschränkt positiv.

Man baut Reserven ein.

Man plant Puffer.

Man kalkuliert konservativ.

Das ist häufig vernünftig.

Aber Sicherheit hat einen Preis.

Ein Sicherheitsabstand von fünf Prozent kann wirtschaftlich kaum ins Gewicht fallen.

Ein Sicherheitsabstand von zehn Prozent kann noch vertretbar sein.

Ein Sicherheitsabstand von fünfzig Prozent verändert möglicherweise die gesamte Wirtschaftlichkeit eines Verfahrens.

Im vorliegenden Gedankenmodell würde ein lokaler Schwellenwert von 3.00 statt 1.500 bedeuten, dass für die hohe Wahrscheinlichkeit einer Vergütung eine doppelte Nutzung der einzelnen Zählmarke in Kauf genommen wird.

Die vermeintliche Lösung erzeugt damit ein neues Problem:

Um das Risiko einer ausbleibenden Vergütung zu reduzieren, wird die Nutzung der vorhandenen Zählmarken so ineffizient, dass die ursprüngliche Optimierung ihren Sinn verliert.

Die eigentliche Grenze

Die Untersuchung hätte an dieser Stelle noch lange weitergeführt werden können.

Man hätte andere Schwellenwerte testen können.

Man hätte statistische Modelle entwickeln können.

Man hätte historische Abweichungen untersuchen können.

Man hätte immer ausgefeiltere Sicherheitsfaktoren berechnen können.

Doch ohne verlässliche Information über die externe Zählung wäre auch ein sehr komplexes Modell letztlich eine Schätzung.

Die entscheidende Frage ist daher nicht:

Wie intelligent kann die lokale Software die unbekannte Differenz erraten?

Sondern:

Kann die für die Entscheidung erforderliche Information überhaupt zuverlässig beobachtet werden?

Wenn die Antwort nein lautet, ist die Grenze erreicht.

Was bleibt?

Die Untersuchung war deshalb nicht umsonst.

Im Gegenteil.

Sie hat gezeigt, dass eine datenbankfreie Verwaltung von Zählmarken technisch möglich ist.

Sie hat gezeigt, dass UUIDs, Zählerstände, Jahreswerte und Statistiken mit einfachen und langfristig wartbaren Mitteln verwaltet werden können.

Sie hat gezeigt, dass ein solches System transparent gemacht werden kann.

Und sie hat gezeigt, an welcher Stelle die technische Lösung an eine Grenze stößt, die nicht durch besseren Code beseitigt werden kann.

Das ist ein verwertbares Ergebnis einer Machbarkeitsstudie.

Nicht jede Studie muss mit einer Produktionsfreigabe enden.

Manchmal besteht ihr Wert darin, rechtzeitig zu zeigen, warum eine zunächst plausible Idee unter bestimmten Randbedingungen nicht tragfähig ist.

Vom Zählen zum Denken

Vielleicht liegt darin die eigentliche Erkenntnis dieses kleinen Projekts.

Am Anfang stand eine wirtschaftliche Überlegung:

Wenn vorhandene Nutzung ohnehin stattfindet, wäre es sinnvoll, die vorhandenen Zählmarken möglichst effizient zu verwenden.

Das ist eine vernünftige Idee.

Ihre Umsetzung scheitert nicht an mangelndem technischen Geschick, sondern an einer fehlenden Beobachtbarkeit.

Und damit verschiebt sich die Frage.

Nicht mehr:

Wie kann ich den Zähler besser programmieren?

Sondern:

Welche Information brauche ich, um überhaupt zu wissen, wann die richtige Entscheidung getroffen werden kann?

Das ist eine wesentlich grundlegendere Frage.

Die Frage hinter der Zahl

Wir leben in einer Welt voller Kennzahlen.

Organisationen messen Leistung.

Unternehmen messen Kosten.

Projekte messen Fortschritt.

Websites messen Zugriffe.

Systeme messen Zustände.

Dashboards machen diese Zahlen sichtbar.

Doch eine sichtbare Zahl ist noch keine vollständige Beschreibung der Wirklichkeit.

Man muss wissen, wie sie entstanden ist.

Man muss wissen, was sie nicht erfasst.

Und man muss wissen, ob die Zahl tatsächlich die Größe beschreibt, über die eine Entscheidung getroffen werden soll.

Nicht jede präzise Zahl ist eine gute Entscheidungsgrundlage.

Vielleicht ist genau das die Verbindung zwischen technischer Arbeit und systemischem Denken:

Man beginnt nicht mit der Methode.

Man beginnt mit dem Verständnis des Systems.

Man fragt, welche Größen miteinander verbunden sind, welche voneinander abhängen und wo Informationen fehlen.

Erst danach stellt sich die Frage, welche technische Lösung sinnvoll ist.

Und wieder die Magd am Brunnen

Die Magd steht noch immer am Brunnen.

Das Wasser fließt.

Sie kann zählen, wie viel Wasser sie selbst in den Eimer geleitet hat.

Aber sie kann nicht sehen, wie der Käufer seinen Eimer zählt.

Sie kann deshalb entweder knapp kalkulieren und riskieren, dass ein Eimer nicht als voll gilt.

Oder sie kann großzügig kalkulieren und mehr Wasser als nötig in jeden Eimer laufen lassen.

Im ersten Fall riskiert sie, dass ihre Arbeit überhaupt nicht vergütet wird.

Im zweiten Fall bezahlt sie die Sicherheit mit Effizienz.

Beides ist eine schlechte Ausgangslage.

Die wirklich wirtschaftliche Lösung wäre eine andere:

Sie müsste wissen, wann der Käufer seinen Eimer als voll betrachtet.

Dann könnte sie genau bis zu diesem Punkt arbeiten.

Nicht mehr.

Nicht weniger.

Und vielleicht ist das die eigentliche Lehre aus diesem Versuch:

Optimierung beginnt nicht damit, einen besseren Sicherheitsfaktor zu finden.

Sie beginnt damit, herauszufinden, ob man die Größe, die man optimieren möchte, überhaupt zuverlässig beobachten kann.

Denn manchmal ist nicht die Lösung zu kompliziert.

Sondern das Wissen, das für eine gute Lösung notwendig wäre, fehlt.