Eine Mitarbeiterin erklärt Kollegen am Arbeitsplatz eine neue Softwarefunktion auf einem Laptop.
Publié le 16 octobre 2026

Neue Funktionen erscheinen in vielen SaaS-Anwendungen automatisch. Was technisch bereits verfügbar ist, muss im Arbeitsalltag jedoch noch lange nicht sinnvoll eingesetzt werden. Mitarbeitende arbeiten mit vertrauten Abläufen weiter, während neue Einstellungen, zusätzliche Automatisierungen oder veränderte Oberflächen unbemerkt bleiben. Werden mehrere Änderungen gleichzeitig aktiviert, können Unsicherheit, Supportaufwand und Fehler entstehen.

Für Schweizer Unternehmen mit regelmässigen Softwareupdates liegt die Herausforderung deshalb weniger in der Freischaltung selbst als in der kontrollierten Übernahme neuer Funktionen. Entscheidend sind ein erkennbarer Nutzen, klare Zuständigkeiten, passende Einführungszeitpunkte und überprüfbare Freigabekriterien.

Eine praktikable Vorgehensweise trennt die technische Bereitstellung von der organisatorischen Einführung. Zunächst wird geprüft, welche Prozesse betroffen sind und welche Risiken bestehen. Danach testet eine begrenzte Nutzergruppe die Funktion unter realistischen Bedingungen. Erst wenn Ergebnisse und Rückmeldungen stimmen, folgt die breitere Nutzung. So können Verbesserungen eingeführt werden, ohne laufende Geschäftsabläufe unnötig zu destabilisieren.

Neue Softwarefunktionen kontrolliert einführen

  • Neue Funktionen anhand ihres konkreten Nutzens und ihrer Auswirkungen auf bestehende Arbeitsabläufe priorisieren.
  • Kritische Änderungen zuerst mit einer Pilotgruppe testen und die Freigabe an nachvollziehbare Kriterien knüpfen.
  • Verantwortlichkeiten, Kommunikation und Schnittstellenkontrollen festlegen, bevor weitere Mitarbeitende die Funktion nutzen.

Warum ignorieren Mitarbeitende neue Softwarefunktionen nach Updates?

Mitarbeitende nutzen neue Softwarefunktionen häufig nicht, weil sie deren Existenz, Nutzen oder Anwendung im eigenen Arbeitsablauf nicht kennen. Das bedeutet nicht automatisch, dass sie Veränderungen ablehnen. Oft fehlen eine verständliche Einführung, ein konkreter Anwendungsfall oder eine zuständige Ansprechperson. Bestehende Gewohnheiten bleiben deshalb erhalten, selbst wenn eine neue Funktion Arbeitsschritte vereinfachen könnte.

Bei automatisch eingespielten SaaS-Updates fällt eine neue Funktion möglicherweise nur durch einen zusätzlichen Menüpunkt auf. Wer gerade einen Kundenauftrag bearbeitet oder einen Monatsabschluss vorbereitet, beschäftigt sich normalerweise nicht mit jeder Änderung der Softwareoberfläche. Eine allgemeine Update-Mitteilung reicht deshalb selten aus, um den Nutzen im jeweiligen Arbeitskontext verständlich zu machen.

Hinzu kommen eingespielte Arbeitsgewohnheiten. Ein Team exportiert beispielsweise seit Jahren Daten nach Excel, um einen bestimmten Bericht zu erstellen. Wird später eine integrierte Berichtsfunktion bereitgestellt, bleibt der Export möglicherweise bestehen. Die neue Funktion muss nicht nur erklärt werden: Mitarbeitende sollten am eigenen Beispiel erkennen können, welche Schritte dadurch entfallen und ob das Ergebnis ihren Anforderungen entspricht.

Auch fehlende Verantwortlichkeiten können die Nutzung bremsen. Gerade in kleineren Unternehmen mit kurzen Entscheidungswegen ist nicht immer festgelegt, wer neue Funktionen bewertet, Fragen beantwortet und Rückmeldungen sammelt. Ein benannter Key User pro betroffenem Team kann diese Lücke schliessen, ohne eine umfangreiche Projektorganisation aufzubauen.

Das Schweizer KMU-Portal des SECO betont in seinen Informationen zu den Ressourcen für die digitale Transformation, dass neben der Technologie auch Prozesse, Kompetenzen und personelle Ressourcen berücksichtigt werden müssen. Die Weiterbildung von Mitarbeitenden gehört zur organisatorischen Vorbereitung. Die Quelle liefert allerdings keine spezifische Erfolgsquote für die Einführung einzelner Softwarefeatures.

