SaaS einführen: Projektplan, Meilensteine und Verantwortlichkeiten

SaaS einführen heisst nicht Software entwickeln

SaaS steht für Software as a Service: Die Anwendung läuft in der Cloud und wird über das Internet bereitgestellt; der Zugriff erfolgt über den Browser oder eine App. Eine Installation auf dem eigenen Rechner oder Server entfällt. Bezahlt wird in der Regel im Abo, monatlich oder jährlich. Updates, Sicherheitspatches und Backups liegen beim Anbieter. Bekannte Beispiele: Microsoft 365, Google Workspace, Slack, Salesforce oder Zoom.

Für das Projekt ändert das die Aufgabe grundlegend: Es entsteht kein Entwicklungsprojekt mit eigener Produkt-Roadmap, sondern ein Einführungs- und Integrationsprojekt mit Konfiguration, Berechtigungskonzept, Datenübernahme, Schnittstellen, Schulung und Abnahme. Beim nutzenden Unternehmen bleiben die Verantwortung für die Daten – Integrität, Aufbewahrung und Sicherung – sowie Zugriffsverwaltung, Benutzerberechtigungen und die Wiederherstellung nach einem Vorfall.

Die weite Verbreitung macht die Einführung nicht einfacher: Laut Statista nutzen 70 Prozent der Unternehmen mit bis zu 500 Mitarbeitenden und 56 Prozent aller Unternehmen weltweit SaaS-Anwendungen. Realistisch ist deshalb ein Plan mit Entscheiden, Rollen, Testfenstern und Abnahmekriterien – und nicht die Annahme, ein Standardprodukt bilde jeden Sonderfall ab.

Ein weiterer Unterschied zur eigenen Installation: Neue Versionen und Features spielt der Anbieter automatisch aus, die Nutzenden arbeiten dadurch immer mit der aktuellen Version. Im Projektplan entfällt damit die eigene Release-Planung; nötig bleiben definierte Zeitfenster für Tests nach grösseren Anbieter-Updates und eine klare Kommunikation an die Nutzenden.

Zielbild, Prozesse und Anforderungen klären

Vor dem Produktentscheid steht die Analyse der eigenen Ausgangslage: bestehende Systemarchitektur, Geschäftsprozesse und organisatorische Anforderungen werden ganzheitlich erhoben. Daraus entsteht eine Cloud-Strategie, die technologische, wirtschaftliche und sicherheitsrelevante Aspekte berücksichtigt, unternehmensstrategisch verankert ist und nicht rein IT-getrieben abläuft. Sie liefert eine Roadmap für die IT-Modernisierung, transparente Investitionsentscheidungen und eine Architektur, die mit dem Unternehmen wächst.

Zu erheben sind: Prozesslandkarte mit den betroffenen Abläufen, zugehörige Daten und Datenflüsse, bestehende Schnittstellen, Rollen und Berechtigungsstufen, Anforderungen an den Datenhaltungsort und benötigte Sprachen. Daraus entsteht ein Zielbild mit prüfbaren Kriterien: abzudeckende Prozesse, Zahl der Nutzenden, Datenvolumen, Kostenrahmen und Termine.

Das Zielbild ist mehr als eine Vorstudie: Es dient später als Bewertungsmassstab für die Anbieterauswahl und als Abnahmekriterium nach dem Rollout. Reduzierte Komplexität und minimierte technologische Abhängigkeiten lassen sich an der Zahl der abgelösten Systeme und der verbleibenden Schnittstellen messen.

Auswahl der Lösung: Kriterien mit Schweiz-Bezug

Ein Kriterienkatalog verhindert, dass Demo-Eindrücke die Auswahl entscheiden. Zu prüfen sind Funktionsumfang gegen die erhobenen Prozessanforderungen, Datenhaltung in der Schweiz oder EU (gilt als Anforderung für DSG-Konformität), Mehrsprachigkeit in DE/EN/FR als Standard für den Schweizer Markt, Abrechnung und Zahlungsarten sowie die Unterstützung durch den Anbieter während der Einführung. Viele Schweizer B2B-Kunden bevorzugen die Zahlung per IBAN-Überweisung; klären Sie, ob der Anbieter das unterstützt und ob Rechnungen in CHF mit Schweizer Mehrwertsteuer ausgestellt werden – in der Schweiz besteht ab CHF 100'000 Jahresumsatz Mehrwertsteuerpflicht.

