Der Deckungsbeitrag (Unit Economics) von Softwareprodukten

Der Kern von Unternehmertum ist es, Probleme zu erkennen und diese mit Produkten zu lösen. Wenn Unternehmen wachsen, die Zahl der Produkte zunimmt, mehr Mitarbeiter angestellt werden und die Kosten steigen, stellen sich sowohl operative als auch strategische Fragen. Wenn wir bei Ookam Software Investitionsmöglichkeiten abwägen, diskutieren wir genau diese Fragen intern als auch mit der Geschäftsführung / dem Management-Team.

Diese Fragen sind:

  • Was sollte das Produkt kosten?

  • Wie wird über die Marktgröße nachgedacht? Neue Version = neue Marktgröße?

  • Wie werden die Kosten gestaltet?

Dazu kommen Fragen wie:

  • Kann ich mir einen Vertriebler im Außendienst leisten?

  • Kann ich mir kostenlosen Support leisten?

  • Wie finanziere ich die Entwicklung neuer Produkte?

In diesem Artikel legen wir die Grundlagen, um über diese Fragen nachzudenken. Dabei beantworten in diesem Artikel zunächst die ersten drei Fragen (ein weiterer Blog-Artikel folgt).

Vorab: Wir arbeiten im Folgenden mit Beispielen und vereinfachten Sachverhalten. Wir wollen versuchen, die grundsätzliche Mechanik zu erläutern.

Teil 1: Der Deckungsbeitrag von Softwareprodukten (Unit Economics)

Jedes Produkt hat Kosten. Die Kosten hängen selbstverständlich von der Art des Produkts ab. Hardware-Produkte haben beispielsweise Materialkosten und Produktionskosten. Dienstleister habe die Kosten der Zeit (bspw. Jahresgehalt eines Consultants). Händler haben den Einkaufspreis.

Kosten, die für jede weitere Einheit anfallen heißen “Grenzkosten”, “Marginalkosten” oder  “mengenabhängige Kosten” auf Englisch “marginal costs”. Diese Begriffe bezeichnen allesamt die Kosten, die für eine weitere Einheit des Produktes anfallen. Alle anderen Kosten, wie Beispielsweise Management oder Forschungsausgaben fallen auf Ebene des Unternehmens an.

Bei Hardwareprodukten oder im Handel sind diese Kosten offensichtlich: Fertige ich Hardware benötigt jede weitere Einheit eines Produktes weitere Komponenten. Bin ich im Handelsgeschäft so kann ich Waren, die ich nicht eingekauft habe, auch nicht verkaufen.

Bei Softwareprodukten ist diese Rechnung schwieriger, aber entscheidend zur Beantwortung der Fragen, die wir uns Eingangs stellten. Nehmen wir also den hypothetischen Fall einer B2B Software, die wir für Kunden in der Cloud hosten. (Wir vereinfachen -  hier mehr zur Umsatzstruktur von Softwareunternehmen).

Die Grenzkosten könnten so aussehen:

Schauen wir uns die Kosten genauer an - “Hosting” und “verwendete Lizenzen” könnten bereits pro Kunde abgerechnet werden (AWS Pricing), das bedeutet hier wissen wir relativ genau was die Kosten pro Produkt sind.

Grenzkosten+Software.png

Größere Kostenpunkte sind wahrscheinlich der Support der Software, beispielsweise über eine Hotline, per E-mail oder Chat. Die Kosten pro verkauftem Produkt berechnen wir so: wir schätzen ab wie viele Kunden ein MItarbeiter betreuen kann und teilen die Gesamtkosten pro Mitarbeiter durch diese Zahl. Im Beispiel gehen wir von 50 Kunden pro Mitarbeiter aus und nehmen die Kosten pro Mitarbeiter (Gehalt, Arbeitsplatz, Software) mit 50,000 Euro an. Ergibt pro Kunde somit Kosten von 1,000€.

Im Gegensatz zu Hardware ist Software selten “fertig”. Das bedeutet, dass wir Kosten für die Pflege und Bugfixes annehmen müssen. Hier nehmen wir an, dass für die Pflege der Software gut 11 Stunden pro Jahr anfallen. Aus dem Jahresgehalt unserer Entwickler leiten wir Kosten von insgesamt 1.100€ pro Kunde pro Jahr ab.

An dieser Stelle gibt es zwei Fragen: “Entstehen diese Kosten wirklich pro verkaufter Version?”, “Was ist wenn die Mitarbeiter ohnehin an der nächsten Version arbeiten?” und “Was ist mit den Vertriebskosten?”


