Zum Hauptinhalt springen

Guide

ISMS-Pilotprojekt: Teste den Arbeitsablauf, nicht nur die Oberfläche

Prüfe ISMS-Software an einem echten Fall: Verantwortung übergeben, einen Nachweis ersetzen und eine offene Maßnahme bis zur Entscheidung verfolgen.

ISMS-Pilotprojekt: Teste den Arbeitsablauf, nicht nur die Oberfläche
Julian Köhn
|Lesezeit: 4 Minuten

Eine Demo zeigt, was eine Software kann. Ein Pilot zeigt, ob euer Team damit arbeiten kann. Dafür braucht ihr keine Kopie eures gesamten ISMS. Ihr braucht einen begrenzten Fall, klare Erwartungen und Menschen, die den Ablauf später tatsächlich nutzen.

Dieser Testplan ist unsere praktische Empfehlung für die Softwareauswahl. Er setzt keine feste Pilotdauer voraus. Für den grundsätzlichen Kriterienvergleich findest du hier den Leitfaden zu ISMS-Software. Im Pilot geht es um die Anwendung dieser Kriterien.

Wähle einen Fall mit einer echten Übergabe

Nimm einen bereits bekannten Arbeitsablauf. Zum Beispiel: Ein Wiederherstellungstest zeigt eine Lücke. Eine verantwortliche Person soll sie bearbeiten, einen neuen Nachweis hinterlegen und das Ergebnis prüfen lassen.

Der Fall sollte mindestens zwei Rollen und eine Entscheidung enthalten. Wenn nur eine Person Daten einträgt und dieselbe Person alles freigibt, prüft ihr die Zusammenarbeit kaum.

Halte den Umfang klein: ein Prozess, ein zugehöriges Risiko oder eine Anforderung, eine Maßnahme und wenige Nachweise. Nutze bereinigte Testdaten, sofern echte Informationen für die Bewertung nicht erforderlich sind. Vereinbare vorab, wer im Pilotsystem welche Daten sehen und ändern darf.

Schreibe Erwartungen auf, bevor der Anbieter den Ablauf zeigt

Formuliere beobachtbare Ergebnisse. „Intuitiv“ ist eine Einschätzung; „die zuständige Person findet ihre offene Aufgabe ohne Unterstützung“ lässt sich prüfen.

SzenarioErwartetes Ergebnis
Eine Lücke erfassenAnforderung oder Risiko und offene Maßnahme sind zugeordnet
Verantwortung übergebenDie neue zuständige Person erkennt Aufgabe und Fälligkeit
Einen Nachweis ersetzenAktueller Stand und vorheriger Bezug sind nachvollziehbar
Eine Rückfrage stellenBegründung und Bearbeitungsstand bleiben beim Fall
Den Abschluss prüfenDie entscheidende Person erkennt Grundlage und offene Punkte

Diese Tabelle beschreibt Prüffragen, keine garantierten Funktionen eines bestimmten Produkts. Lasst euch jeden relevanten Ablauf in der vorgesehenen Konfiguration zeigen und führt ihn anschließend selbst aus.

Teste den zweiten Durchlauf

Der vorbereitete Idealfall ist nur der Anfang. Ändere danach eine Bedingung: Die verantwortliche Person ist abwesend. Der Nachweis deckt den Zeitraum nicht ab. Eine Maßnahme wurde geschlossen, obwohl eine Rückfrage offen ist.

Beobachte, ob die Beteiligten die Abweichung erkennen und den Fall weiterbearbeiten können. Hier zeigt sich, ob das System Orientierung gibt oder ob ihr wieder auf E-Mail und Zuruf ausweicht.

Prüfe auch die Sicht der jeweiligen Rolle. Eine Administration kann möglicherweise alles sehen; das sagt wenig darüber aus, ob ein fachlicher Bearbeiter die richtigen Informationen findet. Umgekehrt sollen für ihn nicht benötigte vertrauliche Inhalte nicht allein für einen bequemeren Test freigegeben werden.

Dokumentiere Beobachtung und Bewertung getrennt

Ein Testprotokoll muss kein Roman sein. Eine Zeile pro Beobachtung reicht, wenn sie eine Entscheidung ermöglicht.

FeldWas du festhältst
SzenarioAusgangslage, beteiligte Rolle und Aufgabe
ErwartungVorher festgelegtes Ergebnis
BeobachtungWas tatsächlich geschah, einschließlich nötiger Hilfe
AbweichungFehlende Funktion, Konfiguration, Datenqualität oder Schulungsbedarf
GewichtBedeutung für euren täglichen Betrieb
EntscheidungAkzeptabel, erneut testen, nachbessern oder Ausschlusskriterium

Trenne Produktgrenzen von Einrichtungsfehlern. Eine fehlende Rollenzuordnung kann korrigierbar sein. Eine notwendige Funktion, die es nicht gibt, ist eine andere Art von Ergebnis. Geplante Funktionen zählen erst dann als erfüllt, wenn sie im vereinbarten Umfang verfügbar und geprüft sind.

Prüfe den späteren Ausstieg mit

Frage, wie ihr eure Daten nach dem Pilot wieder erhaltet. Lasst euch einen verfügbaren Export an einem kleinen Datenbestand zeigen. Prüft, ob er für eure Zwecke verständlich ist und welche Inhalte, Dateien oder Beziehungen nicht enthalten sind.

Damit bewertet ihr keine abstrakte Featureliste. Ihr klärt, welchen Aufwand ein späterer Wechsel oder eine interne Weiterverarbeitung verursachen würde. Notiere offene Exportfragen genauso wie offene Fragen zur täglichen Nutzung.

Entscheide anhand der Fälle

Am Ende stehen drei mögliche Ergebnisse: Der Ablauf funktioniert für euren Bedarf. Er funktioniert nach klar benannten Anpassungen. Oder eine wesentliche Anforderung bleibt offen.

Vermeide einen Gesamtscore, der ein echtes Ausschlusskriterium mit vielen kleinen Komfortpunkten verrechnet. Die Entscheidung sollte zeigen, welche Aufgaben ihr künftig besser erledigen könnt und welche Grenzen ihr bewusst akzeptiert.

Kopexa zwei Wochen begleitet testen

Kopexa bietet eine zweiwöchige begleitete Testphase. Ihr könnt den Arbeitsablauf selbst ausprobieren und offene Fragen mit uns klären.

Nutzt einen bereinigten Prüffall als roten Faden: Legt eure Erwartungen fest, testet mit den beteiligten Rollen und prüft auch eine Abweichung vom Idealfall. Haltet fest, was funktioniert und wo ihr Unterstützung braucht. Nach den zwei Wochen habt ihr eigene Beobachtungen als Grundlage für eure Entscheidung.

Besprecht mit uns, welchen Ablauf ihr in der Testphase prüfen möchtet.