Technische Kriterien zählen gleichwertig. In einer Multi-Tenant-Architektur nutzen mehrere Kunden dieselbe Software-Instanz, ihre Daten sind aber vollständig getrennt. Typische Funktionen einer SaaS-Lösung sind Benutzer- und Rechteverwaltung, sichere Datentrennung, API-Zugänge, Subscription-Management und Auswertungen. Auch die Skalierbarkeit zählt: Zusätzliche Lizenzen lassen sich meist in wenigen Klicks buchen, was bei Wachstum oder Personalwechsel den Aufwand klein hält.

Für den strukturierten Vergleich eignet sich eine gewichtete Bewertungsmatrix: dieselben Fragen an alle Anbieter, Bewertung pro Kriterium, Summenbildung erst danach. Ein Testzugang mit eigenen Beispieldaten zeigt, ob die Kernprozesse tatsächlich abgebildet werden. Schriftlich zu klären sind Support- und Reaktionszeiten, Release-Kommunikation, Datenexport beim Ausstieg, Kündigungsfristen und Preisregeln bei steigender Nutzerzahl. Eine Rangliste ersetzt diese Prüfung nicht – sie fasst nur zusammen, was zuvor mit eigenen Kriterien bewertet wurde.

Der Projektplan: Phasen von der Konzeption bis zum Rollout

Ein bewährter Ablauf führt über fünf Phasen: Konzept und Umfang, Architektur- und Integrationsentscheide, Pilot mit begrenzter Nutzergruppe, flächendeckender Rollout und anschliessende Skalierung. Ein vergleichbares Vorgehen kennt die SaaS-Entwicklung: Produkt-Strategie, Architektur-Design, MVP-Validierung mit echten Nutzenden, Skalierung. Jede Phase endet mit festgelegten Ergebnissen, die vorliegen müssen, bevor die nächste startet.

Phase 1 – Konzept und Umfang: Ergebnisse sind Prozessanalyse, Anforderungsliste, Grobkonzept, Mengengerüst (Nutzende, Daten, Schnittstellen) und Kostenschätzung. Zu entscheiden ist, welche Module und Funktionsbereiche in welcher Reihenfolge eingeführt werden und welche Nutzergruppen zuerst an der Reihe sind. Ohne diesen Entscheid sind weder Ausschreibung noch Angebotsvergleich möglich.

Phase 2 – Architektur und Integration: Hier fallen die technischen Grundsatzentscheide – Multi-Tenant- oder Single-Tenant-Betrieb, Konzept der Datenisolation, API-Design, Datenhaltungsort, Berechtigungsmodell und die Liste der Schnittstellen zu bestehenden Systemen. Ergebnisse: technisches Konzept, Schnittstellenspezifikation, Migrationsplan und Testkonzept.

Phase 3 – Pilot: Eine begrenzte Nutzergruppe arbeitet mit den Kernfunktionen und echten Daten; Fehler, Lücken und Bedienprobleme werden erfasst und priorisiert. Ergebnisse: bestandene Testfälle, bereinigte Fehlerliste, Schulungsunterlagen, migrierte Testdaten. Erst wenn die Kernprozesse im Pilot funktionieren, ist der Rollout sinnvoll.

Phase 4 – Rollout: Datenübernahme, Schulung, Support und Kommunikation laufen nach einem Zeitplan pro Nutzergruppe. Ergebnisse: produktiver Start mit definierter Nutzerzahl, abgeschlossene Schulungen, funktionierender Supportweg. Phase 5 – Skalierung: Erweiterung auf weitere Bereiche, zusätzliche Module, Automatisierung und Performance-Optimierung. Die Einführung endet nicht mit der ersten Live-Version; die Produktentwicklung läuft beim Anbieter weiter, das Unternehmen plant Betrieb und Erweiterung entsprechend mit.