Ein kurzer Selbstdiagnose-Check hilft, eine schwache Einführung zu erkennen:

  • Nach einem Monat wird die neue Funktion im betroffenen Team kaum erwähnt, obwohl sie für dessen Aufgaben relevant wäre.
  • Supportanfragen betreffen weiterhin Probleme, die die neue Funktion möglicherweise lösen könnte.
  • Bestehende Excel-Dateien, manuelle Übertragungen oder andere Umwege bleiben unverändert im Einsatz.

Diese Beobachtungen beweisen für sich allein keine Ablehnung. Sie sind Anlass, mit Mitarbeitenden zu prüfen, ob die Funktion bekannt, verständlich, geeignet und tatsächlich hilfreich ist.

Ist der konkrete Bedarf geklärt, lässt sich die Einführung so planen, dass Mitarbeitende Neues ausprobieren können, ohne ihre laufende Arbeit unnötig zu gefährden.

Wie rollt man neue Funktionen aus, ohne laufende Prozesse zu stören?

Neue Softwarefunktionen lassen sich mit einer begrenzten Pilotgruppe, klaren Freigabekriterien und abgestimmten Aktivierungszeitpunkten kontrolliert ausrollen. Zuerst wird die Funktion in einem überschaubaren Arbeitsbereich getestet. Anschliessend werden Fehler, Nutzung und Rückmeldungen geprüft. Weitere Teams erhalten erst Zugang, wenn die definierten Voraussetzungen erfüllt sind und kritische Prozesse stabil bleiben.

Eine Pilotgruppe sollte nicht einfach aus den technisch versiertesten Mitarbeitenden bestehen. Geeignet ist ein Team, das die betroffenen Prozesse tatsächlich nutzt, Probleme zuverlässig dokumentieren kann und bei Schwierigkeiten auf einen bekannten bisherigen Ablauf zurückgreifen kann.

Vor dem Start werden der Testumfang, die verantwortliche Person und die Bedingungen für die nächste Ausrollstufe festgelegt. Bei einer neuen Freigabefunktion könnten beispielsweise die korrekte Rechtevergabe, die vollständige Bearbeitung eines Testvorgangs und das Ausbleiben ungeklärter kritischer Fehler zu diesen Bedingungen gehören.

Auch der Kommunikationsrhythmus beeinflusst die Einführung. Eine kurze Ankündigung vor der Freischaltung erklärt den Anlass und die betroffenen Aufgaben. Am Aktivierungstag erhalten Mitarbeitende eine kompakte Anleitung. Nach der ersten Nutzungswoche werden Fragen, Schwierigkeiten und mögliche Verbesserungen gesammelt. Dieser Ablauf ist eine praktische Organisationsmethode, keine durch eine allgemeingültige Studie festgelegte Frist.

Bei der Terminplanung müssen nicht nur interne Arbeitsspitzen berücksichtigt werden. Wenn neue Funktionen den Austausch mit Treuhändern, Banken, Geschäftspartnern oder Behörden verändern, sind auch deren Abläufe relevant. Änderungen an MWST-Exporten oder Abrechnungsdaten sollten beispielsweise vor dem produktiven Einsatz mit den tatsächlich betroffenen Schnittstellen geprüft werden.

Ein weiterer Punkt ist die Rückkehr zum bisherigen Zustand. Eine deaktivierbare Oberflächenfunktion lässt sich unter Umständen einfach abschalten. Werden hingegen Daten migriert, bestehende Datensätze verändert oder neue Buchungen ausgelöst, kann ein technischer Rollback erheblich schwieriger sein. Deshalb muss vor dem Pilotbetrieb feststehen, welche Änderungen rückgängig gemacht werden können und welche zusätzliche Sicherungen benötigen.

Die technischen Empfehlungen von Microsoft für sichere Softwarebereitstellungen beschreiben unter anderem Canary Deployments, Feature Flags, schrittweise Freigaben und Qualitätskontrollen zwischen den Stufen. Diese Verfahren setzen allerdings entsprechende technische Möglichkeiten voraus.

