Was ist SaaS (Software as a Service)?

Die meistzitierte Definition stammt vom US-amerikanischen National Institute of Standards and Technology (NIST). In der Special Publication 800-145, im Oktober 2011 in ihrer finalen Fassung veröffentlicht, beschreiben Peter Mell und Timothy Grance drei Servicemodelle des Cloud Computing — Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS) — sowie fünf Merkmale, die ein Angebot erst zu einem Cloud-Service machen: Selbstbedienung auf Abruf, breiter Netzzugriff, geteilte Ressourcen, schnelle Elastizität und eine gemessene, meist nutzungsabhängige Abrechnung.

Bei SaaS betreibt der Anbieter die vollständige Anwendung — von der Infrastruktur bis zur Oberfläche. Der Kunde meldet sich über einen Browser oder eine schlanke Client-Anwendung an und nutzt die Software, ohne Server, Betriebssystem oder Speicher selbst zu verwalten.

Wer eine Anwendung selbst betreibt, betreibt sie an jedem Standort neu: Server bereitstellen, Betriebssystem pflegen, Sicherheitslücken schließen, Version für Version aktualisieren. Bei zehn Werken mit jeweils eigener Installation sind das zehn Update-Vorgänge mit zehn möglichen Abweichungen — unterschiedliche Patch-Stände, unterschiedliche Fehlerbilder, unterschiedliche Ansprechpartner. Bei SaaS ist es ein Software-Stand für alle zehn Werke gleichzeitig.

Dazu kommt die Kostenform: Eine eigene Installation ist eine Investition im Voraus — Server, Lizenzen, Ausfallsicherung. SaaS verschiebt das in eine laufende, meist monatliche Gebühr, die mit der Nutzung wächst oder schrumpft, ohne dass eine eigene Ausfallsicherung aufgebaut werden muss.

Der Preis dafür ist Kontrolle: Wer nicht selbst betreibt, entscheidet auch nicht mehr allein über den Zeitpunkt eines Updates, den Standort der Server oder die Reihenfolge, in der neue Funktionen erscheinen.

Die meisten SaaS-Anwendungen laufen als Multi-Tenant-Architektur: eine gemeinsame Anwendung und Infrastruktur bedient viele Kunden (Tenants) gleichzeitig, logisch voneinander getrennt, aber technisch auf denselben Systemen. Die Alternative ist Single-Tenant: jeder Kunde bekommt eine eigene, isolierte Instanz.

Multi-Tenancy ist der Grund, warum SaaS-Anbieter neue Funktionen schnell für alle Kunden ausliefern können — und der Grund, warum Anpassungen an einzelne Kunden dort enger begrenzt sind als bei einer eigenen Installation.

Ein SLA (Service Level Agreement) legt fest, mit welcher Verfügbarkeit der Anbieter rechnet — meist als Prozentsatz pro Jahr — und was im Störungsfall gilt: Reaktionszeit, Eskalationsweg, Entschädigung. Für eine Produktionsanwendung ist dieser Wert kein Randthema: Ein SLA, das für ein Büro-Werkzeug ausreicht, kann für eine Anwendung, die den Schichtbetrieb steuert, zu wenig sein.

Updates erscheinen bei SaaS in der Regel automatisch und für alle Kunden zur gleichen Zeit — häufig in Stufen (zuerst eine kleine Gruppe, dann alle), mit Release Notes, die beschreiben, was sich ändert. Anders als bei einer eigenen Installation kann der Kunde ein Update selten dauerhaft aufschieben; er kann es meist nur um ein festes Zeitfenster verzögern. Das verlangt ein eigenes, kleines Change Management: wer im Unternehmen prüft neue Versionen, bevor sie live gehen, und wer entscheidet, wenn eine Änderung den laufenden Betrieb berührt.

