Viele Projekte, ein Team: Zugriff und Abrechnung, wenn Lokalisierung über eine App hinauswächst

Die meisten Lokalisierungs-Setups fangen einfach an: eine App, ein Projekt, drei Leute, die sich alle kennen. Nichts in diesem Beitrag trifft darauf zu, und wenn Sie dort stehen, ist der Rest verfrüht.

Es ändert sich mit der zweiten App. Dann kommen ein Mobile-Client, eine Marketing-Website, ein Kundenportal, ein internes Admin-Tool. Jedes davon ist zu Recht ein eigenes Projekt: eigener Release-Rhythmus, eigene Sprachen, eigener Plan. Und irgendwo zwischen dem zweiten und dem fünften hört die Arbeit auf, Übersetzung zu sein, und wird Verwaltung.

Was wirklich bricht, wenn das zweite Projekt auftaucht

Dieselben Einladungen, immer wieder. Acht Kolleginnen und Kollegen, fünf Projekte, vierzig Einladungen, und jede neue Person wiederholt das Ritual. Das ist lästig und nicht gefährlich, und genau deshalb behebt es niemand, bis etwas anderes schiefgeht.

Offboarding wird zum Gedächtnisspiel. Jemand verlässt das Unternehmen oder wechselt in ein Team, das mit dem Portal nichts mehr zu tun hat. Jetzt ist die Frage, zu welchen Projekten diese Person je hinzugefügt wurde. Wenn die Antwort nur in den Benutzerlisten der einzelnen Projekte steht, heißt Zugriff entziehen, sich an jedes existierende Projekt zu erinnern, und der Preis fürs Vergessen ist eine Person, die Monate später noch Ihre Produktivtexte bearbeitet. Das ist der Moment, in dem aus einem Verwaltungsärgernis ein Sicherheitsbefund wird.

Die Rechnung zerfällt. Fünf Projekte, fünf Abonnements, fünf Verlängerungsdaten, fünf Belege zum Abgleichen. Die Buchhaltung fragt, warum ein Unternehmen einen Lokalisierungsanbieter fünfmal bezahlt, und die ehrliche Antwort ist: Das Tool kannte den Begriff Unternehmen nicht.

Externe bekommen mehr Zugriff als beabsichtigt. Die freie Übersetzerin braucht Italienisch auf der Marketing-Website. Der Weg des geringsten Widerstands gibt ihr eine Rolle, die weiter reicht, weil das Einschränken pro Projekt Arbeit ist. Mal jeder Auftragnehmer und jeder Agenturkontakt über ein paar Jahre.

Niemand kann sagen, wer worauf Zugriff hat. Nicht, weil die Daten fehlen, sondern weil sie über N Projekt-Benutzerlisten verteilt sind, ohne eine Stelle, die sie zusammenführt. Wenn diese Frage zum ersten Mal ernsthaft gestellt wird, kommt sie meist von einem Auditor, aus einem Sicherheitsfragebogen eines Kunden oder aus einem Vorfall.

Warum die üblichen Behelfslösungen nicht tragen

Ein großes Projekt mit Namespaces. Verlockend, weil es das Verwaltungsproblem sofort auflöst. Es löst allerdings auch alles auf, wofür Sie die Apps getrennt haben: Ein Namespace ist ein Ausschnitt der Inhalte innerhalb eines Projekts, teilt also dessen Versionen, dessen Publizieren, dessen Plan und dessen Zugriffsregeln. Zwei Produkte, die an verschiedenen Tagen ausgeliefert werden, können sich keinen Release-Rhythmus teilen, und "der Praktikant darf die Marketing-Texte bearbeiten, aber nicht den Checkout" lässt sich in einer Struktur, in der beides Namespaces derselben Sache sind, nicht ausdrücken.

Ein gemeinsamer Login. Er löst das Einladungsproblem, indem er die Nachvollziehbarkeit zerstört, macht Zwei-Faktor-Authentifizierung sinnlos und verwandelt jedes Offboarding in eine Passwortrotation. Er kommt häufiger vor, als irgendjemand zugibt.

Eine Tabelle, wer was hat. Korrekt an dem Tag, an dem sie geschrieben wird. In dem Moment, in dem irgendwo Zugriff vergeben wird, ohne dass die Tabelle nachgeführt wird, ist sie schlechter als nichts, denn jetzt ist sie ein Dokument, das etwas Falsches selbstbewusst behauptet.

Wie die Struktur aussehen sollte

Das Muster, das trägt, ist eine Konto-Ebene über den Projekten, die die beiden Dinge besitzt, die Tatsachen über das Unternehmen sind und nicht über eine App: die Leute und die Rechnung. Vier Eigenschaften machen es aus.

Ein Team, vererbt in jedes Projekt. Sie laden eine Kollegin einmal auf dem Konto ein, mit der Rolle, die sie unternehmensweit haben soll. Sie erscheint in jedem Projekt dieses Kontos mit dieser Rolle. An einer Stelle vergeben, an einer Stelle entziehen. Das macht Offboarding zu einer einzigen Handlung statt zu einer Suche.

Zwei Arten von Rollen, und nur eine davon wird blind vererbt. Rollen, die das Konto führen (Verwaltung und Abrechnung), gehören zum Konto und reichen per Definition überall hin. Die Arbeitsrollen (verwalten, publizieren, übersetzen) werden ebenfalls vererbt, aber ein Projekt muss sagen können: "diese Person hier nicht". Also auf diesem Projekt auf eine Sprache einschränken oder ganz sperren. Ohne dieses Übersteuern ist ein vererbtes Team zu grob, und Teams kehren zu Einladungen pro Projekt zurück.

