Confluence hat 25 Nutzer. Die App darf plötzlich 100 zählen

Zusammenfassung

• Atlassian beschreibt eine Confluence-App für 25 Nutzer, die nach dem Wechsel in eine Teamwork Collection auf derselben Site mit 100 Jira-Nutzern den Preis für 100 erhält.
• Die Collection zählt eine Person innerhalb der enthaltenen Produkte nur einmal. Marketplace-Apps behalten ihre eigene Lizenzlogik; deren Abrechnungsbasis kann gleichzeitig wachsen.
• Instanzbezogene Lizenzen, organisationsweite Mehrinstanz-Verträge und das frühe Forge-Modell für Nutzer mit erteiltem Zugriff lösen unterschiedliche Probleme. Käufer brauchen das tatsächlich verfügbare Modell und ein konkretes Angebot.

Eine Einkaufsabteilung kann Software zusammenlegen und dabei neue Kunden für einen Lieferanten schaffen: ihre eigenen Beschäftigten, die dessen Werkzeug bisher gar nicht brauchten.

Atlassian liefert dafür ein bemerkenswert nüchternes Beispiel. Eine Marketplace-App hängt an einer Confluence-Cloud-Subscription mit 25 Nutzern. Diese wechselt in die Teamwork Collection. Auf derselben Site gibt es 100 Jira-Nutzer. Die App erhält nun den Preis für 100 Nutzer, erklärt die offizielle Abrechnungsdokumentation.

Der gezählte Personenkreis vervierfacht sich. Wie viel Geld daraus wird, bestimmen die Preistabelle der App, Mengenstaffeln und Rabatte. Der Beschaffungsfehler wäre, diese Rechnung erst nach der Bestellung des Pakets aufzumachen.

Denn die App muss für diesen Sprung keine zusätzliche Aufgabe übernehmen. Ihr geschäftlicher Anschluss hat sich verändert. Ein kleines Werkzeug zieht in ein größeres Haus, und an der Kasse wird die Hausgemeinschaft begrüßt.

Das Paket spart Zählungen und erweitert zugleich den Kreis

Die Collection-Regeln zählen Personen, die Zugriff auf mindestens eines der enthaltenen Produkte haben. Dieselbe Person wird über mehrere dieser Produkte hinweg einmal gezählt. Die enthaltenen Produkte erscheinen unter einer Collection-Subscription auf der Rechnung.

Das ist ein verständliches Verkaufsargument. Wer in Jira arbeitet und Confluence verwendet, soll innerhalb dieser Zählung eine Person bleiben. Ein Paket kann zudem die Beschaffung vereinfachen. Weniger einzelne Bestellungen und eine gebündelte Rechnungsposition haben einen organisatorischen Wert.

Die bestehende Marketplace-App fährt allerdings mit einem eigenen Fahrschein mit. Ihre Lizenz ist an das Produkt gebunden, auf dem sie installiert wurde. Atlassian weist ausdrücklich darauf hin, dass ein Wechsel in eine Collection den Preis beeinflussen kann.

Beide Vorgänge passen nebeneinander: Das Paket beseitigt Mehrfachzählungen innerhalb seiner Produkte, während eine Drittanbieter-App eine größere Bevölkerung erreicht. Die erste Rechnung beantwortet, wie oft der Kunde dieselbe Person für die enthaltenen Produkte bezahlt. Die zweite legt fest, welche Personen zur Lizenz eines zusätzlichen Werkzeugs gehören.

Ein überzeugendes Angebot für die Collection kann deshalb eine unvollständige Kalkulation für den gesamten Umzug sein. Die kleinen App-Verträge verschwinden nicht dadurch, dass der große Produktvertrag eleganter aussieht. Sie müssen mit ihrem künftigen Nutzerkreis danebenliegen.

Für den Fachbereich entsteht eine besonders ungemütliche Diskussion. Er hat möglicherweise weiterhin dieselbe Aufgabe und denselben Bedarf. Die Entscheidung über die Größe der gemeinsamen Umgebung fällt an anderer Stelle. Auf seinem Werkzeug landet anschließend ein größerer Kreis abrechenbarer Personen. Wer die Umgebung gestaltet, verändert damit die Wirtschaftlichkeit eines fremden Budgets.

Das Werkzeug verkauft eine Reichweite

Die Forge-Lizenzübersicht beschreibt das Standardmodell ohne große Umschweife: Abgerechnet werden sämtliche Nutzer der Host-Instanz, unabhängig davon, wie viele die App tatsächlich benutzen.

Das dortige Rechenbeispiel setzt 500 Jira-Nutzer, 50 tatsächliche App-Nutzer und einen beispielhaften Preis von zwei Dollar pro Person und Monat an. Das Ergebnis lautet 1.000 Dollar. Die Dokumentation veranschaulicht damit die Lizenzbasis: 500 mal zwei, obwohl nur 50 mit dem Werkzeug arbeiten.

Der Verkäufer bietet dem Kunden also eine Berechtigung für eine bestimmte Umgebung an. Der Käufer begründet den Nutzen oft mit einer viel kleineren Gruppe. Für ein Spezialwerkzeug ist diese Differenz entscheidend. Eine App kann den Arbeitsablauf von 50 Menschen erheblich verbessern und dennoch schwer zu beschaffen sein, wenn ihr Vertrag die übrigen 450 einbezieht.