Checkliste für einen kontrollierten Feature-Rollout

  1. Betroffene Arbeitsabläufe und mögliche Fehlerfolgen erfassen. Ergebnis: eine dokumentierte Prozess- und Risikoliste.
  2. Eine Pilotgruppe mit zuständiger Ansprechperson auswählen. Ergebnis: eine verbindliche Teilnehmer- und Verantwortlichenliste.
  3. Testfälle und Freigabekriterien definieren. Ergebnis: ein nachvollziehbares Testprotokoll mit Bestehensbedingungen.
  4. Freischaltung, Kurzanleitung und Rückmeldetermin abstimmen. Ergebnis: ein kurzer Kommunikations- und Einführungsplan.
  5. Pilotergebnisse auswerten und über die nächste Stufe entscheiden. Ergebnis: eine dokumentierte Freigabe, Korrektur oder Verschiebung.

Wie schnell anschliessend weitere Teams freigeschaltet werden, hängt insbesondere von der Fehlerwirkung und den Abhängigkeiten der neuen Funktion ab.

Direkt freischalten oder schrittweise ausrollen: Was passt zu kritischen Funktionen?

Unkritische, leicht rückgängig zu machende Softwarefunktionen können häufig direkt für alle betroffenen Mitarbeitenden aktiviert werden. Bei Änderungen an Berechtigungen, Datenbeständen, Preisberechnungen oder automatisierten Buchungen ist ein schrittweiser Rollout meist sinnvoller. Entscheidend sind die Folgen möglicher Fehler und die Anzahl der voneinander abhängigen Arbeitsprozesse, nicht allein die technische Komplexität.

Eine sofortige Freischaltung hat einen organisatorischen Vorteil: Alle Teams arbeiten mit demselben Funktionsstand. Unterschiedliche Anleitungen und Übergangsregeln lassen sich vermeiden. Gleichzeitig betrifft ein möglicher Fehler sofort den gesamten freigeschalteten Nutzerkreis.

Ein gestaffelter Rollout begrenzt zunächst die Auswirkungen. Allerdings entstehen vorübergehend unterschiedliche Nutzungsmöglichkeiten, die koordiniert werden müssen. Besonders bei teamübergreifenden Abläufen darf diese Übergangsphase nicht zu widersprüchlichen Prozessregeln führen.

Für die Entscheidung lassen sich zwei Dimensionen kombinieren: Fehlerwirkung und Prozessabhängigkeit. Die folgende Matrix ist eine praktische Entscheidungshilfe, keine verbindliche technische Norm.

Entscheidungsmatrix für die Freischaltung neuer Softwarefunktionen
Fehlerwirkung und Abhängigkeit Geeignete Einführung Beispiel
Geringe Fehlerwirkung, isolierte Nutzung Direkte Freischaltung nach kurzem Funktionstest Optionale Anpassung einer persönlichen Ansicht
Geringe Fehlerwirkung, mehrere Teams betroffen Koordinierte Einführung mit gemeinsamer Kommunikation Neue teamübergreifende Suchoberfläche
Hohe Fehlerwirkung, isolierte Nutzung Begrenzter Pilot mit dokumentierter Kontrolle Änderung einer fachlichen Berechnungsregel
Hohe Fehlerwirkung, mehrere Teams betroffen Gestaffelter Rollout mit formeller Freigabe Neue Preislogik oder automatisierte Buchungsprozesse

Die Fehlerwirkung steigt insbesondere dann, wenn eine Funktion Daten dauerhaft verändert, externe Aktionen auslöst oder gesetzlich relevante Fristen beeinflussen kann. Auch eine vermeintlich kleine Änderung kann kritisch sein, wenn mehrere Systeme dieselben Daten weiterverarbeiten.

Zwischen den Ausrollstufen sollten technische Zustandsindikatoren und praktische Rückmeldungen gemeinsam betrachtet werden. Dazu gehören fehlgeschlagene Vorgänge, Datenabweichungen, Nutzungsmuster und Supportanfragen.

Sinkende Supportanfragen können auf eine stabilere Nutzung hindeuten. Sie reichen jedoch nicht als alleiniger Nachweis: Auch eine kaum verwendete Funktion erzeugt möglicherweise wenige Anfragen. Deshalb sollte überprüft werden, ob die vorgesehenen Arbeitsvorgänge tatsächlich erfolgreich abgeschlossen werden.

Eine Freigabe nach festen Kalendertagen ist weniger aussagekräftig als eine Freigabe nach erfüllten Prüfkriterien. Beobachtungsphasen müssen ausreichend Nutzung umfassen, damit auch seltenere Abläufe berücksichtigt werden.