Meilensteine setzen und messbar machen

Ein Meilenstein taugt nur als Steuerungsinstrument, wenn er vier Elemente enthält: ein überprüfbares Ergebnis, ein Kriterium, bis wann es vorliegt, und eine verantwortliche Rolle. Beispiele: abgeschlossene Prozessanalyse, freigegebene Anbieterauswahl durch den Auftraggeber, bestandene Testphase mit echten Nutzenden, produktiver Start, erreichte Nutzungsziele nach einem definierten Beobachtungszeitraum.

Damit Meilensteine als Abbruchkriterien taugen, muss jedes Kriterium scheiterbar formuliert sein. Der Pilot gilt als bestanden, wenn die vereinbarten Kernprozesse mit echten Daten durchlaufen werden und die Wiederherstellung von Daten nachgewiesen ist – nicht, wenn «die Stimmung gut» ist. Wird ein Kriterium nicht erreicht, sind die Konsequenzen vorab festzulegen: Nachverhandlung, Nachschulung, erneuter Testlauf oder Abbruch des Vorhabens.

Die zeitliche Dimension hängt stark vom Umfang ab. Wer nur einen Kernbereich einführt, braucht weniger Migrationsschritte, Schnittstellen und Schulungen als bei einem vollständigen Funktionsumfang mit mehreren Modulen. Fixtermine gehören deshalb an Ereignisse gebunden – Budgetfreigabe, Ablauf eines Altvertrags, Ende einer Pilotphase – und nicht an Kalenderwünsche, die den Testaufwand zusammenstreichen.

Wer trägt was: geteilte Verantwortung statt Alles-beim-Anbieter

Grundlage ist das Modell der geteilten Verantwortung: Die Sicherheit der Infrastruktur liegt beim SaaS-Anbieter, die Datensicherheit grösstenteils beim nutzenden Unternehmen. Viele Unternehmen nehmen fälschlicherweise an, der Anbieter schütze auch ihre Daten. Tatsächlich bleiben Integrität, Aufbewahrung und Sicherung der Daten beim Kunden – zusammen mit Zugriffsverwaltung, Benutzerberechtigungen und Datenwiederherstellung.

Auf der Anbieterseite stehen Bereitstellung aus gesicherten Rechenzentren, Betrieb, Updates, Wartung, Sicherheitspatches und Backups der Infrastruktur. Auf der Unternehmensseite stehen Datenverantwortung, Berechtigungskonzept, eigene Sicherung der SaaS-Daten, Notfallplan und Compliance.

Daraus lassen sich konkrete Projektrollen ableiten: Die Auftraggeberseite entscheidet über Budget und Meilensteinfreigaben. Die Fachbereiche liefern Prozesse, Testfälle, Abnahmen und die Kommunikation an die Nutzenden. Die IT verantwortet Integration, Schnittstellen, Berechtigungskonzept sowie Datenexport und -sicherung. Die Projektleitung führt Plan, Risikoliste, Statusberichte und Eskalation. Die Anbieterseite liefert Onboarding, Support und Release-Informationen. Das Zeitbudget jeder Rolle gehört ausdrücklich in die Planung – Fachbereichsmitarbeitende sind während Test und Schulung nicht für das Tagesgeschäft verfügbar.

Daten, Zugriffsrechte und Wiederherstellung regeln

Zugriffe steuern rollenbasierte Zugriffskontrollen (RBAC) und verhindern, dass unbefugte Benutzer auf Daten zugreifen. Dazu kommt die Trennung zwischen Kunden: In einer Multi-Tenant-Architektur sieht jeder Kunde nur seine eigenen Daten, technisch abgesichert etwa über Row-Level Security auf Datenbankebene. Wichtige Kriterien für eine Backup-Lösung sind einfache Verwaltung und rollenbasierte Zugriffskontrolle.

