Warum Preise pro Seat wachsende Salesforce-Teams bestrafen

Kurze Antwort: Preise pro Seat kosten nicht nur Geld, sie verändern Verhalten. Teams kaufen weniger Seats als sie Menschen haben, Releases laufen über ein oder zwei Power User, und die entstehende Warteschlange kostet mehr, als die Lizenzen je gespart haben. Auf Salesforce trifft das härter als anderswo, weil genau die Leute ausgeschlossen werden, die die Arbeit machen.

Was ist DevOps-Preisgestaltung pro Seat, und warum ist sie Standard?

Pro Seat heißt: Sie zahlen je benanntem Nutzer mit Zugriff. Das ist der Standard in der Entwicklerwerkzeugwelt, weil er sich leicht planen lässt und der Umsatz mit der Mitarbeiterzahl wächst. Die Schwäche ist gut dokumentiert: Die Kosten skalieren mit der Teamgröße statt mit dem gelieferten Nutzen, und Nutzen folgt selten der Kopfzahl (Schematic).

Im Salesforce DevOps ist diese Schwäche schärfer, denn der Releaseprozess ist keine reine Entwicklertätigkeit. Wer eine Änderung berechtigterweise bewegen können muss:

• Admins, die deklarativ bauen und nie ein Terminal öffnen.
• Beraterinnen und Berater, die in mehreren Kundenorgs arbeiten.
• Tester, die ein Deployment in eine QA-Sandbox brauchen.
• Release Manager, denen der Kalender gehört, aber nicht der Code.
• Product Owner, die schlicht wissen wollen, was im nächsten Release steckt.

Was passiert wirklich, wenn ein Team Seats kauft?

Niemand lizenziert alle. Budget gibt es für die zwei technischsten Personen, alle anderen leiten ihre Anfragen über diese beiden. Danach folgen drei Dinge, in dieser Reihenfolge:

1. Eine Warteschlange entsteht. Deployments warten jetzt auf einen Kalender statt auf Fertigstellung.
2. Wissen konzentriert sich. Die zwei lizenzierten Personen sind die Einzigen, die die Pipeline verstehen. Das ist ein Personalrisiko, lange bevor es ein Kostenproblem ist.
3. Umgehungen kehren zurück. Change Sets und manuelle Änderungen kommen für die "kleinen" Dinge zurück, und die Drift beginnt von vorn.

Das Werkzeug wurde gekauft, um einen Single Point of Failure im Releaseprozess zu beseitigen. Seat-Preise bauen ihn wieder auf und lassen sich dann dafür bezahlen, ihn zu verbreitern.

Was kostet der Engpass tatsächlich?

Rechnen Sie mit Ihren eigenen Gehältern statt mit denen eines Anbieters. Die Form der Rechnung:

• Zählen Sie die Menschen, die ein Release berühren. Entwickler, Admins, Berater, Tester, Release Manager. Acht ist typisch für ein mittleres Salesforce-Team.
• Zählen Sie die Seats, die Sie wirklich kaufen würden. Meist zwei oder drei.
• Bepreisen Sie die Lücke in Zeit, nicht in Lizenzen. Verbringt eine erfahrene Person zwei Tage pro Woche mit fremden Deployments, gehen rund vierzig Prozent eines Seniorgehalts für Warteschlangenverwaltung drauf.
• Addieren Sie die Verzögerung. Jede Änderung, die drei Tage auf ein Deployfenster wartet, sind drei Tage nicht gelieferter Nutzen.

Nebeneinander gelegt laufen Stacks pro Nutzer und Pauschalangebote mit wachsender Teamgröße schnell auseinander (Kostenanalyse von Hyperping). Doch die Lizenzdifferenz ist die kleinere Hälfte des Arguments. Die teure Hälfte ist das Verhalten, das das Preismodell erzeugt.

Warum trifft das wachsende Teams am härtesten?

Drei Multiplikatoren addieren sich:

• Kopfzahl. Jede Einstellung ist eine neue Preisentscheidung, Wachstum wird also zur wiederkehrenden Budgetdebatte darüber, wer deployen darf.
• Anzahl der Orgs. Beratungen und ISVs betreuen mehrere Orgs. Preise, die mit Nutzern und Orgs skalieren, treffen genau die Unternehmen, deren Marge davon abhängt, viele Kunden effizient zu bedienen.
• Fluktuation und Externe. Kurze Einsätze machen benannte Seats administrativ teuer, Externe werden also standardmäßig ausgeschlossen und der Engpass wird enger.

Für ein stabiles Fünferteam funktioniert Seat-Pricing gut. Am schlechtesten funktioniert es bei den wachsenden, gemischten Multi-Org-Teams, die DevOps am dringendsten brauchen.

Worauf sollten Sie stattdessen achten?

• Unbegrenzte Nutzer. Ist Zugriff eine Budgetentscheidung, deckelt die Finanzabteilung die Adoption statt des Bedarfs.
• Preis unabhängig von der Org-Anzahl. Mehr Orgs zu betreuen darf keine Strafe sein.
• Transparente Messung. Pauschaler Zugriff mit Verbrauchsmessung ist ehrlich, solange der Zähler sichtbar und die Einheit erklärbar ist.
• Eine kostenlose Stufe, die eine echte Stufe ist. Kein Countdown bis zum Vertriebsgespräch.

Genau so ist Serpent bepreist. Scale kostet 699 Dollar pro Unternehmen und Monat mit unbegrenzten Nutzern, unabhängig von der Zahl Ihrer Orgs, mit 0 Dollar Einrichtung und monatlicher Laufzeit. Der Verbrauch wird in Credits gemessen (300 pro Monat in Scale, Nachkauf zu 1 Dollar je Credit), der Zähler bleibt also sichtbar, statt sich in einer Seat-Zahl zu verstecken. Essentials ist wirklich kostenlos mit 30 Credits im Monat, ohne Kreditkarte und ohne Zeitlimit, damit das ganze Team ab Tag eins im Werkzeug ist. So bepreist Serpent es.

Wie zehn Salesforce DevOps-Plattformen tatsächlich abrechnen, pro Platz, pro Team oder pro Unternehmen, zeigt unser Vergleich der Salesforce DevOps-Tools.

FAQ

Ist Seat-Pricing immer das falsche Modell?

Nein. Für ein kleines, stabiles Team, in dem jeder Vollzeitnutzer ist, ist es vernünftig. Es altert schlecht, sobald Admins, Tester und Berater am Releaseprozess beteiligt sind.

Ist Pauschalpreis nicht Seat-Pricing mit Zwischenschritten?

Nur wenn der Anbieter die Nutzerzahl im Kleingedruckten deckelt. Ein Pauschalpreis mit echten unbegrenzten Nutzern ändert, wer deployen darf, und genau darum geht es.

Und Credits? Ist das nicht auch nur ein Zähler?

Es ist ein Zähler, und man sollte ihn so nennen. Der Unterschied liegt darin, was gezählt wird: planbarer, sichtbarer Verbrauch statt Kopfzahl, die Zusammenarbeit bestraft.

Wie argumentiere ich das intern?

Präsentieren Sie es nicht als Lizenzvergleich. Zählen Sie die Deployments, die im Kalender einer einzigen Person warten, und setzen Sie eine Gehaltszahl gegen diese Zeit.