Wie nutzen Sie Software-as-a-Service, ohne nach 6 Monaten im Abo-Dschungel zu landen?

Software-as-a-Service (SaaS) ermöglicht Schweizer KMU, neue Anwendungen ohne eigene Serverinfrastruktur einzuführen. Eine Fachabteilung kann ein Tool testen, Mitarbeitende einladen und innerhalb kurzer Zeit produktiv arbeiten. Doch gerade diese Einfachheit schafft ein Problem: Nach einigen Monaten laufen möglicherweise mehrere Abonnements parallel, niemand kennt sämtliche Kündigungsfristen und der tatsächliche Nutzen einzelner Lizenzen bleibt unklar.

Die Lösung ist nicht, jede Softwarebeschaffung durch einen langwierigen Freigabeprozess zu schicken. Entscheidend ist ein leichtgewichtiges SaaS-Management: Anforderungen vor dem Kauf festlegen, Verträge zentral erfassen, Zugriffe kontrollieren und Ausstiegsmöglichkeiten prüfen. So bleibt die Einführung schnell, ohne dass die Kontrolle über Kosten, Daten und Anbieter verloren geht.

Für Schweizer Unternehmen kommt eine weitere Verantwortung hinzu. Wer Personendaten über Cloud-Dienstleister bearbeiten lässt, muss die Anforderungen des Schweizer Datenschutzgesetzes berücksichtigen. Das gilt auch dann, wenn ein SaaS-Produkt technisch sofort einsatzbereit ist und keine klassische IT-Installation benötigt.

Warum SaaS-Kosten explodieren, sobald 3 Teams „mal testen“

Wenn drei Teams unabhängig SaaS-Anwendungen testen, können Kosten entstehen, die keiner zentralen Budgetplanung zugeordnet sind. Testzugänge werden zu kostenpflichtigen Abonnements, identische Funktionen mehrfach eingekauft und ungenutzte Nutzerkonten weiterberechnet. Nicht die Anzahl der Teams verursacht zwangsläufig eine Kostenexplosion, sondern die fehlende Übersicht über Beschaffung, Nutzung und Vertragsbedingungen.

Die Ausgangssituation ist nachvollziehbar: Der Vertrieb benötigt ein CRM-Zusatztool, das Marketing eine Automatisierungslösung und die Personalabteilung eine Plattform für Bewerbungen. Jede Anwendung löst zunächst ein konkretes Problem. Ohne gemeinsame Inventarisierung sieht jedoch niemand, ob bereits vorhandene Systeme dieselben Aufgaben erfüllen könnten.

Daraus entsteht sogenannte Shadow IT: Anwendungen werden ausserhalb der zentralen IT-Verwaltung beschafft oder betrieben. Neben doppelten Lizenzkosten können dadurch Sicherheitsprüfungen, Verantwortlichkeiten und Löschprozesse lückenhaft werden. Für Schweizer KMU mit kurzen Entscheidungswegen kann eine dezentrale Beschaffung praktisch sein. Sie braucht aber verbindliche Mindestregeln.

Ein weiterer Kostentreiber ist die License-Drift. Teams laden zusätzliche Nutzer ein, benötigen erweiterte Funktionen oder überschreiten enthaltene Nutzungskontingente. Bei entsprechenden Tarifmodellen steigen dadurch die monatlichen Ausgaben. Neben Nutzerlizenzen können beispielsweise API-Aufrufe, Speicherplatz oder andere Verbrauchsgrössen kostenpflichtig sein.

Der FinOps-Fachbeitrag zur SaaS-Kostenkontrolle beschreibt die Zusammenführung von Nutzungs- und Kostendaten sowie die Überwachung von Vertragsverlängerungen als wichtige Bestandteile einer kontrollierten SaaS-Verwaltung.

Für den Einstieg genügt häufig eine gemeinsame Vertragsübersicht. Pro Anwendung sollten mindestens folgende Informationen vorhanden sein:

• Anbieter, Produkt und verantwortliche Fachabteilung
• Gebuchte Lizenzen und tatsächlich aktive Nutzer
• Grundpreis, Zusatzkosten und Abrechnungsintervall
• Vertragsbeginn, Laufzeit und Kündigungsfrist
• Automatische Verlängerung und mögliche Anpassungsrechte
• Geschäftlicher Zweck und zuständige Person für die Freigabe