Besonders kritisch wird die Entscheidung, wenn eine Funktion nicht nur Arbeitsoberflächen verändert, sondern eigenständig Aktionen ausführen oder Zugriffsrechte erweitern kann.

Welche neuen Features sollten nicht automatisch für alle Nutzer aktiviert werden?

Neue Funktionen sollten nicht automatisch für alle Mitarbeitenden aktiviert werden, wenn sie externe Aktionen auslösen, Zugriffsrechte verändern, Personendaten anders verarbeiten oder etablierte Geschäftsprozesse grundlegend beeinflussen. Solche Funktionen benötigen vor der Aktivierung eine fachliche und gegebenenfalls datenschutzrechtliche Prüfung. Eine rollenbezogene Freigabe reduziert das Risiko unbeabsichtigter Aktionen und unpassender Berechtigungen.

Besonders sorgfältig sollten Unternehmen drei Funktionsgruppen behandeln:

  • Automatisierte Aktionen nach aussen: Funktionen, die Zahlungen anstossen, Kunden benachrichtigen, Dokumente versenden oder Daten automatisch exportieren.
  • Änderungen an Berechtigungen: Neue Rollen, erweiterte Administratorfunktionen oder zusätzliche Zugriffsmöglichkeiten auf vertrauliche Informationen.
  • Veränderungen bestehender Standardprozesse: Automatische Freigaben, neue Genehmigungswege oder Funktionen, die bisherige Kontrollen ersetzen.

In Schweizer KMU liegt die technische Administration teilweise bei einer einzelnen Person. Diese kennt jedoch nicht zwangsläufig alle fachlichen Konsequenzen einer Funktion. Deshalb sollte die technische Aktivierung von der fachlichen Freigabe unterschieden werden.

Ein einfacher Freigabeprozess kann festlegen, wer den geschäftlichen Nutzen beurteilt, wer Berechtigungen kontrolliert und wer die Funktion tatsächlich einschaltet. Bei sensiblen Änderungen ist zusätzlich eine unabhängige Kontrolle zweckmässig.

Werden Personendaten verarbeitet, müssen die jeweils anwendbaren Datenschutzanforderungen berücksichtigt werden. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte stellt Informationen des EDÖB zu Informationssicherheit und Datenschutzmassnahmen bereit. Dazu gehören Hinweise zu technischen und organisatorischen Schutzmassnahmen sowie zur Protokollierung nach den einschlägigen Voraussetzungen der schweizerischen Datenschutzverordnung.

Eine neue Funktion kann beispielsweise zusätzliche Datenfelder an einen externen Dienst übertragen oder bisher getrennte Benutzerrollen zusammenführen. Vor der Aktivierung ist dann zu klären, welche Personendaten betroffen sind, wer darauf zugreifen darf und welche Sicherheitsmassnahmen erforderlich sind. Eine allgemeine Pflicht zur vollständigen Protokollierung sämtlicher Softwareaktivitäten lässt sich daraus nicht ableiten.

Auch Aufbewahrungsfunktionen verdienen Aufmerksamkeit. Werden Löschfristen oder Archivierungsprozesse verändert, sind neben dem Datenschutz gegebenenfalls die einschlägigen buchführungsrechtlichen Anforderungen zu prüfen.

Für die laufende Kontrolle genügt häufig eine übersichtliche interne Feature-Liste mit folgenden Feldern:

Beispiel einer internen Feature-Freigabeliste
Eintrag Zweck
Feature und betroffene Anwendung Änderung eindeutig identifizieren
Status: aktiv, testweise oder gesperrt Aktuellen Freigabestand dokumentieren
Freigegebene Rollen Nutzerkreis begrenzen
Verantwortliche Person Entscheidungen und Rückfragen zuordnen
Prüfdatum und Entscheid Spätere Kontrollen nachvollziehbar machen

Diese Liste sollte nach relevanten Anbieterupdates überprüft werden, insbesondere wenn neue Funktionen automatisch verfügbar werden oder sich Standardeinstellungen ändern.

Nach der Entscheidung über Berechtigungen und Risiken stellt sich die nächste Frage: Wann passt die Einführung am besten zum tatsächlichen Arbeitsrhythmus?

Wann sollte ein neues Softwarefeature nach Veröffentlichung eingesetzt werden?

