Den echten Arbeitsablauf testen
Ausgangspunkt ist die Aufgabe, die verbessert werden soll, gemeinsam mit den Personen, die sie erledigen. Schritte, Übergaben, Daten und Ausnahmen einer normalen Woche werden aufgelistet. Anschließend wird das Produkt an diesen Beispielen getestet, statt sich auf eine Funktionspräsentation oder ein vorbereitetes Demokonto zu verlassen.
Auf Reibung ist zu achten: doppelte Eingaben, unklare Status, schwer zugängliche Bedienelemente, umständliche mobile Nutzung oder Berichte mit viel manueller Nacharbeit. Ein Produkt kann zahlreiche Funktionen haben und trotzdem für die wichtigste Aufgabe des Teams ungeeignet sein.
Zugriff und Datenverarbeitung prüfen
Zu prüfen ist, wie Nutzer sich anmelden, welche Rollen verfügbar sind, wie Zugänge entfernt werden und welche Protokolle Administratoren einsehen können. Das Unternehmen sollte wissen, wo Daten verarbeitet und gespeichert werden, wie Sicherungen und Aufbewahrung funktionieren und welche Unterauftragsverarbeiter oder Integrationen beteiligt sind. Die richtigen Fragen hängen von den Daten und Pflichten des Unternehmens ab.
Auch der Export und das Zielformat sind zu klären. Vor der Bindung wichtiger Datensätze sollte ein Export getestet werden. Nach Vertragsende muss klar sein, was mit Daten geschieht und ob der Dienst die benötigten Zugriffskontrollen ermöglicht.
Integrationen und wiederkehrende Kosten berücksichtigen
Die zu verbindenden Systeme und der Informationsfluss in beide Richtungen werden festgehalten. Ein Connector muss die benötigten Ereignisse und Felder unterstützen; ein Anbieterlogo auf einer Integrationsseite genügt nicht. Außerdem sollte klar sein, wer Zugangsdaten wartet und fehlgeschlagene Synchronisierungen überwacht.
Die Kosten werden für erwartete Nutzerzahl und Nutzung berechnet. Einzubeziehen sind Einführung, kostenpflichtige Erweiterungen, Supportstufen und Änderungen bei Verlängerungen. Ein niedriger Einstiegspreis entspricht womöglich nicht den Kosten des Ablaufs, wenn das Team wächst oder eine wesentliche Integration benötigt.
Einen zeitlich begrenzten Pilot mit Ausstiegskriterien durchführen
Eine kleine Gruppe, ein repräsentativer Prozess und ein festgelegter Testzeitraum bilden einen sinnvollen Pilot. Es wird bestimmt, was funktionieren muss, welche Probleme akzeptabel sind und welche Belege über die Fortsetzung entscheiden. Eine Person sammelt Rückmeldungen, eine weitere verantwortet Daten und Konfiguration.
Vor dem Pilot ist festzuhalten, wie Testinformationen exportiert oder entfernt und wie der frühere Ablauf wieder aufgenommen werden. Ein geplanter Ausstieg ist kein Pessimismus; er ermöglicht der Organisation eine ehrliche Entscheidung mit geringem Aufwand.
Quellen und weiterführende Informationen
Einen sachlichen Fehler melden oder eine Quelle vorschlagen? Redaktion kontaktieren.