Besonders aufschlussreich ist der Vergleich zwischen gebuchten und aktiv verwendeten Lizenzen. Ein bezahlter Zugang ohne erkennbare Nutzung ist ein Kandidat für eine Prüfung, aber nicht automatisch überflüssig. Manche Konten dienen der Administration, seltenen Pflichtaufgaben oder der Wiederherstellung von Betriebsabläufen.

Erst wenn diese Transparenz besteht, lohnt es sich, neue Anwendungen systematisch zu vergleichen. Andernfalls vergrössert jede zusätzliche Softwareauswahl lediglich einen Bestand, dessen tatsächliche Kosten unbekannt sind.

Wie wählen Sie SaaS mit 9 Kriterien aus, ohne 20 Demos anzuschauen?

Sie vermeiden unnötige SaaS-Demos, indem Sie vor dem Anbietervergleich neun Kriterien festlegen und verbindliche Mindestanforderungen definieren. Anbieter, die zentrale Anforderungen an Funktionen, Datenschutz, Integration oder Datenexport nicht erfüllen, scheiden bereits bei der Vorprüfung aus. Erst die verbleibenden Lösungen werden anhand realer Geschäftsprozesse getestet und wirtschaftlich verglichen.

Der häufigste Fehler ist, eine Softwarepräsentation als Ausgangspunkt der Auswahl zu verwenden. Eine überzeugende Demo zeigt vor allem, welche Funktionen der Anbieter gut präsentieren kann. Sie beantwortet nicht zwingend, ob das Produkt die betrieblichen Anforderungen eines KMU zuverlässig erfüllt.

Stattdessen sollten IT und Fachabteilungen zunächst dokumentieren, welche Aufgaben zwingend abgedeckt werden müssen. Danach lassen sich Anbieterinformationen, technische Unterlagen und Vertragsentwürfe gezielt prüfen.

Diese neun Kriterien bilden die Entscheidungsgrundlage:

1. Funktionale Abdeckung: Unterstützt die Anwendung die wichtigsten Geschäftsprozesse ohne aufwendige Umgehungslösungen?
2. Integration und API-Fähigkeit: Sind Schnittstellen zu bestehenden Systemen vorhanden, ausreichend dokumentiert und im gewünschten Tarif enthalten?
3. DSG-Konformität: Ermöglichen Vertragsbedingungen, Sicherheitsmassnahmen und organisatorische Prozesse eine datenschutzkonforme Nutzung?
4. Datenspeicherort: Wo werden Personendaten gespeichert und bearbeitet, welche Länder sind beteiligt und wer kann darauf zugreifen?
5. Exit-Möglichkeiten: Können Daten vollständig und in einem brauchbaren Format exportiert werden? Welche Kosten oder Einschränkungen entstehen?
6. Nutzerlizenzmodell: Wie werden zusätzliche, inaktive, externe oder nur gelegentlich eingesetzte Nutzer abgerechnet?
7. Support-Qualität: Welche Reaktionszeiten, Supportsprachen und Eskalationsmöglichkeiten sind vertraglich vorgesehen?
8. Skalierbarkeit: Bleibt die Anwendung bei wachsenden Nutzerzahlen und Datenmengen technisch und wirtschaftlich geeignet?
9. Total Cost of Ownership: Welche Gesamtkosten entstehen durch Lizenzen, Einführung, Integration, Administration, Schulung und späteren Ausstieg?

Für Schweizer Unternehmen verdient das Datenschutzkriterium besondere Aufmerksamkeit. Das revidierte Datenschutzgesetz (DSG) gilt seit dem 1. September 2023. Bei ausgelagerter Datenbearbeitung bleibt das verantwortliche Unternehmen grundsätzlich für die Einhaltung seiner datenschutzrechtlichen Pflichten zuständig.

Die EDÖB-Informationen zur Auftragsdatenbearbeitung erläutern insbesondere die Auswahl und Überwachung von Dienstleistern, angemessene Sicherheitsmassnahmen, Unterauftragsbearbeiter und internationale Datenübermittlungen.