Ein neues Softwarefeature sollte eingesetzt werden, sobald sein Nutzen geklärt, die relevanten Tests abgeschlossen und die betroffenen Arbeitsabläufe für die Umstellung geeignet sind. Das Veröffentlichungsdatum allein ist kein ausreichendes Kriterium. Bei geschäftskritischen Prozessen ist häufig der Beginn eines neuen Arbeitszyklus günstiger als eine Einführung während laufender Abschlüsse oder anderer intensiver Betriebsphasen.

Zwischen technischer Verfügbarkeit und produktiver Nutzung besteht ein wichtiger Unterschied. Ein Anbieter kann eine Funktion bereitstellen, während das Unternehmen deren Einsatz bewusst auf einen geeigneten Zeitpunkt verschiebt. Ob diese Trennung technisch möglich ist, hängt von der jeweiligen SaaS-Anwendung ab.

Bei Funktionen für die Buchhaltung bietet sich beispielsweise die Prüfung nach einem abgeschlossenen Monatsabschluss an. Eine Änderung, die den gesamten Abrechnungsprozess betrifft, lässt sich unter Umständen besser zu Beginn der nächsten Periode einführen. So kann ein vollständiger Durchlauf unter den neuen Bedingungen beobachtet werden.

Auch bei mehreren gleichzeitig veröffentlichten Funktionen ist eine Reihenfolge sinnvoll:

  1. Grundlegende Funktionen zuerst einführen, wenn weitere Neuerungen technisch oder organisatorisch davon abhängen.
  2. Unabhängige, risikoarme Verbesserungen bei ausreichender Betreuung parallel zulassen.
  3. Mehrere Änderungen am selben kritischen Prozess zeitlich trennen, damit Fehlerursachen erkennbar bleiben.

Vor dem Rollout sollte die neue Funktion mit realistischen, aber unkritischen Daten geprüft werden. Geeignet sind beispielsweise ein Testmandat, ein abgeschlossener Vorgang oder eine vom Produktivsystem getrennte Testumgebung.

Bei Schweizer Lohn- und Sozialversicherungsanwendungen können unternehmensspezifische Stammdaten und kantonale Besonderheiten relevant sein. Die Prüfung muss deshalb über eine reine Demonstration mit Standarddaten hinausgehen, sofern solche Besonderheiten den betroffenen Prozess tatsächlich beeinflussen.

Eine kurze Nutzbarkeitsprüfung sollte bestätigen, dass Eingaben korrekt verarbeitet werden, erwartete Ergebnisse entstehen und bestehende Folgeprozesse weiterhin funktionieren. Kritische Sicherheitskorrekturen sind gesondert zu behandeln: Sie können eine beschleunigte Aktualisierung erfordern, auch wenn der betriebliche Zeitpunkt nicht ideal ist.

Damit solche Entscheidungen nicht von einzelnen Mitarbeitenden oder zufälligen Update-Meldungen abhängen, braucht es eine koordinierte Steuerung der Aktualisierungen.

Wie führt man Softwareupdates zentral aus, ohne den Betrieb unnötig zu unterbrechen?

Softwareupdates lassen sich durch zentrale Zuständigkeiten, abgestimmte Wartungsfenster und klare Kommunikation mit möglichst geringen Betriebsstörungen durchführen. Entscheidend ist, zwischen Updates zu unterscheiden, deren Zeitpunkt das Unternehmen selbst kontrolliert, und SaaS-Aktualisierungen, die der Anbieter vorgibt. Für beide Fälle sollten betroffene Prozesse, technische Abhängigkeiten und Kontrollen nach der Aktualisierung festgelegt werden.

Bei dezentral verwalteter Software können Mitarbeitende unterschiedliche Versionen verwenden. Dadurch unterscheiden sich möglicherweise Oberflächen, Funktionen oder Dateiformate. Schulungen und Support werden schwieriger, weil nicht alle Personen mit demselben Systemstand arbeiten.

Eine zentrale Update-Verantwortung schafft Transparenz darüber, welche Versionen eingesetzt werden, welche Änderungen bevorstehen und wer ihre Auswirkungen beurteilt. Das bedeutet nicht, dass jede Aktualisierung manuell installiert werden muss.

Bei Cloud-SaaS bestimmt häufig der Anbieter den technischen Zeitpunkt. Das Unternehmen kann dann vor allem Benachrichtigungen auswerten, verfügbare Konfigurationsmöglichkeiten nutzen und die organisatorische Einführung planen. Bei On-Premise-Systemen oder steuerbaren Release-Fenstern bestehen meist weitergehende Möglichkeiten zur Terminplanung.