• Internetanbindung. SaaS setzt eine belastbare Verbindung zwischen Werk und Anbieter voraus — in der Produktion oft der schwächste Punkt, weshalb eine zweite, unabhängige Anbindung oder eine lokale Zwischenspeicherung bei Ausfall dazugehört.
• Anmeldung und Berechtigungen. Single Sign-On (SSO) über Standards wie SAML oder OAuth bindet die SaaS-Anwendung an die bestehende Nutzerverwaltung an, statt eine eigene Passwortliste zu führen.
• Schnittstellen. APIs verbinden die SaaS-Anwendung mit MES, ERP oder einem Namensraum wie dem Unified Namespace — ohne sie bleibt SaaS eine isolierte Oberfläche statt eines Teils der Landschaft.
• Verschlüsselung. Daten werden auf dem Übertragungsweg (TLS) und im Speicher verschlüsselt; der Serverstandort entscheidet mit, welches Recht auf die Daten anwendbar ist.

1. Datenklassen festlegen

   Welche Daten dürfen das Werk in die Cloud verlassen, welche bleiben lokal? Diese Entscheidung steht vor der Anbieterauswahl, nicht danach.

2. Anbieter und Vertrag prüfen

   Auftragsverarbeitungsvertrag nach Art. 28 DSGVO, Serverstandort, SLA, Kündigungsfrist und — besonders wichtig — die Möglichkeit, eigene Daten in einem offenen Format wieder zu exportieren.

3. Integration einrichten

   Single Sign-On, Schnittstellen zu MES/ERP und Namensraum, Netzwerkfreigaben — bevor die Anwendung im Schichtbetrieb genutzt wird.

4. Betrieb überwachen

   Verfügbarkeit, Update-Ankündigungen und Nutzung werden laufend beobachtet, nicht nur beim Vertragsabschluss geprüft.

• Kein Freibrief für die Datenschutzverantwortung. Der Kunde bleibt im Regelfall datenschutzrechtlich Verantwortlicher, der Anbieter ist Auftragsverarbeiter nach Art. 28 DSGVO — mit Vertrag, nicht nur mit Vertrauen.
• Kein Ersatz für eine Anbindung bei Internetausfall. Ohne lokale Pufferung steht die Anwendung still, sobald die Leitung ausfällt — dafür braucht es dieselbe Store-&-Forward-Logik wie an anderer Stelle der Landschaft.
• Kein einheitliches Produkt. Der Grad an Konfigurierbarkeit, der Serverstandort und die Exportmöglichkeiten unterscheiden sich von Anbieter zu Anbieter erheblich.
• Kein Ersatz für IaaS oder PaaS, wenn eine eigene Anwendung entwickelt werden soll — dafür bleiben die anderen beiden Servicemodelle die richtige Wahl.

• Internetabhängigkeit in der Halle. Wo die Netzanbindung schwächer ist als im Büro, entscheidet eine fehlende Pufferung darüber, ob ein Leitungsausfall zum Produktionsstillstand wird.
• Ungeklärte Datenhoheit. Serverstandort und anwendbares Recht werden oft erst nach der Unterschrift geprüft — dabei gehören sie in die Vertragsprüfung, nicht in die Nachbetrachtung.
• Vendor Lock-in. Ohne zugesicherten Export im offenen Format wird ein Anbieterwechsel teurer, je länger die Nutzung dauert.
• Update-Zwang ohne Change Management. Wer neue Versionen nicht vorab prüft, erlebt Änderungen im laufenden Betrieb statt geplant.

pronubes ist die Plattform zwischen Shopfloor und IT — als SaaS betrieben, mit Serverstandort in der EU und einem Auftragsverarbeitungsvertrag nach Art. 28 DSGVO als Vertragsbestandteil.

• pronubes Edge puffert bei Verbindungsverlust vor Ort — ein Leitungsausfall im Werk unterbricht nicht die Datenerfassung, nur die Übertragung.
• pronubes Zones und pronubes Insights laufen als Multi-Tenant-SaaS: Ein Software-Stand für alle Kunden, Updates ohne eigenen IT-Aufwand vor Ort.
• Daten lassen sich jederzeit in offenen Formaten exportieren — SaaS bindet an einen Betrieb, nicht an ein Format.

So bleibt der Betrieb beim Anbieter — die Entscheidung, welche Daten wohin fließen, beim Kunden. Mehr zur Plattform