Auch die Nutzerzahl mehrerer Jira-Produkte wird nach einer konkreten Regel ermittelt. Atlassians Beispiel mit 100 Jira-Nutzern und 80 Jira Service Management-Agenten verwendet die größere Zahl: 100. Wird die Jira-Subscription mit 100 Nutzern deaktiviert, gilt ab dem nächsten Abrechnungszyklus der Preis für die verbleibenden 80. Die Regel zählt hier weder 180 zusammen noch die aktiven Nutzer der Marketplace-App.

Für den Einkauf ist das eine Aufforderung zu präzisen Substantiven. „Nutzer“ kann die Person mit Produktzugriff, die Bevölkerung einer Instanz, eine innerhalb der Collection deduplizierte Person oder eine Person mit erteiltem App-Zugriff bezeichnen. Dieselbe Spaltenüberschrift in zwei Angeboten garantiert noch keine vergleichbaren Mengen.

Der Abrechnungszyklus einer Marketplace-App folgt zudem dem zugehörigen Produkt. Die organisatorische Trennung zwischen dem großen Plattformkauf und dem kleinen Zusatzwerkzeug spiegelt sich deshalb nicht unbedingt in getrennten kommerziellen Entscheidungsterminen wider. Wer das Produktpaket umstellt, sollte die App-Lizenzen bereits auf dem Tisch haben.

Ein kleinerer Kreis braucht ein verkäufliches Modell

Atlassian beschreibt für Forge auch ein nutzerbezogenes Modell. Gezählt werden dabei Personen, denen Zugriff auf die App erteilt wurde. Der reizvolle Gedanke: Der kleine Fachbereich kann innerhalb einer großen gemeinsamen Umgebung einen kleineren kommerziellen Kreis bilden.

Die Anleitung zur Einführung trägt allerdings einen konkreten Entwicklungsstand. Der dokumentierte Early Access ermöglicht Aufbau, Bereitstellung und Tests in Nichtproduktionsumgebungen über die Forge CLI. Veröffentlichung im Marketplace, Preiseinrichtung, Preisänderungen und Freigabe werden als spätere Erweiterungen des Programms aufgeführt.

Die Seite enthält zugleich Voraussetzungen für bereits veröffentlichte Apps und Text zur Umstellung von Bestandskunden. Wer darüber einkauft, muss diese gemischte Dokumentation in eine eindeutige Antwort des Anbieters übersetzen: Welches Modell verkauft er für genau diese App und genau diesen Kunden heute?

Eine Zugriffsgruppe allein eröffnet noch keinen neuen Tarif. Der Partner muss das Modell übernehmen; pro App ist ein Abrechnungsmodell vorgesehen. Er kann dabei auch seine Preise ändern. Bestehende Kunden folgen dem Modellwechsel der App. Connect-Apps müssen zunächst Forge übernehmen, um diesen Weg nutzen zu können.

Darin liegt der wirtschaftliche Haken einer technisch hübschen Lösung. Ein kleinerer gezählter Kreis erlaubt eine andere Preisgestaltung. Aus 50 Berechtigten wird nicht automatisch die alte Rechnung geteilt durch zehn. Der Anbieter verkauft weiterhin den Wert seines Werkzeugs und legt dafür einen Preis fest.

Auch das Wort „nutzerbezogen“ verdient einen nüchternen Blick. Die vorgesehene Zählung richtet sich nach erteiltem Zugriff. Wer die App einen Monat lang nicht öffnet, ist damit noch nicht aus ihrem berechtigten Kreis herausgefallen. Eine Einkaufskalkulation auf Basis von Klicks würde wieder die falschen Menschen zählen.

Zwei Instanzen sind eine weitere Grenze

Für Enterprise-Kunden kommt eine zweite Achse hinzu: die Verteilung auf Instanzen. Atlassians Enterprise-Abrechnung verwendet das fiktive Unternehmen Acme mit 8.000 Jira-Nutzern, aufgeteilt auf Instanzen mit 5.000 und 3.000. Wird eine instanzbezogen lizenzierte App auf der ersten installiert, gilt die Stufe für 5.000.

Das Beispiel macht eine Verwaltungsentscheidung kommerziell sichtbar. Die Installation auf einer bestimmten Instanz setzt die Lizenzgrenze. Aus dem unternehmensweiten Jira-Vertrag allein lässt sich die App-Menge daher nicht ablesen.

Daneben gibt es für Cloud Enterprise einen Mehrinstanz-Vertrag für Marketplace-Apps. Er fasst App-Instanzen unter einer Organisations-Subscription zusammen und zählt dieselbe Person über mehrere Instanzen hinweg einmal. Zu Beginn wird eine Nutzerstufe ausgewählt. Installiert werden muss die App weiterhin auf jeder betroffenen Instanz.

Diese Deduplizierung löst die Überschneidung zwischen Instanzen. Die gezielte Vergabe von App-Zugriff löst dagegen die Auswahl innerhalb einer Instanz. Beides kann für denselben Käufer interessant sein, aber die Verfahren beantworten verschiedene Fragen.

Die Mehrinstanz-Dokumentation formuliert außerdem, dass alle Apps dieses Modell anbieten werden. Für eine Beschaffung zählt das Angebot des konkreten Partners. Eine angekündigte Breite des Marktplatzes ersetzt keine bestellbare Lizenz.

Damit wird die eigentliche Verhandlung sichtbar. Der Kunde kauft Funktionen, zugleich aber einen geografisch unsichtbaren Umfang: diese Site, jene Instanz, diese Menge berechtigter Personen, jene organisationsweite Gruppe. Die Grenze gehört ins Angebot. Sonst verhandelt der Einkauf den Preis, während jemand anders die Menge festlegt.