Eine Speicherung ausschliesslich in der Schweiz ist dabei keine allgemeine gesetzliche Voraussetzung für jeden SaaS-Dienst. Entscheidend sind die konkrete Datenbearbeitung, die beteiligten Länder und die erforderlichen Schutzmassnahmen. Die Liste der Unterauftragsbearbeiter sowie die Vereinbarung zur Auftragsbearbeitung sollten deshalb vor Vertragsabschluss geprüft werden.

Ein Praxistest sollte nicht beim erfolgreichen Login enden. Entscheidend ist, ob ein typischer Arbeitsvorgang vollständig funktioniert und die erzeugten Daten anschliessend wieder exportiert werden können. Für Tests mit Personendaten müssen die datenschutzrechtlichen Voraussetzungen bereits erfüllt sein; andernfalls eignen sich synthetische Beispieldaten.

Nach der Produktauswahl bleibt die Vertragsgestaltung entscheidend. Selbst eine funktional passende Lösung kann teuer werden, wenn sich die Lizenzanzahl bei verändertem Personalbedarf nicht anpassen lässt.

Monatsabo oder Jahresvertrag: Was ist besser bei schwankenden Nutzerzahlen?

Monatsabonnements eignen sich besonders für Teams mit unsicherem oder kurzfristig wechselndem Personalbedarf. Jahresverträge können wirtschaftlicher sein, wenn Nutzerzahlen und Softwarebedarf stabil bleiben und ein entsprechender Preisvorteil tatsächlich angeboten wird. Entscheidend sind jedoch nicht nur die ausgewiesenen Lizenzpreise, sondern auch Mindestabnahmen, Anpassungsrechte und automatische Vertragsverlängerungen.

Ein Jahresvertrag mit günstigem Preis pro Nutzer ist kein Vorteil, wenn ein Unternehmen für nicht mehr benötigte Zugänge weiterzahlen muss. Umgekehrt kann ein monatlich kündbarer Tarif unnötig teuer werden, wenn dieselbe Anzahl Mitarbeitender über lange Zeit auf die Anwendung angewiesen ist.

Die Wahl sollte deshalb auf der erwarteten Nutzung und den konkreten Vertragsbedingungen beruhen.

Besonders wichtig sind sogenannte True-up- und True-down-Regeln. Ein True-up ermöglicht oder verpflichtet zur Anpassung der Lizenzkosten bei steigendem Bedarf. Ein True-down erlaubt dagegen eine Reduktion. Nicht jeder Vertrag bietet beide Möglichkeiten unter vergleichbaren Bedingungen.

Das FinOps Framework für Lizenz- und SaaS-Management weist darauf hin, dass Softwareverträge Erhöhungen der Lizenzmenge ermöglichen können, ohne entsprechende Reduktionsrechte vorzusehen. Auch zusätzliche Abrechnungsmetriken müssen berücksichtigt werden.

Für ein KMU mit saisonalen Mitarbeitenden kann deshalb ein hybrides Modell interessant sein: Die dauerhaft benötigten Zugänge werden längerfristig gebucht, während temporäre Nutzer über flexibel kündbare Lizenzen abgedeckt werden. Vorausgesetzt ist, dass der Anbieter eine solche Kombination tatsächlich unterstützt.

Ebenso wichtig ist ein zentraler Vertragskalender. Er sollte neben dem offiziellen Vertragsende die Kündigungsfrist und einen internen Prüfungstermin enthalten. Dieser Prüfungstermin muss ausreichend vor der Kündigungsfrist liegen, damit Lizenzbedarf, Alternativen und Verhandlungsmöglichkeiten geklärt werden können.

Bei automatischen Verlängerungen ist zusätzlich zu prüfen, ob sich der Vertrag um einen Monat, ein Jahr oder eine andere vereinbarte Laufzeit verlängert. Die konkrete Regel ergibt sich aus dem jeweiligen Vertrag, nicht aus dem Begriff «Jahresabo» allein.

Mit einem passenden Lizenzmodell sind die laufenden Kosten besser steuerbar. Vollständig kontrolliert ist die SaaS-Nutzung aber erst, wenn auch das Ausscheiden von Mitarbeitenden zuverlässig in allen Anwendungen berücksichtigt wird.

Der Admin-Fehler, der Ex-Mitarbeitenden noch 90 Tage Zugriff lässt

