Einen gibt keinen universellen Blueprint für die SaaS-Organisation
Viele Gespräche beginnen ähnlich. Jemand hat wochenlang recherchiert, Frameworks verglichen und Rollenmodelle studiert. An Ansätzen mangelt es nicht. Doch ein Modell, das sich direkt auf das eigene Unternehmen übertragen lässt, findet sich selten.
Das liegt nicht an fehlender Recherche. Gerade für kleinere Softwarehersteller sind viele Frameworks zu umfangreich und setzen Strukturen voraus, die es im Unternehmen gar nicht gibt. Einzelne Rollendefinitionen können hilfreich sein. Wie die Verantwortlichkeiten sinnvoll verteilt werden, hängt jedoch von der jeweiligen Organisation ab.
In unseren Mandaten begegnen uns immer wieder ähnliche Herausforderungen. Daraus haben wir fünf Erkenntnisse gewonnen, die zeigen, worauf es beim Aufbau und bei der Weiterentwicklung eines SaaS-Betriebs ankommt.
1. Produktverantwortung muss den Betrieb mitdenken
Ein häufiger Befund in unseren Mandaten: Es gibt jemanden, der bestimmt, was ins Produkt kommt. Es gibt jemanden, der bestimmt, wie es gebaut wird. Was oft fehlt, ist eine klare Verantwortung dafür, dass der Dienst im Alltag verfügbar, schnell und sicher ist.
Diese Lücke zeigt sich in der Priorisierung: Während sich jemand für neue Funktionen einsetzt, fehlt diese Unterstützung bei der Servicequalität. Verfügbarkeit, Wartbarkeit, Performance und Sicherheit werden deshalb zugunsten neuer Kundenfunktionen zurückgestellt.
Die naheliegende Antwort ist, eine zusätzliche Rolle zu schaffen: einen Service Owner. Wir raten meist davon ab. Wer den Betrieb verantwortet, aber nicht über Prioritäten entscheiden darf, muss sich gegenüber der Produktverantwortung durchsetzen. Das gelingt selten, wenn auf der anderen Seite ein Neukunde auf eine zugesagte Funktion wartet.
Wirksamer ist aus unserer Erfahrung, die Verantwortung für den Betrieb direkt mit der Produktverantwortung zu verbinden. Wer über die Weiterentwicklung entscheidet, muss auch mit den Beschwerden der Kunden über Störungen konfrontiert sein. So erhalten Verfügbarkeit und Zuverlässigkeit mehr Gewicht. Damit wächst auch der Anreiz, das Produkt zu vereinfachen, statt es mit jeder neuen Funktion komplexer zu machen.
2. Entwicklung und Betrieb gehören zusammen
Eine Entwicklungsabteilung, eine Betriebsabteilung, zwei Budgets. Das wirkt klar organisiert, schafft aber Reibungsverluste. Wer die Software entwickelt, bekommt die Folgen von Fehlern im Betrieb oft nur am Rande mit. Wer die Störungen behebt, kann deren Ursachen wiederum häufig nicht selbst beseitigen.
In einem unserer Mandate haben wir diese Trennung aufgelöst: ein Team, ein Budget, dieselben Leute für Entwicklung und Betrieb. Die Qualität verbesserte sich, weil das Team die Auswirkungen seiner Entscheidungen selbst erlebte. Wer nachts eine Störung beheben muss, hat einen konkreten Anreiz, die Ursache dauerhaft zu beseitigen und denselben Fehler künftig zu vermeiden.
Damit aus dieser Erfahrung eine Verbesserung entsteht, muss der Betrieb fest im Entwicklungsprozess verankert sein. Probleme aus dem laufenden Betrieb gehören als Anforderungen in den nächsten Entwicklungszyklus und müssen bei der Priorisierung ebenso ernst genommen werden wie neue Kundenwünsche.
3. Das Standardprodukt im Blick behalten
Kundenspezifische Ausnahmen verursachen nicht nur bei der Entwicklung Aufwand. Sie müssen auch bei späteren Releases, beim Testen und im Support berücksichtigt werden. Deshalb gilt es schon bei der Aufnahme von Anforderungen abzuwägen, welche Anpassungen sinnvoll sind und wo der gemeinsame Produktstandard Vorrang hat.
Bei einigen hundert Kunden kommen schnell ebenso viele unterschiedliche Konfigurationen zusammen. Damit wächst die Komplexität: Längst ist nicht mehr klar, wie jeder Kunde das Produkt eingestellt hat und ob ein neues Release in allen Varianten zuverlässig funktioniert.
Hier bietet das SaaS-Modell einen wichtigen Vorteil: Durch den zentralen Betrieb können Hersteller die genutzten Konfigurationen besser überblicken. Das hilft ihnen zu erkennen, welche Varianten gebraucht werden und welche Einstellungen sich vereinheitlichen lassen. Wer diese Erkenntnisse nutzt, kann das Produkt gezielt vereinfachen und den Aufwand für Tests, Wartung und Support reduzieren.
4. Produktentwicklung und Kundenrollout brauchen einen gemeinsamen Plan
Die Einführung bei einem grossen Kunden ist Projektarbeit. Eine Projektleitung koordiniert dabei Migration, Schulungen, Termine und Kundenkommunikation. Welche Funktionen ins Produkt kommen und wann sie umgesetzt werden, entscheidet weiterhin die Produktverantwortung.
Diese Aufgabenteilung braucht eine enge Abstimmung. Ein zugesagter Rollout-Termin darf die Produktpriorisierung nicht automatisch bestimmen. Umgekehrt muss die Produktverantwortung wissen, welche Funktionen der Kunde für die Einführung benötigt und welche Folgen eine Verzögerung hätte.
Dafür gleichen Projektleitung und Produktverantwortung Roadmap und Rollout-Plan regelmässig ab. Zwei Fragen stehen dabei im Mittelpunkt: Sind die benötigten Funktionen verfügbar, wenn der erste Kunde sie braucht? Und ist der Rollout-Termin angesichts der noch offenen Arbeiten realistisch?
Aus dieser Abstimmung entstehen Entscheidungen, die sonst offenbleiben: eine Funktion schrittweise ausbauen, eine Kundengruppe später einführen oder den Umfang bewusst reduzieren. Die Produktverantwortung entscheidet, die Projektleitung bringt die Anforderungen und Möglichkeiten beim Kunden ein. Gemeinsam entsteht ein Plan, der hält.
5. Support ersetzt keine aktive Kundenkommunikation
Ein Missverständnis, das sich hartnäckig hält: Sobald der Support steht, ist die Kundenkommunikation geregelt. Doch der Support ist zunächst die Anlaufstelle für Fragen und Probleme. Damit ist noch nicht sichergestellt, dass Kunden rechtzeitig erfahren, was sich im nächsten Release ändert.
Ein gut organisierter Support bearbeitet den grössten Teil der Anfragen im ersten und zweiten Level. Fälle, die eine Produktentscheidung erfordern, werden an die Produktverantwortung weitergegeben. Auch wiederkehrende Fragen können zeigen, wo das Produkt verbessert werden muss. Dafür braucht es einen klaren Weg vom Support in die Priorisierung. Sonst versickern wertvolle Erkenntnisse im Ticket.
Die Kommunikation über Veränderungen muss dagegen aktiv und vor dem Release erfolgen: Was kommt neu hinzu? Was ändert sich für die Anwender? Und was müssen Kunden vorbereiten? Wer erst nach der Veröffentlichung informiert, verursacht vermeidbare Rückfragen und zusätzlichen Supportaufwand.
Bewährt hat sich dabei, Schlüsselanwender beim Kunden gezielt zu informieren und zu befähigen. Sie können Neuerungen intern weitergeben und ihre Kolleginnen und Kollegen unterstützen. Der Hersteller stellt verständliche Produktinformationen und Dokumentationen bereit, der Kunde übernimmt die Schulung seiner Mitarbeitenden.
Gemeinsam prüfen wir, wo Ihre Organisation heute steht, wo Abläufe und Zuständigkeiten verbessert werden können und welche nächsten Schritte den grössten Nutzen bringen.
Der grösste Hebel ist der Billigste
In diversen Reorganisationsmandaten haben wir gemeinsam mit den Kunden die Ursachen in verschiedenen Bereichen untersucht: Menschen, Methoden, Technik und Rahmenbedingungen. Anschliessend haben wir die daraus abgeleiteten Massnahmen nach Wirkung und Aufwand bewertet.
Dabei zeigte sich immer wieder, dass Wissen allein nicht reicht. Die Verbesserungsideen liegen oft längst auf dem Tisch. Was fehlt, ist die Durchsetzung. Zu viele Baustellen laufen gleichzeitig, der Fortschritt bleibt unklar und das Tagesgeschäft beansprucht alle Kapazitäten.
Erkenntnisse im eigenen SaaS-Alltag
Den Anspruch, Erkenntnisse konsequent umzusetzen, stellen wir auch an uns selbst. Mit der XWare Pulse AG haben wir eine eigene SaaS-Firma gegründet und stellen unsere Empfehlungen in der Praxis auf die Probe. Dabei begegnen uns dieselben Fragen und Zielkonflikte wie in unseren Beratungsmandaten. Diesmal auf eigene Rechnung und mit eigener unternehmerischer Verantwortung.
Sie möchten Ihre Organisation auf den SaaS-Betrieb ausrichten oder bestehende Abläufe verbessern? Gerne unterstützen wir Sie dabei, Verantwortlichkeiten zu klären, Prioritäten festzulegen und konkrete Verbesserungen umzusetzen.