Externe bleiben beim Projekt. Das Konto-Team ist für Ihre eigenen Leute. Eine freie Übersetzerin oder ein Agenturkontakt bekommt eine Berechtigung auf genau dem Projekt, an dem sie arbeiten, und erfährt nie, dass der Rest des Kontos existiert. Diese eine Regel hält die Vererbung sicher: Alles im Konto-Team ist bewusst unternehmensweit, also steht alles, was nicht unternehmensweit sein darf, gar nicht erst darin.

Ein Konto, ein Abonnement, eine Rechnung. Jedes Projekt rechnet in seinem Konto ab. Wenn eine Abteilung wirklich eine eigene Rechnung, eine eigene Zahlungsart oder einen eigenen Personenkreis braucht, dann ist diese Abteilung ein zweites Konto und kein Sonderfall innerhalb des ersten. Der Versuch, zwei Rechnungen in einem Konto auszudrücken, ist der Punkt, an dem solche Modelle üblicherweise zu etwas werden, das niemand mehr durchdenken kann.

Darüber hinaus ergeben ein paar Dinge nur auf Konto-Ebene Sinn: Single Sign-on (ein Identity Provider ist eine Tatsache über das Unternehmen, nicht über eine App), erzwungene Zwei-Faktor-Authentifizierung und ein Audit-Log darüber, wem was gegeben und entzogen wurde. Das pro Projekt zu konfigurieren, ist Fleißarbeit und ein sicherer Weg zu fünf unterschiedlichen Sicherheitsniveaus in einem Unternehmen.

Wie das in Locize funktioniert

Das ist die Form von Organisationen in Locize und der Grund, warum wir sie gebaut haben.

Ihre Organisation ist die Konto-Ebene. Sie bekommen sie automatisch mit Ihrem ersten Projekt, benannt nach Ihrem Unternehmen, und können sie jederzeit umbenennen. Alles oben Beschriebene ist ihr Verhalten:

• Das Team lebt auf der Organisationsseite. Mitglieder werden einmal eingeladen und erben in jedes Projekt, mit einem "via organization"-Badge in der Benutzerliste jedes Projekts, damit Sie vererbten von direktem Zugriff immer unterscheiden können. Eine direkte Projektberechtigung gewinnt bei den Arbeitsrollen, Sie können jemanden also auf einem einzelnen Projekt einschränken oder sperren, und "inherit" gibt ihn wieder an die Regel der Organisation zurück. Details in der Benutzerverwaltung.
• Admin und Accountant gibt es nur auf der Organisation. Projektberechtigungen enden beim Manager. Das ist es, was die Offboarding-Geschichte wahr macht: Es gibt keinen Weg, unternehmensweite Macht Projekt für Projekt anzusammeln.
• Die Abrechnung gehört der Organisation. Das erste Projekt, das ein Abonnement abschließt, erstellt es, und jedes weitere Projekt tritt bei: eine Rechnung, während jedes Projekt seinen eigenen Plan und seine eigenen Limits behält. Eine gemeinsame Rechnung ist ab dem Growth-Plan enthalten.
• Eine eigene Rechnung ist eine eigene Organisation. Sie können sie direkt im Formular zum Anlegen eines Projekts erstellen, und ein bestehendes Projekt mit einem einmaligen Übergabecode verschieben: Der empfangende Admin sieht vor dem Bestätigen, welches Projekt ankommt und von wem. Tenants und Branches folgen ihrem Elternprojekt automatisch (Multi-Tenant).
• SSO wird einmal pro Abonnement berechnet, unabhängig davon, wie viele Projekte es nutzen. Erzwungene Zwei-Faktor-Authentifizierung wird für die ganze Organisation gesetzt, und ein Projekt kann sie verschärfen, aber nie abschwächen. Organisations-Admins können das Audit-Log der Mitglieder- und Einladungsänderungen herunterladen, in Plänen, die es enthalten.

Wenn Sie bereits Collective Billing genutzt haben, hat nichts davon etwas von Ihnen verlangt: Ihre Abrechnungsgruppe wurde zu Ihrer Organisation, ihre Admins wurden Organisations-Admins, alle behielten die Projekte, die sie hatten, und die Rechnung blieb gleich oder wurde leicht günstiger, da SSO jetzt einmal pro Abonnement statt einmal pro Projekt berechnet wird.

Wann Sie nichts davon brauchen

Eine App, ein oder zwei Personen, keine externen Übersetzer, keine Compliance-Fragen: Lassen Sie es. Ein einzelnes Projekt mit ein paar direkten Berechtigungen ist die richtige Struktur, und eine Konto-Ebene darüber bringt Ihnen nichts. Die Signale, dass es so weit ist, sind konkret und Sie werden sie erkennen: das dritte Projekt, die erste Person, die aus mehreren Projekten gleichzeitig entfernt werden muss, die erste Rechnungsfrage aus der Buchhaltung, der erste Sicherheitsfragebogen, der fragt, wie Zugriff vergeben und entzogen wird, oder der erste Auftragnehmer, dem Sie mehr Zugriff geben mussten, als Sie wollten.

Der Sinn der Konto-Ebene ist nicht, dass sie Ihre Übersetzungen verwaltet. Er ist, dass sie verhindert, dass die Verwaltung drumherum mit jedem Produkt mitwächst, das Sie ausliefern.

Wenn Ihnen mehrere dieser Signale bekannt vorkommen, sehen Sie die Struktur am schnellsten an Ihrem eigenen Setup: Die Organisationsseite listet jedes Projekt, wer darauf zugreift und was es diese Periode kostet. Kostenlos mit Locize starten, oder lesen Sie zuerst die Dokumentation zu Organisationen, wenn Sie das Modell vor dem Produkt sehen möchten.