Shop-Software: Hier lauern die Lizenz-Kostenfallen

Wer ein neues Shopsystem sucht, hat die Qual der Wahl. Neben dem reinen Funktionsumfang wollen der Integrations-, Anpassungs- und Wartungsaufwand, Time-to-Market, die Zukunftsfähigkeit des Systems und nicht zuletzt auch die umgebende Dienstleisterlandschaft bedacht sein. Schon die Auflistung zeigt, dass betriebswirtschaftliche Gesichtspunkte neben technischen Aspekten eine mindestens ebenso große Rolle spielen. Damit rücken automatisch auch die Lizenzkosten einer Software in den Mittelpunkt - und damit auch die verschiedenen Lizenzmodelle. Ein falsche Entscheidung kann schließlich viel Geld kosten.

Der Gründer hat in dieser Situation zwei Möglichkeiten: Die Auswahl eines bestehenden Systems oder die Einrichtung und Erstellung eines eigenen Onlineshops. Es liegt in der Natur der Sache, dass eine individuell programmierte Software optimal zu den Abläufen im Unternehmen passt. Schließlich wird die Software speziell zur Vereinfachung dieser Abläufe entwickelt. Dafür sind die Kosten einer individuell entwickelten Software nicht gerade gering. Sie berechnet sich aus dem Aufwand, den Wünschen des Kunden und dem Stundensatz des Entwicklers. Entsprechend weit ist die Spanne der Kosten: Sie reicht von einem fünfstelligen Betrag für eine einfache Lösung bis in den sechsstelligen Bereich.

Für viele Unternehmen ist das deutlich zu viel. Sie fahren mit einer Standardlösung deutlich günstiger. Spätestens nun ist es Zeit, sich mit dem verschiedenen Modellen des Software-Erwerbs auseinanderzusetzen. Neben der Eigenentwicklung sind mindestens vier verschiedene Modelle zu unterscheiden:

• Eigenentwicklung (on Premise)
  
• Open-Source (on Premise / Cloud)
  
• Closed-Source Kauf (on Premise)
  
• Closed-Source Miete (on Premise / Managed Hosting)
  
• Closed-Source Abo (Cloud)

Auch wenn bei jedem Modell letztlich immer dieselbe Summe finanziert werden muss, ergeben sich am Ende deutliche Unterschiede in der Art und Weise, wie diese fällig wird und - vor allem - welche Folgekosten sich aus den einzelnen Modellen ergeben. Das sind die Vor- und Nachteile:

Eigenentwicklung	Bei schlechter Dokumentation ergeben sich Abhängigkeiten vom Dienstleister. Unter Umständen müssen eigene IT-Mitarbeiter angestellt werden. Insgesamt wird vom Unternehmen ein hoher digitaler Reifegrad und IT-Knowhow gefordert. Schließlich liegt die Führungsaufgabe beim Händler.
Open-Source	Auch wenn bei Open-Source-Lösungen keine Lizenzkosten anfallen, heißt das keinesfalls, dass sie kostenlos sind. Wenigstens der Support muss sichergestellt sein. In der Regel sind dafür kostenpflichtige Enterprise-Verträge erforderlich. Dafür erhält der Kunde eine hohe Flexibilität, hervorragende Dokumentation und die Unterstützung einer (meist) großen Community. Sonder- und Spezialanwendungen lassen sich entsprechend leicht realisieren. Der Händler bewegt sich also faktisch irgendwie zwischen Fertig-Software und Eigenentwicklung - mit allen damit verbundenen Vor- und Nachteilen. Als Cloud-Lösung kombiniert sich geringer Wartungsaufwand mit hohem Individualisierungsgrad.
Closed-Source Kauf (on Premise)	Bei der Lizenzierung einer Closed-Source-Lösung müssen neben den einmaligen Lizenzkosten ebenfalls Kosten für den Support sichergestellt werden. Auch beim Softwarekauf entstehen also laufende Kosten. Außerdem werden regelmäßig kostenpflichtige Updates und Upgrades bzw. Versionswechsel fällig. Durch die hohen Einmalkosten entsteht eine recht lange Bindung. Individualisierungen sind möglich, aber oft aufwändig. Bei tiefgreifenden Eingriffen geht Support und (oft) auch die Möglichkeit reibungsloser Updates verloren.
Closed-Source Miete (on Premise / Managed Hosting)	Die Mietkosten werden in festen Zeitintervallen (meist monatlich) fällig. Oft ist in den Kosten der Support bereits enthalten. Außerdem entfallen meist die Zusatzkosten für Updates oder Versionswechsel. Allerdings: Auch wenn im Vertrag ein fester monatlicher Betrag festgeschrieben ist, können sich die Mietkosten im Laufe der Zeit erhöhen. Häufig wird dann eine bestimmte Produktlinie nicht mehr weiterentwickelt. Der Hersteller drängt die User dazu, auf den (teureren) Nachfolger zu wechseln. Nicht zu unterschätzender Vorteil einer Mietlösung ist jedoch, dass die monatlichen Gesamtkosten einfach zu kalkulieren sind und keine langfristige Bindung entsteht. Als weitere laufende Kosten müssen nur noch der Server und dessen Konnektivität bzw. der dazu gehörige Support-Aufwand berechnet werden. Allerdings drohen auch hier Kostenüberraschungen, wenn nach einem Versionswechsel auch neue Hardware benötigt wird.
Closed-Source Abo (Cloud/SaaS)	Noch einen Schritt weiter gehen Cloud- bzw. SaaS-Lösungen (Software as a Service). Im monatlichen Mietpreis ist nicht nur die Software-Lizenz, Service und Wartung enthalten, sondern auch noch der Server, Hosting, Traffic und Load-Management. Die hohen laufenden Kosten relativieren sich durch die hohen Inklusivleistungen und die einfache Kalkulation.