Typische Risiken, gegen die der Projektplan Vorkehrungen treffen muss: versehentliche Löschungen und menschliches Versagen, böswillige Insider, Ransomware und Cyberangriffe, die zunehmend SaaS-Anwendungen als Ziel nehmen, sowie Synchronisierungsfehler mit Datenverlust oder -beschädigung. Aus der geteilten Verantwortung folgt eine eigene Backup- und Recovery-Strategie für die SaaS-Daten – statt des Vertrauens auf die Sicherungen des Anbieters.

Fest im Projektplan zu verankern sind ein Berechtigungskonzept mit definierten Rollen, ein Wiederherstellungstest vor dem Go-live, klare Regeln, wer löschen und wiederherstellen darf, die Protokollierung kritischer Aktionen, Aufbewahrungs- und Löschfristen sowie ein geordneter Export beim Ausstieg aus einem Dienst. Ohne diese Punkte bleibt offen, wer im Ernstfall handelt.

Migration und Integration in die bestehende Systemlandschaft

Ziel der Migration ist, bestehende Anwendungen, Daten und Geschäftsprozesse sicher, strukturiert und ohne operative Störungen in die neue Umgebung zu überführen. Damit verbunden sind der Abbau von Komplexität und die Reduktion technologischer Abhängigkeiten – beides lässt sich an der Zahl der abgelösten Systeme und der verbleibenden Schnittstellen messen.

Praktisch beginnt die Migration mit einem Dateninventar: Welche Datensätze werden gebraucht, wo liegen sie heute, wer ist Eigentümer, welche Felder müssen wie zugeordnet werden? Danach folgen Bereinigung vor der Übernahme, Export aus dem Altsystem, Import, Abgleich und eine dokumentierte Kontrolle der Datensätze. Schnittstellen werden über die API der Lösung angebunden; zu klären ist, ob der Austausch laufend oder in Stapeln erfolgt und was bei Ausfällen passiert.

Während des Umstiegs läuft ein Parallellbetrieb: Altsystem und neue Lösung werden für einen definierten Zeitraum gleichzeitig geführt. Vorab festzulegen sind Dauer, Kriterien für die Abschaltung, Zuständigkeit für den Datenabgleich und ein Rückfallweg, falls der Umstieg stockt. Nach der Abschaltung des Altsystems gehören Verträge, Lizenzen, Zugänge und Wartungsverträge auf die Abschlussliste – sonst bleiben Kosten und Abhängigkeiten bestehen.

Nach dem Go-live: Betrieb, Kosten und Weiterentwicklung

Mit dem produktiven Start beginnt der Betrieb. SaaS funktioniert nach einem Abo-Modell mit monatlichen oder jährlichen Kosten; diese wiederkehrenden Ausgaben gehören über die gesamte Laufzeit ins Budget, nicht nur ins Einführungsjahr. Zusätzliche Nutzende oder Lizenzen lassen sich meist in wenigen Klicks dazubuchen, wodurch die Kosten mit der Nutzerzahl mitwachsen.

Für die Steuerung gehören Kennzahlen in den Betrieb: aktive Nutzende, Nutzung pro Prozess und Supportfälle. Auswertungen und Dashboards liefern die Daten dafür. Neue Funktionen werden schrittweise und auf Basis von Nutzerfeedback erweitert – die Weiterentwicklung des Produkts endet beim Anbieter nicht mit der ersten Live-Version, entsprechend wird auch beim Kunden laufend geplant.

Kosten und Zeitaufwand variieren stark mit dem Umfang. Richtwerte nennt logixc für die Entwicklung eines SaaS-Produkts in der Schweiz: CHF 20'000 bis 40'000 und 6 bis 10 Wochen für ein MVP, CHF 40'000 bis 80'000 und 12 bis 20 Wochen für ein vollständiges v1.0, CHF 80'000 und mehr sowie 6 Monate und länger für Enterprise-Varianten mit Multi-Tenancy, API und Integrationen. Diese Zahlen betreffen die Produktentwicklung. Bei der Einführung einer zugekauften Lösung fallen stattdessen Abo-, Integrations-, Schulungs- und Betriebskosten an; entscheidend für deren Höhe sind Umfang, Zahl der Schnittstellen und Grösse der Nutzergruppe.