Risiken und Gegenmassnahmen einordnen

Beginnen Sie mit dem Auslöser. Beschreiben Sie eine konkrete Bedingung oder ein Ereignis statt nur das unerwünschte Ergebnis. «Wenn die Produktdaten vor dem Import nicht bereinigt sind» ist prüfbarer als «Bei der Migration bestehen Risiken». Der Auslöser zeigt zugleich, worauf beide Seiten vor Projektbeginn achten müssen.

Benennen Sie danach die betroffene Seite. Ein Ereignis kann einzelne Mitarbeitende, den Vertrieb, die Buchhaltung, Endkunden oder einen externen Partner treffen. Die Zuordnung verhindert, dass eine kleine Unannehmlichkeit wie ein unternehmensweites Problem wirkt oder dass eine erhebliche Belastung in einer Fachabteilung unsichtbar bleibt.

Ergänzen Sie eine verständliche Wahrscheinlichkeitsaussage und die Auswirkung. Die Wahrscheinlichkeit beschreibt, unter welchen beobachtbaren Bedingungen das Ereignis eher oder seltener eintritt. Die Auswirkung beschreibt, was dann tatsächlich passiert: Welche Arbeit stoppt, welcher Zusatzaufwand entsteht, welche Zahlung wird fällig oder welcher Termin verschiebt sich?

Prüfen Sie vor der Veröffentlichung, ob Sie überhaupt ein Risiko beschreiben. Eine begrenzte Zahl von Schnittstellen, ein fester Supportzeitraum oder die fehlende Eignung für einen bestimmten Anwendungsfall sind dauerhafte Leistungsgrenzen. Sie werden nicht durch Aufmerksamkeit unwahrscheinlicher. Ein fehlerhafter Import bei unbereinigten Daten ist dagegen ein steuerbares Risiko. Vermischen Sie beide Kategorien nicht.

Verwenden Sie keine Prozentzahl, wenn keine belastbare und vergleichbare Datengrundlage vorliegt. Eine Zahl wirkt objektiv, kann aber unterschiedliche Projektgrössen, Ausgangslagen oder Definitionen verdecken. «In 15 Prozent der Projekte» wäre nur sinnvoll, wenn Stichprobe, Zeitraum, Ereignisdefinition und Vergleichbarkeit bekannt sind. Sonst ist die Zahl genauer formuliert als das Wissen dahinter.

Arbeiten Sie stattdessen mit Bedingungen und abgestuften Begriffen. Formulierungen wie «tritt vor allem auf, wenn …», «ist bei erstmaliger Datenbereinigung eher zu erwarten» oder «kam bisher vereinzelt unter folgender Bedingung vor» zeigen Richtung und Kontext. Definieren Sie intern, was Begriffe wie häufig, gelegentlich oder selten bedeuten, damit Verkauf und Projektteam sie nicht unterschiedlich verwenden.

Trennen Sie Beobachtung und Einschätzung. Schreiben Sie etwa: «Bei Projekten ohne benannte interne Ansprechperson beobachten wir häufiger Wartezeiten. Für Ihr Vorhaben ist dieses Risiko relevant, solange die Rolle unbesetzt ist.» Der erste Satz beschreibt Erfahrung, der zweite eine fallbezogene Beurteilung. Beides bleibt überprüfbar, ohne eine scheinbar exakte Prognose abzugeben.

Nennen Sie auch die Grenzen Ihres Wissens. Bei einer neuen Leistung, einer ungewöhnlichen Systemlandschaft oder wenigen vergleichbaren Fällen ist «noch nicht belastbar einschätzbar» die präzisere Aussage. Verbinden Sie diese Unsicherheit mit einem Prüfpunkt, etwa einem technischen Vorabtest. Unwissen wird dadurch nicht zum blinden Fleck, sondern zu einer Aufgabe vor der Entscheidung.

Beschreiben Sie zuerst die operative Folge. Fragen Sie: Welcher Prozess ist eingeschränkt, wer muss zusätzlich arbeiten und welche Übergangslösung ist nötig? «Die Automatisierung fällt aus» bleibt abstrakt. Konkreter ist: «Bestellungen müssen bis zur Fehlerbehebung manuell geprüft und freigegeben werden.» So kann der Kunde beurteilen, ob Personal und ein Notverfahren vorhanden sind.

Ordnen Sie danach die finanzielle Folge ein. Dazu gehören nicht nur zusätzliche Rechnungspositionen, sondern auch interne Arbeitszeit, externe Unterstützung, Ersatzbeschaffung oder eine vorübergehende Doppelstruktur. Nennen Sie bekannte Preise oder Berechnungsregeln, wenn sie tatsächlich feststehen. Wenn die Höhe von Umfang und Dauer abhängt, erklären Sie diese Kostentreiber statt einen unbelegten Betrag zu nennen.