Ein ehemaliger Mitarbeiter kann weiterhin auf SaaS-Daten zugreifen, wenn sein Konto beim Austritt nicht deaktiviert und bestehende Sitzungen oder Zugangsdaten nicht wirksam entzogen werden. Die im Titel genannten 90 Tage sind keine gesetzliche oder allgemeine technische Frist, sondern ein mögliches Risikofenster. Wie lange ein Zugriff bestehen bleibt, hängt von Anwendung, Konfiguration und Offboarding-Prozess ab.

Die Ursache liegt häufig in unvollständigen Zuständigkeiten. Die Personalabteilung meldet den Austritt, die IT sperrt das zentrale Unternehmenskonto, aber eine Fachabteilung verwaltet ihre eigenständig beschaffte SaaS-Anwendung weiterhin separat. Das dort angelegte Benutzerkonto bleibt aktiv.

Ein solches Konto verursacht möglicherweise zusätzliche Lizenzkosten. Schwerer wiegt jedoch die Gefahr, dass ehemalige Mitarbeitende weiterhin vertrauliche Dokumente, Kundendaten oder interne Geschäftsinformationen einsehen können.

Ein wirksames Offboarding beginnt deshalb mit einem vollständigen SaaS-Inventar. Zu jedem Dienst muss bekannt sein, wer Benutzer verwaltet und wie Berechtigungen entzogen werden.

Eine zentrale Identitätsverwaltung mit Single Sign-on (SSO) reduziert diesen Verwaltungsaufwand. Mitarbeitende authentifizieren sich über ein gemeinsames Identitätssystem, statt separate Passwörter für jede Anwendung zu verwenden.

SSO allein garantiert allerdings nicht, dass sämtliche SaaS-Konten beim Austritt gelöscht oder gesperrt werden. Die tatsächliche Wirkung hängt von der Integration ab. Automatisierte Benutzerbereitstellung und -deaktivierung, etwa über unterstützte Provisioning-Schnittstellen, kann zusätzliche Sicherheit schaffen. Bestehende Sitzungen, lokale Konten, API-Schlüssel und nicht integrierte Anwendungen müssen gegebenenfalls separat behandelt werden.

Eine geeignete Offboarding-Kontrolle umfasst daher die Bestätigung des Austritts, eine Liste sämtlicher zugeordneten Anwendungen, die Deaktivierung der Zugänge sowie eine dokumentierte Prüfung verbliebener Berechtigungen. Dabei müssen auch Administratorrechte und gemeinsam verwendete Zugangsdaten berücksichtigt werden.

Das Schweizer Datenschutzgesetz verlangt in Artikel 8 risikogerechte technische und organisatorische Sicherheitsmassnahmen. Gemäss Artikel 24 muss eine Verletzung der Datensicherheit dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten so rasch als möglich gemeldet werden, wenn sie voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte betroffener Personen führt. Die Rechtsgrundlage findet sich im Schweizer Datenschutzgesetz (DSG) auf Fedlex.

Ein nicht deaktiviertes Konto bedeutet nicht automatisch, dass bereits eine meldepflichtige Datenschutzverletzung vorliegt. Ob eine Verletzung stattgefunden hat und die Meldeschwelle erreicht wird, hängt insbesondere von den tatsächlichen Zugriffen, den betroffenen Informationen und dem Risiko für die betroffenen Personen ab.

Zentrale Benutzerverwaltung verbessert damit Sicherheit und Kostenkontrolle zugleich. Bei der anschliessenden Optimierung der Softwarelandschaft müssen jedoch auch laufende Verträge berücksichtigt werden, bevor Anwendungen vorschnell ersetzt werden.

Wann sollten Sie erst Verträge bündeln und erst danach Tools ablösen?

Verträge sollten zuerst gebündelt und neu verhandelt werden, wenn mehrere Anwendungen ähnliche Leistungen abdecken, noch längere Restlaufzeiten bestehen oder ein gemeinsamer Einkauf bessere Bedingungen ermöglichen könnte. Ein sofortiger Wechsel lohnt sich dagegen eher, wenn Sicherheitsprobleme, funktionale Mängel oder die langfristigen Betriebskosten schwerer wiegen als die Wechselkosten. Massgeblich ist ein Vergleich beider Wege.

Die technische Ablösung einer Anwendung und die wirtschaftliche Beendigung ihres Vertrags sind zwei unterschiedliche Entscheidungen. Ein Unternehmen kann ein neues Produkt einführen und trotzdem verpflichtet bleiben, das bisherige Abonnement bis zum Vertragsende zu bezahlen.