Die Übersicht zeigt: Es ist gar nicht so einfach, einen validen Kostenvergleich zwischen Kauf-, Miet- und Cloud-Lösung anzustellen. Für eine faire Gegenüberstellung müssen die gesamten Ausgaben für Lizenz, Support, Updates, Hosting, Server (inklusive eventuell fälliger Erweiterungen) und Wartung auf die voraussichtliche Laufzeit umgelegt werden, um sie mit den Kosten einer Cloud-Lösung zu vergleichen.

Dazu kommen immaterielle Unterschiede. Während eine Cloud-Lösung in der Regel flexibel erweitert oder reduziert werden kann, legt sich der Anwender beim Kauf auf eine bestimmte Ausbaustufe fest und bleibt relativ starr. Außerdem hat er relativ hohe Anfangsinvestitionen zu tragen, während der Cloud-Anwender mehr freies Kapital für seine Wachstumsstrategie behält.

Insbesondere letztere Argumente verstehen viele Gründer sofort, sodass inzwischen fast alle Business-Anbieter in einer Cloud-Variante angeboten werden und dieses Lizenzmodell zu einem der beliebtesten überhaupt geworden ist. Genau genommen ist die Cloud-Lizenz deswegen aber auch besonders schwer mit herkömmlichen Lizenzmodellen zu vergleichen. Es handelt sich schlicht um eine erweiterte Dienstleistung, die viel mehr als nur ein bestimmtes Lizenzmodell umfasst. Dies zeigt sich besonders deutlich bei einem Vergleich der Software Magento, die sowohl in einer herkömmlichen (Open-Source-) Lizenz und im Cloud-Modell erhältlich ist. Das Cloud-Bundle enthält neben der obligatorischen Magento-Lizenz mit 24/7-Support-Vertrag folgende Elemente:

• Ein Content Delivery Network (CDN) des Anbieters Fastly  ,
  
• Performance Management Tools von New Relic   und blackfire.io  
  
• Magento Commerce    (ehemals Magento Enterprise Edition)
  
• eine Platform as a Service (PaaS)-Lösung von Platform.sh  
• die die Cloud-Infrastruktur von Amazon Web Services   (AWS) nutzt.

Angefangen vom CDN - das dafür sorgt, dass statische und gecachte Inhalte gar nicht erst vom Shop-Server abgerufen werden müssen - bis zu den AWS - die mittels eines 3-Server-Cluster Redundanz und Sicherheit herstellen - kauft der Kunde mit dem Cloud-Dienst eher einen kompletten Fire-and-Forget-Service, der hohe Performance und Skalierbarkeit sicherstellt, als eine Shop-Lizenz.

Hier lauern die Kosten-Fallen

Aber selbst wer sich für ein Modell des Software-Erwerbs entschieden hat, sollte beim konkreten Vertrag genau hinschauen. Im Kleingedruckten lauern oft Kostenfallen, die auf den ersten Blick leicht übersehen werden. Denn in den seltensten Fälle handelt es sich bei Lizenzgebühren um einfache, eindimensionale Kosten, die sich nur an der Zeit bemessen. Fast immer kommen weitere leistungsabhängige Komponenten hinzu. Einerseits verständlich, wenn das Shopsystem flexibel und skalierbar arbeiten soll und der Hersteller auch das Hosting bereitstellt. Andererseits schwer abzuschätzen, gerade wenn der Shop noch am Anfang seiner Entwicklung steht.

Gängige Varianten sind:

• Traffic: Hier wird ein bestimmter Webseiten-Verkehr eingeräumt. Beim Überschreiten einer bestimmten Grenze werden weitere Gebühren fällig.
  
• Arbeitsplatz-Lizenz: Bei diesem Modell darf nur eine bestimmte Zahl von Mitarbeitern auf die Software zugreifen. Zwei Varianten stehen zur Wahl: Bei Einzelplatzlizenzen ist die tatsächliche Zahl der Arbeitsplätze beschränkt, beim etwas flexibleren Concurrent User-Model die Anzahl der gleichzeitigen Log-ins.
  