Machen Sie die zeitliche Folge sichtbar. Unterscheiden Sie zwischen einer Verschiebung des Projektplans, einer Betriebsunterbrechung und einer verzögerten Wirkung nach dem Start. Nennen Sie Abhängigkeiten und Entscheidungspunkte. Ein Terminrisiko ist anders zu bewerten, wenn ein Kunde einen gesetzlichen Stichtag einhalten muss, als wenn der Start innerhalb eines flexiblen Quartals erfolgen kann.

Illustratives Beispiel: Ein KMU möchte sein neues Warenwirtschaftssystem zum Monatswechsel starten. Unbereinigte Artikelstammdaten können den Import verzögern. Betroffen sind Projektteam und Auftragsabwicklung; mögliche Folgen sind zusätzliche Bereinigungsarbeit, ein verlängerter Parallelbetrieb und ein späterer Start. Das Beispiel ist keine allgemeine Prognose. Es zeigt, wie Betrieb, Kosten und Termin für einen konkreten Fall gemeinsam beschrieben werden.

Ordnen Sie jede Gegenmassnahme einem Auslöser zu. Ein Vorabtest hilft gegen unerkannte technische Inkompatibilitäten; eine Schulung hilft gegen Bedienfehler; eine Reserve im Terminplan federt Verzögerungen ab. Eine lange Liste allgemeiner Qualitätsmassnahmen schafft dagegen keine Klarheit darüber, welches Risiko tatsächlich kleiner wird.

Erklären Sie, wie die Massnahme wirkt und welche Voraussetzung sie hat. «Wir führen einen Testimport durch» ist erst vollständig, wenn Umfang, benötigte Daten, Auswertung und Konsequenz eines Fehlers feststehen. Kann der Test nur mit repräsentativen Daten aussagekräftig sein, muss der Kunde diese rechtzeitig liefern. Sonst hängt die behauptete Schutzwirkung an einer unerwähnten Bedingung.

Nennen Sie direkt danach das Restrisiko. Ein Testimport kann bekannte Formate prüfen, aber nicht jede spätere Änderung an Quelldaten erfassen. Eine Vertretungsregel reduziert die Abhängigkeit von einer Person, beseitigt aber nicht den Wissensverlust bei einem kurzfristigen Ausfall. Formulieren Sie, was trotz korrekter Massnahme passieren kann und welche Folge dann getragen werden muss.

Behandeln Sie dauerhafte Grenzen anders. Wenn eine Software einen notwendigen Prozess grundsätzlich nicht unterstützt, ist ein Kontrollschritt keine Gegenmassnahme. Ein manueller Umweg kann eine bewusste Alternative sein, ändert aber die Leistungsgrenze nicht. Kennzeichnen Sie deshalb klar: «Das System kann X nicht; möglich ist Y mit folgendem laufenden Aufwand.» So entscheidet der Kunde über einen bekannten Kompromiss statt über ein scheinbar gelöstes Risiko.

Teilen Sie Aufgaben nach tatsächlicher Kontrolle zu. Der Anbieter verantwortet typischerweise die vereinbarte Leistung, fachgerechte Ausführung, eigene Termine und die Meldung erkannter Abweichungen. Der Kunde verantwortet beispielsweise interne Entscheidungen, Zugänge, freigegebene Daten und verfügbare Fachpersonen. Schreiben Sie nicht pauschal «Mitwirkung des Kunden», sondern nennen Sie Ergebnis, verantwortliche Rolle und Fälligkeit.

Legen Sie für kritische Punkte einen Nachweis fest. Das kann eine dokumentierte Freigabe, ein erfolgreicher Test, eine Entscheidung im Projektprotokoll oder eine geprüfte Datei sein. Ein Nachweis dient nicht dazu, Verantwortung abzuschieben. Er macht sichtbar, ob eine Voraussetzung erfüllt ist und ob der nächste Schritt sicher beginnen kann.

Definieren Sie einen einfachen Änderungsprozess: Wer meldet eine neue Annahme oder Abweichung? Wer bewertet Folgen für Leistungsumfang, Kosten, Termin und Risiko? Wer darf entscheiden? Wo wird die Entscheidung dokumentiert? Eine Änderung gilt erst dann als vereinbart, wenn Auswirkungen und Verantwortlichkeiten für beide Seiten nachvollziehbar festgehalten sind.

Regeln Sie auch die Eskalation. Wenn eine notwendige Kundenzuarbeit fehlt oder der Anbieter einen Termin nicht halten kann, braucht es einen Zeitpunkt für die Meldung, eine verantwortliche Kontaktperson und mögliche Optionen. Das Ziel ist keine lückenlose Absicherung jeder Kleinigkeit. Beide Seiten sollen früh erkennen, wann ein steuerbares Risiko wächst, eine Massnahme angepasst werden muss oder eine dauerhafte Grenze die ursprüngliche Lösung infrage stellt.