Ein geeignetes Update-Fenster orientiert sich an der tatsächlichen Nutzung. Eine nächtliche Aktualisierung ist beispielsweise nicht automatisch unproblematisch, wenn zu dieser Zeit Datenübertragungen, automatisierte Buchungen oder Schnittstellenläufe stattfinden.

Im Schweizer Geschäftsalltag können auch Verbindungen zu Banken, Treuhändern und Behörden relevant sein. Deshalb sollten die verantwortlichen Fachbereiche bestätigen, dass während des vorgesehenen Fensters keine kritischen Übermittlungen oder Verarbeitungsschritte beeinträchtigt werden.

Die Kommunikation vor dem Update muss vor allem drei Fragen beantworten:

  • Was verändert sich konkret an den eigenen Aufgaben?
  • Welche bisherigen Abläufe bleiben unverändert?
  • An wen können sich Mitarbeitende bei Schwierigkeiten wenden?

Nach der Aktualisierung werden die wichtigsten Funktionen und Schnittstellen geprüft. Dazu gehören die Erreichbarkeit des Systems, die Verarbeitung ausgewählter Geschäftsvorgänge und die Kontrolle möglicher Fehlermeldungen.

Technische Architekturleitfäden zu SaaS-Aktualisierungen weisen darauf hin, dass Wartungsfenster, unterschiedliche Softwareversionen und die Überwachung des Systemzustands gemeinsam betrachtet werden sollten. Allerdings kann ein SaaS-Kunde die vom Anbieter vorgesehenen Aktualisierungsmechanismen nicht beliebig verändern.

Wenn trotz kontrollierter Aktualisierungen dauerhaft Funktionslücken, Doppelarbeit oder Integrationsprobleme bestehen, sollte nicht nur das nächste Update, sondern auch die bestehende Softwarelandschaft hinterfragt werden.

Wann sollte ein bestehender SaaS-Dienst ersetzt oder konsolidiert werden?

Ein bestehender SaaS-Dienst sollte ersetzt oder mit anderen Anwendungen zusammengeführt werden, wenn er wichtige Geschäftsprozesse dauerhaft nicht mehr unterstützt, erhebliche funktionale Überschneidungen verursacht oder unverhältnismässigen Betriebsaufwand erzeugt. Vor einem Wechsel müssen jedoch Integrationen, Datenmigration, Vertragsbedingungen und fachliche Anforderungen geprüft werden. Weniger Anwendungen bedeuten nicht automatisch bessere Prozesse.

Ein sinnvoller Ausgangspunkt ist die Frage, welche Aufgabe jede Anwendung tatsächlich erfüllt. Zwei Programme können ähnliche Funktionen anbieten, aber unterschiedliche Anforderungen einzelner Fachbereiche abdecken.

Für eine Konsolidierung sprechen insbesondere folgende Beobachtungen:

  • Dieselben Daten werden dauerhaft in mehreren Anwendungen gepflegt.
  • Wesentliche Prozesse lassen sich mit dem bestehenden Dienst nicht mehr angemessen abbilden.
  • Notwendige Funktionen werden vom Anbieter nicht weiterentwickelt oder bleiben dauerhaft unzureichend.
  • Der zuverlässige Betrieb hängt von einer einzelnen Person mit nicht dokumentiertem Spezialwissen ab.

Eine Konsolidierung sollte deshalb nicht ausschliesslich auf Lizenzkosten ausgerichtet sein. Weniger Systeme können Berechtigungen, Datenflüsse und Support vereinfachen. Gleichzeitig kann eine spezialisierte Anwendung fachliche Funktionen bereitstellen, die in einer allgemeinen Plattform fehlen.

Vor der Entscheidung empfiehlt sich eine Gegenüberstellung der betroffenen Prozesse, ihrer Schnittstellen und der tatsächlich benötigten Funktionen. Dabei sollten Fachabteilungen bestätigen, welche Anforderungen unverzichtbar sind.

Ein vollständiger SaaS-Wechsel bringt zusätzliche Risiken mit sich. Historische Daten müssen möglicherweise migriert werden, bestehende Exporte müssen weiterhin lesbar sein und vertragliche Kündigungs- sowie Datenherausgabebedingungen sind zu berücksichtigen.

Während einer Übergangsphase kann zudem parallele Datenpflege notwendig werden. Ohne klare Zuständigkeit besteht die Gefahr, dass sich Datenbestände auseinanderentwickeln.