• Erfolgsbeteiligung: Dieses Modell ist für Einsteiger attraktiv, da das finanzielle Risiko gering bleibt. Die Shop-Software wird über eine Umsatzprovision bezahlt. Motto: Steigt der Umsatz, leistet die Software auch mehr.
  
• Serverlast: Im Grunde ähnlich wie beim Traffic-Modell werden hier die Lizenzkosten über die Zahl der eingesetzten Prozessoren oder Server bestimmt. Verteilte Systeme kosten mehr, einfache Rechner kommen günstiger weg.
  
• Artikelstammdaten: Gerade bei kleineren Systemen ist häufig die Anzahl der zu verwaltenden Artikelstammdaten für die Höhe der Lizenzkosten ausschlaggebend. Für kleinere Onlineshops ist dieses Modell besonders transparent.

Kein Modell ohne Nachteil. Viele Shopbetreiber machen sich wenige Gedanken darum, warum sie mit welcher dieser Leistungskomponenten besser fahren. Die Vor und Nachteile in der Übersicht:

Abrechnungsmodell	Vorteil:	Nachteil:
Traffic	Klare, performancerelevante Messgröße. Flexible Zubuchung und Abrechnung möglich. Conversion-Optimierung zahlt sich doppelt aus.	Traffic kann stark schwanken und ist schwer vorherzusagen. Bei großem Shop-Erfolg explodieren die Kosten, Nachverhandlung nötig. Hoher Traffic kann zu Test- oder Marketingzwecken erwünscht sein (Gewinnspiele, Adressgenerierung etc.). Bots und Maschinen erzeugen Traffic. Verschiedene Messverfahren führen zu verschiedenen Ergebnissen.
Arbeitsplätze	Einfache, fest planbare Größe. Fair (skaliert in der Regel mit dem Shoperfolg). Concurrent User Modell gibt (gewisse) Flexibilität. Gibt viele Freiheiten für Marketing-Experimente. Keine Überraschungen bei der Abrechnung.	Unflexibel bei kurzfristigem, spontanem oder unregelmäßigem Bedarf. Einzelplatz-Lizenzen im Cloud-Zeitalter nicht zeitgemäß. Geringe Granularität in der Abrechnung, Erweiterungen müssen gut überlegt sein.
Umsatz	Geringes Risiko, da die Lizenzkosten mit dem Umsatz steigen. Hohe Flexibilität. Bei steigenden Umsätzen skaliert die Leistung automatisch mit. Transparentes Abrechnungsmodell.	Werbung wird doppelt bezahlt: Einmal durch die eigentlichen Marketingkosten, einmal durch den Verkaufserfolg. Shopbetreiber gibt Skaleneffekte ab. Ungünstig für schnell wachsende Geschäftsmodelle. Schwer kalkulierbar, wenn die Produktmargen im Shop schwanken.
Prozessoren/Server	Klare Abrechnungseinheit, hohe Transparenz. Serverlast wächst in der Regel mit dem Geschäftserfolg. Keine Überraschungen bei der Abrechnung.	Schwer skalierbar; Erweiterungen nur in festgelegten Schritten. Unflexibel bei kurzfristigem, spontanem oder unregelmäßigem Bedarf. Performance-Ansprüche liegen nicht immer im Shoperfolg begründet
Artikelanzahl:	Feste, leicht kalkulierbare Abrechnungseinheit. Änderungen gut planbar. Lizenzkosten nicht vom Shoperfolg abhängig.	Unflexibel bei kurzfristigem Bedarf. (Meist) feste Schwellwerte erfordern langfristige Planung bei Expansion. Für manche Geschäftsmodelle aufgrund der Sortimentsgröße ungeeignet.

Besonders kritisch sind Abrechnungsmodelle zu bewerten, die sich nach dem Umsatz richten. Hier besteht die Gefahr, notwendige Marketingmaßnahmen zusätzlich zu verteuern, weil die dadurch erzielten Umsätze zusätzlich mit dem Shopanbieter geteilt werden müssen. Dadurch gerät die Wirtschaftlichkeit in Gefahr. Zudem verzichtet der Händler auf die - im Handelsgeschäft ohnehin geringen - Skaleneffekte, die entstehen, wenn bei gleichbleibenden Grundkosten die Umsätze steigen. Denn: Bei der Umsatzprovisionierung gibt es keine gleichbleibenden Grundkosten.

Sowohl beim Traffic- als auch beim Umsatzmodell sollten zudem logarithmische Skalen verwendet werden, um eine Kostenexplosion zu vermeiden und die Zahlungen zusätzlich nach oben deckeln. Bei großem Erfolg soll schließlich nicht der Softwarehersteller, sondern der Shopbetreiber reich werden.

Besondere Vorsicht ist zudem geboten, wenn mehrere Abrechnungsmodelle kombiniert sind - insbesondere, wenn sich diese gegenseitig bedingen. Die Kombination aus einem Traffic- und Prozessormodell würde beispielsweise eine doppelte Belastung erzeugen. Denn steigender Traffic führt zwangsläufig zu höherer Serverlast. Es gäbe keinen Grund, diesen zweimal zu berechnen.