Vor einer Migration sollten daher mindestens vier Grössen erfasst werden: die verbleibenden Vertragszahlungen, mögliche Kosten einer vorzeitigen Kündigung, der Aufwand für Migration und Schulung sowie die Kosten eines notwendigen Parallelbetriebs.

Diese Informationen erlauben einen Vergleich zwischen sofortiger Ablösung und einem geplanten Wechsel zum regulären Vertragsende.

Ein vereinfachtes, ausdrücklich hypothetisches Beispiel: Ein KMU möchte sein bestehendes Dokumentenmanagement ersetzen. Der aktuelle Vertrag läuft noch mehrere Monate, während die neue Lösung bereits verfügbar ist. Wird sofort umgestellt, können in dieser Übergangszeit beide Abonnements kostenpflichtig sein. Ein späterer Wechsel könnte diese Überschneidung reduzieren, muss aber gegen den fortbestehenden Nutzen und die Risiken des alten Systems abgewogen werden.

Der Parallelbetrieb ist nicht grundsätzlich ineffizient. Er ermöglicht beispielsweise, Datenübernahmen zu prüfen, Mitarbeitende einzuarbeiten und kritische Prozesse zu vergleichen. Allerdings sollten Dauer, Verantwortlichkeiten und Abschaltkriterien vorab festgelegt werden.

Beim Bündeln mehrerer Verträge über einen Anbieter oder Reseller können Schweizer KMU nach gemeinsamen Laufzeiten, Lizenzanpassungen, Kündigungsrechten und klaren Exportbedingungen fragen. Ob solche Zugeständnisse möglich sind, hängt vom jeweiligen Anbieter, dem Einkaufsvolumen und der Verhandlungsposition ab.

Wichtig bleibt, dass eine Bündelung nicht unbeabsichtigt eine neue Abhängigkeit schafft. Ein günstiger Gesamtvertrag ist wenig hilfreich, wenn einzelne Leistungen später nicht mehr separat beendet werden können.

Nach der Vertragsprüfung lässt sich bewerten, ob die vorhandene Softwarelandschaft langfristig sinnvoll aufgebaut ist. Dabei sind die Zahl der Anwendungen und ihre Lizenzpreise nur ein Teil der Rechnung.

Warum 7 Einzellösungen oft teurer sind als 1 integrierter Stack?

Sieben spezialisierte Anwendungen können insgesamt teurer sein als eine integrierte Plattform, weil zusätzlich zu den Lizenzen Schnittstellen, Datenabgleiche, Administration und Schulungen anfallen. Eine gemeinsame Softwareplattform kann diese Aufwände reduzieren. Sie ist jedoch nicht automatisch günstiger: Fehlende Spezialfunktionen, teure Zusatzmodule oder aufwendige Anpassungen können den vermeintlichen Vorteil wieder aufheben.

Ein reiner Preisvergleich zeigt selten die tatsächlichen Betriebskosten. Wenn Vertrieb, Buchhaltung und Projektmanagement unterschiedliche Systeme verwenden, müssen Informationen möglicherweise mehrfach erfasst oder automatisiert übertragen werden.

Besonders bei Schnittstellenproblemen entsteht zusätzlicher Aufwand. Eine geänderte API, ein fehlgeschlagener Datenabgleich oder unterschiedliche Felddefinitionen können manuelle Korrekturen erforderlich machen.

Hinzu kommt die Datenfragmentierung. Liegen Kundeninformationen verteilt in mehreren Systemen, entstehen unterschiedliche Datenstände. Mitarbeitende müssen klären, welche Anwendung die verbindliche Information enthält. Auch Auswertungen können aufwendiger werden, wenn Daten zunächst zusammengeführt und bereinigt werden müssen.

Eine integrierte Plattform mit gemeinsamem Datenmodell kann diese Probleme reduzieren. Ihr Vorteil hängt allerdings davon ab, ob die verwendeten Module tatsächlich integriert sind und die benötigten Geschäftsprozesse ausreichend unterstützen.

Für eine belastbare Entscheidung empfiehlt sich ein Vergleich der Total Cost of Ownership (TCO) über einen gemeinsamen Zeitraum von beispielsweise drei Jahren. Dieser Planungshorizont ist eine Bewertungsmethode und keine allgemeingültige Vertrags- oder Amortisationsdauer.