Für Schweizer Unternehmen müssen relevante landesspezifische Abläufe im Zielsystem vor der Abschaltung des bisherigen Dienstes geprüft werden. Dazu können beispielsweise MWST-Exporte oder Schnittstellen für AHV-bezogene Abrechnungsprozesse gehören. Welche Anforderungen gelten, hängt von der konkreten Anwendung und dem betroffenen Geschäftsprozess ab.

Eine oft weniger aufwendige Alternative besteht darin, zunächst vorhandene Funktionen bereits eingeführter Anwendungen zu prüfen. Wenn ein bestehendes System einen bislang separat bearbeiteten Prozess zuverlässig übernehmen kann, ist möglicherweise keine vollständige Neueinführung erforderlich.

Die Entscheidung sollte auf dokumentierten Prozessanforderungen, nachgewiesener Funktionsabdeckung und einem realistischen Übergangsplan beruhen.

Unabhängig davon, ob Anwendungen bestehen bleiben oder zusammengeführt werden, hängt ihre Zuverlässigkeit wesentlich davon ab, wie Daten zwischen ihnen übertragen und kontrolliert werden.

Das Wichtigste für die nächste Entscheidung

  • Vor jeder Änderung klären, welche Anwendung für welche Daten verantwortlich ist und welche nachgelagerten Prozesse davon abhängen.
  • Bei der Einführung neuer Funktionen nicht nur die Oberfläche testen, sondern auch bestehende Datenübertragungen berücksichtigen.
  • Für kritische Schnittstellen überprüfbare Abgleich- und Fehlerbehandlungsverfahren vorsehen, bevor der produktive Einsatz erweitert wird.

Wie organisiert man zuverlässigen Datenaustausch zwischen Anwendungen?

Zuverlässiger Datenaustausch zwischen Anwendungen benötigt ein passendes Übertragungsverfahren, eindeutig festgelegte Datenverantwortlichkeiten und regelmässige Kontrollen. Unternehmen sollten bestimmen, welches System für jeden wichtigen Datenbestand führend ist, wie Informationen übertragen werden und wie Übertragungsfehler erkannt werden. Bei neuen Softwarefunktionen müssen bestehende Schnittstellen vor der produktiven Nutzung erneut geprüft werden.

Die technische Umsetzung hängt davon ab, wie häufig Daten übertragen werden, wie aktuell sie sein müssen und welche Fehlerfolgen entstehen können. Nicht jeder Datenaustausch benötigt eine Echtzeitintegration.

Drei grundlegende Austauschmodelle kommen infrage:

Modelle für den Datenaustausch zwischen Geschäftsanwendungen
Austauschmodell Geeigneter Einsatz Wichtige Grenze
Manueller Export und Import Seltene, bewusst kontrollierte Übertragungen Manueller Aufwand und mögliche Bedienungsfehler
Regelmässige dateibasierte Schnittstelle Wiederkehrende Übertragung strukturierter Daten Abhängigkeit von Dateiformat, Zeitplan und Fehlerbehandlung
API-Integration Häufige oder zeitnahe Datenübertragung Höherer Einrichtungs-, Überwachungs- und Wartungsbedarf

Die Wahl des Verfahrens löst allerdings nicht das grundlegende Problem der Datenverantwortung. Werden beispielsweise Kundenadressen in einem CRM-System und gleichzeitig in einer Buchhaltungssoftware gepflegt, muss feststehen, welches System den verbindlichen Datenstand liefert.

Ohne diese Festlegung können widersprüchliche Datensätze entstehen. Eine Aktualisierung in einem System wird möglicherweise bei der nächsten Übertragung überschrieben oder führt zu fehlerhaften Folgeprozessen.

Für zentrale Datenobjekte wie Kundenstamm, Artikelstamm oder Preisliste sollte deshalb dokumentiert werden, wo Änderungen vorgenommen werden dürfen und in welche Richtung sie weitergegeben werden.

Ebenso wichtig ist die Kontrolle nach jeder relevanten Übertragung. Je nach Datenart können Datensatzzahlen, Summen oder ausgewählte Einzelvorgänge zwischen Quell- und Zielsystem verglichen werden. Bei Buchungsdaten kann beispielsweise eine Abstimmung der übertragenen Beträge sinnvoll sein.