Einschub 1: Entstehen diese Kosten wirklich pro verkaufter Version?Oftmals wird argumentiert, dass die Grenzkosten bei Software “nahezu null” sind. Dies ist bei komplexer B2B Software nicht der Fall - natürlich kostete eine Kopie des Codes nahezu nichts und auch eine weitere Amazon Web Services Instanz kostet wenig. Doch bilden diese Kosten nicht die realen Kosten für B2B Software ab. Diese Kosten liegen in der Regel in der Wartung und dem Support der Software - genau aus diesem Grund sind Wartungs- und Supportverträge üblich.

Der Unterschied zu anderen “einmalig verkauften” Produkten ist, dass die Grenzkosten nicht ganz so trennscharf wie in der physischen Welt sind. In unsere Beispiels sehen wir das im Support: Natürlich könnte ein Support-Mitarbeiter zwischenzeitlich statt 50 auch 51 Kunden betreuen, dennoch gibt es einen akzeptablen Durchschnitt den wir hier ausdrücken.

Einschub 2: Wo tauchen hier die Vertriebskosten auf?Es erscheint offensichtlich, dass die Kosten für den Vertrieb mit der Zahl der verkauften Produkte zusammenhängen. Eine Kommission greift schließlich genau pro verkauftem Produkt. Genau hier liegt jedoch ein wesentlicher Unterschied von Softwareprodukten mit wiederkehrenden Umsätzen - Vertriebskosten sind von der Natur her eher einmalige Kosten, wie die Produktentwicklung: angenommen die Abwanderungsquote ist gering genug. Deshalb gehen wir in einem separaten Artikel darauf ein.

Unit+Economics+Software.png

Wenn wir also nun unsere Grenzkosten haben und zusätzlich den Preis pro verkaufter Einheit wissen, dann ergibt sich folgendes Bild pro verkaufter Version.

Der Deckungsbeitrag ist schlicht die Differenz zwischen dem Preis und der Grenzkosten. Im Englischen ist der Deckungsbeitrag die “contribution margin”.

Teil 2: Die Unternehmenssicht (Company Economics)

Ein Unternehmen ist eine Organisation, die Produkte entwickelt und vertreibt. Anders ausgedrückt - die Kosten eines Unternehmens ergeben sich aus der Summe Grenzkosten, plus aller anderen Kosten, die nicht an der Anzahl verkaufter Produkte hängen - beispielsweise F&E oder Management. So ergibt sich folgendes Bild:

Deckungsbeitrag+Lizenzmiete.png

Links die schematische Sicht auf ein Produkt. Rechts die Sicht auf das Unternehmen. Der blaue Teil ergibt sich aus der Summe aller verkauften Einheiten des Produktes. Alle anderen Kosten, die wir nicht nach der oben beschriebenen Logik sinnvoll auf Produktebene abbilden können liegen als “Nicht-Grenzkosten” auf dem Level des Unternehmens.

Frage 1: Wie denken wir über Marktgröße nach?

Einfach gesprochen: Es müssen genügend Einheiten des Produktes verkaufen können, als dass die Summe der Deckungsbeiträge alle verbleibenden Kosten des Unternehmens tragen können.

Schematisch in einer Graphik zusammengefasst ergibt sich folgendes Bild:

Marktgröße+-+Deckungsbeitrag.png

Die grünen Rechtecke stellen, wie immer schematisch, den Deckungsbeitrag da. Sobald die grüne Box die nicht-variablen Kosten decken, haben wir den Break Even, also die Gewinnzone erreicht. In diesem Fall also nach fünf Verkäufen.

Alle weiteren Verkäufe sind “profitabel” - bedeutet mit diesen Umsätzen können die Investitionen zurückgezahlt werden - das sind typischerweise a) einmalige Kundenakquisitionskosten und b) die einmalige Entwicklungskosten.

Frage 2: Wieviel sollte mein Produkt kosten?

Blicken wir zunächst auf die vorherige Grafik. Unser Ziel ist es, über Zeit genügend Deckungsbeiträge einzusammeln, um zunächst die Nicht-Grenzkosten des Unternehmens zu Decken. Danach geht es darum, die ursprünglichen Investitionen zurückzuzahlen. Ob wir das Geld dabei als Profit ausschütten oder re-investieren ist eine separate Frage.

Dafür bleiben drei Hebel: Der Preis, die Grenzkosten und die Zahl der realistisch verkaufbaren Einheiten.

Die Zahl der realistisch verkaufbaren Einheiten ist schlicht die Marktgröße, die in der Regel fix ist. Die Grenzkosten sind oftmals schwer reduzierbar.

Preis_Grenzkosten_Lizenzmiete.png

So ergibt sich oft aus der Marktgröße und den Nicht-Grenzkosten ein Preis, zu dem das Produkt angeboten werden kann um die Investitionen in einem realistischen Zeitrahmen zurückzuzahlen.

Wir danken für die Aufmerksamkeit und freuen uns über Kommentare und Verbesserungsvorschläge. Weitere Teile folgen.

Autor: Steffen Bünau