Bei der Berechnung sollten einmalige Einführungs- und Migrationskosten getrennt von jährlich wiederkehrenden Betriebskosten ausgewiesen werden. So wird erkennbar, ob eine Konsolidierung nur kurzfristig teuer ist oder dauerhaft zusätzliche Aufwände verursacht.

Eine Speziallösung kann weiterhin die bessere Wahl sein, wenn sie einen geschäftskritischen Prozess deutlich geeigneter unterstützt als ein allgemeines Plattformmodul. Die Entscheidung sollte deshalb nicht auf einer möglichst geringen Anzahl von Anwendungen beruhen.

Bevor diese Architekturentscheidung getroffen werden kann, müssen die beteiligten Abteilungen allerdings klar formulieren, welche Funktionen und Abläufe wirklich notwendig sind.

Wie führen Sie 3 Anforderungsworkshops durch, die zu klaren Muss-Kriterien führen?

Drei aufeinander aufbauende Workshops schaffen eine belastbare Softwareauswahl: Zuerst werden bestehende Prozesse und Probleme erfasst, danach Anforderungen priorisiert und schliesslich anhand konkreter Arbeitssituationen überprüft. Das Ergebnis ist ein verbindlicher Kriterienkatalog mit nachvollziehbaren Muss- und Kann-Anforderungen. Er verhindert, dass persönliche Funktionswünsche die eigentlichen Geschäftsziele überlagern.

Die Workshops sollten Vertreter der betroffenen Fachabteilungen, der IT und eine entscheidungsbefugte Person einbeziehen. Wichtig ist, dass jede Anforderung auf einen tatsächlichen Arbeitsprozess oder ein überprüfbares betriebliches Risiko zurückgeführt werden kann.

Workshop 1: Ist-Prozesse und Probleme verstehen.

Die Teilnehmenden beschreiben typische Aufgaben in ihrer heutigen Arbeitsweise. Statt nach gewünschten Funktionen zu fragen, sollte beispielsweise geklärt werden: «Wie wird ein Kundenauftrag heute erfasst, geprüft und weitergeleitet?»

Dabei werden Medienbrüche, doppelte Dateneingaben, fehlende Informationen und manuelle Kontrollen sichtbar. Als Ergebnis entsteht eine Übersicht der wichtigsten Prozesse mit den jeweiligen Schwierigkeiten und beteiligten Rollen.

Workshop 2: Anforderungen priorisieren.

Im zweiten Termin werden die festgestellten Probleme in konkrete Anforderungen übersetzt. Eine einfache MoSCoW-Priorisierung kann dabei helfen:

• Must have: Ohne diese Anforderung ist die Lösung für den vorgesehenen Einsatz nicht geeignet.
• Should have: Die Funktion ist wichtig, aber nicht zwingend für den ersten Produktiveinsatz erforderlich.
• Could have: Die Funktion bietet einen Zusatznutzen, falls Aufwand und Budget es erlauben.
• Won’t have: Die Anforderung wird im betrachteten Projektumfang bewusst nicht umgesetzt.

Bei Konflikten zwischen Abteilungen kann eine dokumentierte Bewertung nach Geschäftsrelevanz, Risiko und Aufwand helfen. Eine blosse Mehrheitsentscheidung ist für kritische Anforderungen ungeeignet: Eine gesetzlich notwendige Schutzmassnahme kann beispielsweise nicht dadurch entfallen, dass andere Abteilungen sie weniger wichtig finden.

Workshop 3: Kriterien anhand realer Szenarien validieren.

Im dritten Termin wird geprüft, ob die priorisierten Anforderungen zusammenpassen und ausreichend präzise sind. Dafür eignen sich konkrete End-to-End-Abläufe, etwa die Bearbeitung eines Kundenauftrags vom Eingang bis zur Rechnungsstellung.

Eine unklare Formulierung wie «Die Software muss einfach bedienbar sein» wird durch überprüfbare Kriterien ersetzt. Beispielsweise lässt sich festlegen, welche Benutzerrolle einen bestimmten Vorgang ohne zusätzliche Berechtigungen abschliessen können muss.