Ein reiner Vergleich der Datensatzzahlen erkennt allerdings nicht jeden Fehler. Datensätze können inhaltlich falsch oder doppelt vorhanden sein, obwohl die Gesamtzahl plausibel erscheint. Für kritische Daten sollten deshalb zusätzliche Plausibilitätsprüfungen und ein nachvollziehbarer Umgang mit Fehlermeldungen vorgesehen werden.

Neue Softwarefunktionen können bestehende Integrationen verändern, selbst wenn die eigentliche Schnittstelle nicht ausdrücklich Bestandteil des Updates ist. Ein zusätzliches Pflichtfeld, ein geändertes Datenformat oder eine neue Validierungsregel kann dazu führen, dass zuvor funktionierende Übertragungen fehlschlagen.

Vor grösseren Änderungen sollte deshalb feststehen, welche Anwendungen Daten mit dem aktualisierten System austauschen. Anschliessend werden die betroffenen Übertragungen mit geeigneten Testdaten geprüft und die Ergebnisse dokumentiert.

Bei einer schrittweisen Feature-Einführung gehört diese Schnittstellenprüfung zu den Freigabekriterien. Erst wenn Datenübertragung, Verarbeitung und Abgleich zuverlässig funktionieren, sollte die nächste Nutzergruppe freigeschaltet werden.

Als nächster Schritt empfiehlt sich, für das bevorstehende Softwareupdate eine verantwortliche Person zu benennen, die betroffenen Datenflüsse zu erfassen und einen vollständigen Testvorgang mit dokumentiertem Ergebnis durchzuführen. Damit wird aus einer technischen Freischaltung eine überprüfbare Einführung im laufenden Betrieb.

Häufige Fragen zur Einführung neuer Softwarefunktionen
Wer sollte in einem kleinen Unternehmen für neue Softwarefunktionen verantwortlich sein?

Sinnvoll ist eine klar benannte Person, die den fachlichen Nutzen beurteilt und Rückmeldungen koordiniert. Die technische Aktivierung kann bei der IT oder einer administrierenden Person liegen. Bei risikoreichen Funktionen sollten fachliche Freigabe und technische Umsetzung bewusst aufeinander abgestimmt werden.

Wie erkennt man, ob eine neue Funktion tatsächlich angenommen wurde?

Neben verfügbaren Nutzungsdaten sollten abgeschlossene Arbeitsvorgänge, Rückmeldungen der Mitarbeitenden und die Entwicklung bisheriger Umwege betrachtet werden. Eine hohe Zahl von Anmeldungen allein beweist keinen Nutzen. Entscheidend ist, ob die Funktion die vorgesehene Aufgabe zuverlässig unterstützt.

Was tun, wenn ein SaaS-Anbieter neue Funktionen automatisch aktiviert?

Zunächst sollten die verfügbaren Einstellungen für Rollen, Berechtigungen und Funktionsaktivierung geprüft werden. Ist eine separate Deaktivierung nicht möglich, gewinnen die frühzeitige Auswertung von Release-Mitteilungen, interne Kommunikation und Tests betroffener Abläufe an Bedeutung. Bei kritischen Auswirkungen sollte der Anbieter nach verfügbaren Steuerungs- oder Übergangsmöglichkeiten gefragt werden.

Wie viel Schulung benötigen Mitarbeitende für ein neues Softwarefeature?

Der Schulungsumfang hängt von der Komplexität, der Nutzungshäufigkeit und den möglichen Fehlerfolgen ab. Für eine kleine Oberflächenänderung kann eine kurze Anleitung genügen. Bei veränderten Freigabe- oder Buchungsprozessen sind praktische Übungen mit realistischen Testfällen und eine erreichbare Ansprechperson zweckmässiger.

Wann sollte die Einführung einer neuen Funktion gestoppt werden?

Die weitere Freischaltung sollte ausgesetzt werden, wenn kritische Fehler auftreten, Daten nicht zuverlässig verarbeitet werden oder festgelegte Freigabekriterien unerfüllt bleiben. Anschliessend ist zu entscheiden, ob eine Korrektur, eine Anpassung des Prozesses oder eine technisch mögliche Rückkehr zum bisherigen Zustand erforderlich ist.

Rédigé par Daniel Baumann, Dokumentarrechercheur mit Fokus auf Cloud-Software, SaaS und digitale Betriebsmodelle. Er untersucht technische Konzepte, Kostenstrukturen und Bereitstellungsvarianten anhand vergleichbarer Kriterien. Damit erhalten Leser eine belastbare Orientierung zu Cloud-, Lizenz- und Infrastrukturfragen.