Warum Preise pro Seat wachsende Salesforce-Teams bestrafen

Kurze Antwort: Preise pro Seat kosten nicht nur Geld, sie veraendern Verhalten. Teams kaufen weniger Seats als sie Menschen haben, Releases laufen ueber ein oder zwei Power User, und die entstehende Warteschlange kostet mehr, als die Lizenzen je gespart haben. Auf Salesforce trifft das haerter 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 heisst: Sie zahlen je benanntem Nutzer mit Zugriff. Das ist der Standard in der Entwicklerwerkzeugwelt, weil er sich leicht planen laesst und der Umsatz mit der Mitarbeiterzahl waechst. Die Schwaeche ist gut dokumentiert: Die Kosten skalieren mit der Teamgroesse statt mit dem gelieferten Nutzen, und Nutzen folgt selten der Kopfzahl (Schematic).

Im Salesforce DevOps ist diese Schwaeche schaerfer, denn der Releaseprozess ist keine reine Entwicklertaetigkeit. Wer eine Aenderung berechtigterweise bewegen koennen muss:

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

Was passiert wirklich, wenn ein Team Seats kauft?

Niemand lizenziert alle. Budget gibt es fuer die zwei technischsten Personen, alle anderen leiten ihre Anfragen ueber 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 zurueck. Change Sets und manuelle Aenderungen kommen fuer die "kleinen" Dinge zurueck, 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 dafuer bezahlen, ihn zu verbreitern.

Was kostet der Engpass tatsaechlich?

Rechnen Sie mit Ihren eigenen Gehaeltern statt mit denen eines Anbieters. Die Form der Rechnung:

• Zaehlen Sie die Menschen, die ein Release beruehren. Entwickler, Admins, Berater, Tester, Release Manager. Acht ist typisch fuer ein mittleres Salesforce-Team.
• Zaehlen Sie die Seats, die Sie wirklich kaufen wuerden. Meist zwei oder drei.
• Bepreisen Sie die Luecke in Zeit, nicht in Lizenzen. Verbringt eine erfahrene Person zwei Tage pro Woche mit fremden Deployments, gehen rund vierzig Prozent eines Seniorgehalts fuer Warteschlangenverwaltung drauf.
• Addieren Sie die Verzoegerung. Jede Aenderung, die drei Tage auf ein Deployfenster wartet, sind drei Tage nicht gelieferter Nutzen.

Nebeneinander gelegt laufen Stacks pro Nutzer und Pauschalangebote mit wachsender Teamgroesse schnell auseinander (Kostenanalyse von Hyperping). Doch die Lizenzdifferenz ist die kleinere Haelfte des Arguments. Die teure Haelfte ist das Verhalten, das das Preismodell erzeugt.

Warum trifft das wachsende Teams am haertesten?

Drei Multiplikatoren addieren sich:

• Kopfzahl. Jede Einstellung ist eine neue Preisentscheidung, Wachstum wird also zur wiederkehrenden Budgetdebatte darueber, 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 abhaengt, viele Kunden effizient zu bedienen.
• Fluktuation und Externe. Kurze Einsaetze machen benannte Seats administrativ teuer, Externe werden also standardmaessig ausgeschlossen und der Engpass wird enger.

Fuer ein stabiles Fuenferteam 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 unabhaengig von der Org-Anzahl. Mehr Orgs zu betreuen darf keine Strafe sein.
• Transparente Messung. Pauschaler Zugriff mit Verbrauchsmessung ist ehrlich, solange der Zaehler sichtbar und die Einheit erklaerbar ist.
• Eine kostenlose Stufe, die eine echte Stufe ist. Kein Countdown bis zum Vertriebsgespraech.

Genau so ist Serpent bepreist. Scale kostet 699 Dollar pro Unternehmen und Monat mit unbegrenzten Nutzern, unabhaengig 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 Zaehler 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.

FAQ

Ist Seat-Pricing immer das falsche Modell?

Nein. Fuer ein kleines, stabiles Team, in dem jeder Vollzeitnutzer ist, ist es vernuenftig. 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 aendert, wer deployen darf, und genau darum geht es.

Und Credits? Ist das nicht auch nur ein Zaehler?

Es ist ein Zaehler, und man sollte ihn so nennen. Der Unterschied liegt darin, was gezaehlt wird: planbarer, sichtbarer Verbrauch statt Kopfzahl, die Zusammenarbeit bestraft.

Wie argumentiere ich das intern?

Praesentieren Sie es nicht als Lizenzvergleich. Zaehlen Sie die Deployments, die im Kalender einer einzigen Person warten, und setzen Sie eine Gehaltszahl gegen diese Zeit.