Das abschliessende Selektionsdokument sollte jede Muss-Anforderung mit einer verantwortlichen Fachperson und einer vorgesehenen Prüfmethode verbinden. So kann später nachvollzogen werden, ob ein Anbieter die Anforderung tatsächlich erfüllt.

Diese Dokumentation bildet zugleich die Grundlage für die neun SaaS-Auswahlkriterien. Sie verhindert, dass ein Produkt wegen einer überzeugenden Präsentation bevorzugt wird, obwohl zentrale Anforderungen ungeprüft geblieben sind.

Mit dieser gemeinsamen Entscheidungsgrundlage lässt sich anschliessend klären, ob vier Abteilungen besser auf einer Plattform arbeiten oder unterschiedliche spezialisierte Anwendungen einsetzen sollten.

Welche Unternehmenssoftware passt, wenn 4 Abteilungen unterschiedliche Anforderungen haben?

Wenn vier Abteilungen unterschiedliche Anforderungen haben, hängt die geeignete Unternehmenssoftware vor allem von ihren gemeinsamen Prozessen und Daten ab. Eine integrierte Plattform ist häufig sinnvoll, wenn Informationen abteilungsübergreifend genutzt werden. Spezialisierte Best-of-Breed-Anwendungen können besser passen, wenn Prozesse weitgehend unabhängig sind und zuverlässige Schnittstellen zur Verfügung stehen.

Die Entscheidung sollte daher nicht damit beginnen, welche Abteilung die meisten Funktionen benötigt. Wichtiger ist die Frage, wie stark die Geschäftsprozesse voneinander abhängen.

Ein Unternehmen, in dem Vertrieb, Auftragsbearbeitung, Produktion und Buchhaltung dieselben Kunden- und Auftragsdaten verwenden, profitiert möglicherweise von einer gemeinsamen Datenbasis. Änderungen können dadurch einheitlicher verarbeitet werden, sofern die Plattform den gesamten Prozess tatsächlich unterstützt.

Anders liegt die Situation, wenn einzelne Abteilungen weitgehend eigenständige Aufgaben erfüllen. Eine spezialisierte Anwendung kann dann funktional geeigneter sein, solange erforderliche Daten sicher und zuverlässig ausgetauscht werden können.

Bei vier Abteilungen braucht es ausserdem eine verbindliche Entscheidungsstruktur. Die Geschäftsführung oder eine beauftragte IT-verantwortliche Person sollte festlegen, welche Anforderungen unternehmensweit Vorrang haben und wie Konflikte gelöst werden.

Eine geeignete Governance muss keine zusätzliche Hierarchie schaffen. Entscheidend sind klar dokumentierte Zuständigkeiten für Budget, Datenschutz, technische Integration, Betrieb und endgültige Produktauswahl. Auch die Verantwortung für spätere Lizenzanpassungen und Vertragsverlängerungen gehört dazu.

Statt alle vier Abteilungen gleichzeitig umzustellen, empfiehlt sich ein begrenzter Pilot in einem Bereich mit klaren Anforderungen. Vorab sollten die zu prüfenden Prozesse, Erfolgskriterien, Verantwortlichkeiten und Bedingungen für einen Abbruch feststehen.

Der Pilot sollte nicht ausschliesslich zeigen, ob Mitarbeitende die Oberfläche akzeptieren. Ebenso wichtig sind Datenqualität, Berechtigungsverwaltung, Integration in bestehende Abläufe und die tatsächlichen Betriebskosten. Werden dabei Schwächen erkannt, können sie vor einer breiteren Einführung berücksichtigt werden.

Nach dem Pilot werden die Ergebnisse mit dem ursprünglichen Kriterienkatalog abgeglichen. Erst danach sollte die Reihenfolge für weitere Abteilungen festgelegt werden. Bei stark miteinander verknüpften Geschäftsprozessen kann ein gemeinsamer Rollout mehrerer Teilbereiche notwendig sein; bei unabhängigen Anwendungen ist eine gestaffelte Einführung häufig einfacher.

Als nächster Schritt sollte das Unternehmen für einen konkreten Geschäftsprozess eine verantwortliche Person bestimmen, die wichtigsten Muss-Anforderungen dokumentieren und einen begrenzten Praxistest vorbereiten. So wird aus der Softwarediskussion eine überprüfbare Entscheidung, ohne vorschnell neue langfristige Verpflichtungen einzugehen.