Kosten der Lösung vs. Kosten des Problems

Artikel vom 20. September 2007, exklusiv für Dr. Web. ISSN 1614-3124, #33. Schwerpunkt: Methodik (RSS-Feed für alle Themen).

Dieser und viele andere Beiträge sind auch als hübsches, wohlerzogenes E-Book erhältlich: On Web Development.

Probleme kosten Geld, und Probleme erfordern Lösungen, die ebenfalls Geld kosten. Diese Situation ist in allen Bereichen und Branchen präsent, doch in vielen Fällen wird nur auf eins geschaut: Wie viel kostet die Lösung eines Problems? Vernachlässigt wird die Kehrseite, nämlich die Kosten des Problems.

Die Kosten einer Lösung sind einfach zu bestimmen: Man ermittelt, was für ein zeitlicher und letztlich monetärer Aufwand notwendig ist, um sie zu erarbeiten und zu implementieren. Man konzentriert sich auf die aufzuwendenden Ressourcen.

Die Kosten des Problems entsprechen den finanziellen Folgen, wenn man nichts tut, wenn man das Problem bestehen lässt. Seine Lösung verursacht dementsprechend nicht nur Kosten, sondern verfügt auch über einen Wert. Wird das Augenmerk ausschließlich auf Problemlösungen gerichtet, egal, wie diese motiviert sind, ist zumindest »unklar«, ob tatsächlich wirtschaftlich gearbeitet wird. Einsicht in sowohl Kosten als auch Wert einer Lösung sind essentiell, um ökonomisch handeln zu können; die einzige Ausnahme mag der Wunsch nach Perfektion sein, denn Perfektion ist ein teurer Sport, ein Luxus von Idealisten, nicht aber von Pragmatikern, und das ohne Konnotat.

Das Einbeziehen nicht nur der Lösungs-, sondern auch der Problemkosten entspricht wirtschaftlicher Notwendigkeit. Nur die Kosten und der Wert der Lösung tragen dazu bei, Probleme richtig einordnen und priorisieren zu können.

Beispiele

Eine Firma will ihre Website runderneuern. Ein Pitch mit mehreren Agenturen führt zur Selektion einer, die ihr eine neue Online-Präsenz für pauschal 50.000 Euro zusichert; mitsamt organisatorischem Aufwand kalkuliert das Unternehmen mit Kosten in Höhe von 55.000 Euro. Diese Summe dient der Lösung des Problems »unsere Website lockt und hält zuwenig Kunden (und wir wollen eh was neues)«. So endet die Geschichte in den meisten Fällen, die Website wird überarbeitet.

Dieselbe Firma aber, sofern sie sich Analyse widmet, mag gemessen und errechnet haben: Im Durchschnitt generiert jeder Besucher der alten Website 30 Cent Gewinn; die neue Website deutet in Tests an, diesen auf 50 Cent steigern zu können. Bei angenommenen 100.000 Besuchern entspräche dies 20.000 Euro mehr Gewinn, je Monat, der antizipierte höhere Besucherstrom nicht einbezogen. Die Firma hat Gewissheit – eine zumindest wesentlich höhere Wahrscheinlichkeit –, dass sich die Problemlösung lohnt. Würde sie jedoch in einem anderen Szenario feststellen, dass eine Novellierung der Website vierstellige Mehreinnahmen erbringt, aber sie zwei Jahre benötigt, die Kosten wieder reinzuspielen, könnte sie das Problem und seine Lösung anders priorisieren, letztere vielleicht verwerfen.

Allein in der Internetbranche finden sich haufenweise vergleichbare Fälle, und jede Problemlösung sollte sich der Prüfung unterziehen, inwieweit die Kosten des Problems die der Lösung überwiegen: Ist eine Umstellung von XHTML auf HTML sinnvoll, wenn der Aufwand drei Manntage beträgt, der Nutzen aber nicht messbar, vielleicht nicht vorhanden ist? Sollte die Überarbeitung des Registrierungsbereichs, der unter einer Abbruchrate von 75% leidet, wirklich um sechs Monate verschoben werden? Muss ein einziger Pixelfehler im Internet Explorer 6 mittels »Conditional Comments« behoben werden?

Was Marketing-Fachleuten wie auch Vertrauten von Kosten-Nutzen-Analysen (DOC, 17 KB) bekannt sein könnte, darf in diesem Fall getrost noch mehr Aufmerksamkeit erhalten: Strategische oder idealistische Motivation ausgeklammert, müssen immer nicht nur die Kosten der Lösung, sondern auch des Problems betrachtet werden, um wirtschaftliche Entscheidungen fällen zu können.

Über mich

Ich bin Jens (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin Mitwirkender an verschiedenen Webstandards und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Erfahrungen und Ansichten. (Bitte sei kritisch, interpretiere wohlwollend und gib Feedback.)