Übermäßige Abhängigkeit vom Softwareanbieter vermeiden: was zu vereinbaren ist

Die Abhängigkeit von einem Softwareanbieter bemerkt man nicht, solange die Zusammenarbeit funktioniert. Sie zeigt sich an dem Tag, an dem etwas geändert werden muss — der Anbieter, das Abonnement oder die Person, die das Projekt betreut hat —, und niemand im Unternehmen sagen kann, wo die Daten liegen, auf wessen Namen die Dienste registriert sind und was nötig ist, um sie anderswo zum Laufen zu bringen. Das ist keine Frage des Vertrauens: Es ist eine Frage der Bestandsaufnahme, und die macht man heute, mit einem Anbieter, dem man vertraut.

Das Ziel ist nicht, morgen den Anbieter wechseln zu können. Es ist, dass Bleiben eine Wahl ist und nicht der einzig gangbare Weg.

Die Bestandsaufnahme: was existiert, und auf wessen Namen

Die erste Übung ist eine Liste. Sie wird einmal erstellt, bei jeder Änderung aktualisiert und deckt die Stellen auf, an denen das Unternehmen nicht Inhaber dessen ist, was es täglich nutzt.

Die Daten: Exportieren allein genügt nicht, es braucht die Beziehungen

Ein Export der Kunden in eine Tabellenkalkulation ist eine Namensliste, nicht Ihr Archiv. Ein Archiv besteht aus Verknüpfungen, und die Verknüpfungen sind der Teil, der zuerst verloren geht.

• Die Kennungen: Haben Kunden einen internen Code, muss dieser auch in den Bestellexporten erscheinen, sonst ist das erneute Verknüpfen Handarbeit.
• Die Historie: frühere Zustände, Änderungsdaten, wer was getan hat. Oft wird nur der letzte Zustand exportiert.
• Die Anhänge: Verträge, Fotos, unterschriebene Dokumente. Das sind Dateien, keine Zeilen, und müssen mit der Angabe exportiert werden, womit sie verknüpft waren.
• Die berechneten Felder: Summen, Fristen, Punktwerte. Werden sie nicht bewahrt, müssen sie anhand der Formel rekonstruiert werden, die deshalb irgendwo aufgeschrieben sein muss.
• Das Format: offen und lesbar ohne das Programm, das es erzeugt hat. Ein in ein proprietäres Format exportiertes Archiv hängt weiterhin von demselben Werkzeug ab.

Support, Wartung und Weiterentwicklung sind drei verschiedene Dinge

Sie müssen mit drei unterschiedlichen Namen bezeichnet werden, sonst stellt sich erst im Bedarfsfall heraus, dass das Benötigte nicht in der Gebühr enthalten war.

• Support: eine Störung beheben. Es muss festgelegt werden, was eine Störung ist, wie sie gemeldet wird und mit welchen Reaktionszeiten.
• Wartung: Aktualisierung der Komponenten, Sicherheit, Anpassungen, wenn sich etwas im Umfeld ändert. Es muss festgelegt werden, wer über ihre Durchführung entscheidet und ob sie enthalten ist.
• Weiterentwicklung: Änderungen und neue Funktionen. Es muss festgelegt werden, wie sie geschätzt werden und wer sie freigibt.
• Übergabe: was übergeben wird, in welcher Zeit und in welcher Form, falls die Zusammenarbeit endet. Das ist der Punkt, den fast niemand zu Beginn schriftlich festhält, also dann, wenn man leicht ohne Spannung darüber sprechen kann.

Der Test: ein echter Export, mindestens einmal

Eine Liste nie getesteter Garantien ist wenig wert. Die Prüfung kostet einen halben Tag und muss durchgeführt werden, wenn alles gut läuft, nicht dann, wenn sie gebraucht wird.

1. Verlangen Sie einen vollständigen Datenexport, keine von anderen ausgewählte Stichprobe.
2. Öffnen Sie ihn auf einem Unternehmenscomputer, ohne vom Anbieter geliehene Werkzeuge zu verwenden.
3. Nehmen Sie drei echte, komplexe Fälle — einen Kunden mit vielen Bestellungen, einen Vorgang mit Anhängen, einen Fall mit langer Historie — und rekonstruieren Sie sie aus den Dateien. Gelingt das nicht, ist der Export unvollständig.
4. Versuchen Sie, eine Sicherungskopie in einer getrennten Umgebung wiederherzustellen. Eine nie wiederhergestellte Sicherung ist eine Sicherung, über die man nichts weiß.
5. Schreiben Sie auf, was fehlt und was sich nicht rekonstruieren lässt: Diese Liste ist das eigentliche Ergebnis des Tests.

Ein beispielhaftes Übergabepaket

Illustrativ, an die Größe des Projekts anzupassen. Es ist die Liste dessen, was im Unternehmen existieren und aktuell bleiben sollte, unabhängig davon, wer es pflegt.

• Liste der Zugänge, mit dem jeweils angegebenen Unternehmensinhaber.
• Adresse des Code-Archivs, sofern die Übergabe im Vertrag vorgesehen ist, mit Anleitung zum Start.
• Beschreibung der Architektur auf wenigen Seiten: welche Teile es gibt und wie sie miteinander kommunizieren.
• Liste der Komponenten Dritter und der jeweiligen Nutzungsbedingungen.
• Verfahren für die Sicherungskopien: wo sie liegen, wie oft, wie lange sie aufbewahrt werden, wie sie wiederhergestellt werden.
• Eine Stichprobe des Datenexports mit Erklärung der Felder.
• Die operativen Kontakte und was im Falle einer Blockade zu tun ist.

Was dieser Leitfaden nicht abdeckt

Hier geht es um technische Kontinuität: Zugänge, Daten, Dokumentation, Tests. Das Eigentum am Code, die Nutzungsrechte, die Vertragsklauseln und die Kündigungsbedingungen liegen auf einer anderen Ebene und müssen im Vertrag und mit einer Rechtsberatung geprüft werden, denn was hier als verfügbar beschrieben wird, hängt in erster Linie davon ab, was in der Vereinbarung festgehalten wurde. Die Wahl zwischen Standard-Verwaltungssoftware und individueller Software sowie die Kontrollen zu Berechtigungen und Sicherungskopien haben eigene Leitfäden.