MoSCoW-Priorisierung im Schweizer Banking: Compliance und Effizienz vereinen

Jedes Schweizer KMU kennt den Druck: Die Zeit ist knapp, das Budget begrenzt und die Erwartungen hoch. Im regulierten Banking-Umfeld kommt eine weitere Schicht hinzu – die lückenlose Einhaltung von Vorschriften. Viele Geschäftsführende stehen vor der Herausforderung, Dutzende von Projektanforderungen zu managen, ohne den Überblick zu verlieren oder die Compliance zu gefährden.

Allein die schiere Menge an Aufgaben und Wünschen kann Projekte lähmen, bevor sie überhaupt richtig starten. Ein Blick auf die Zahlen zeigt die Relevanz: 99,7 % aller Schweizer Unternehmen sind KMU, und sie stellen zwei Drittel der Arbeitsplätze. Dies unterstreicht die Notwendigkeit effizienter Methoden, die auch in komplexen, regulierten Umfeldern wie dem Schweizer Banking funktionieren.

Als Praktiker mit IPSO-Fachausweis in AI Business habe ich selbst erlebt, wie schnell Projekte scheitern, wenn die Prioritäten nicht von Anfang an klar sind. Besonders im Banking, wo FINMA-Vorgaben und das nDSG feste Grenzen setzen, ist eine präzise Anforderungsanalyse kein Luxus, sondern eine Notwendigkeit. Die MoSCoW-Methode bietet hier einen klaren, pragmatischen Weg, um das Wesentliche vom Wünschbaren zu trennen und den Fokus auf das zu legen, was wirklich zählt.

Wie kann ich mit der MoSCoW-Methode meine Projektanforderungen in einem regulierten Umfeld priorisieren?

Durch eine klare Kategorisierung in unverzichtbare, wichtige, wünschenswerte und ausschliessbare Anforderungen. Die MoSCoW-Methode ist ein effektives Werkzeug, um Anforderungen zu bewerten und zu priorisieren. Sie wurde speziell dafür entwickelt, in Projekten mit knappen Ressourcen und festen Terminen den Fokus zu behalten. Im Schweizer Banking-Umfeld, wo regulatorische Vorgaben wie die der FINMA und das neue Datenschutzgesetz (nDSG) nicht verhandelbar sind, ist diese Trennschärfe von unschätzbarem Wert.

Wir klassifizieren Anforderungen grundsätzlich in drei Ebenen, um eine solide Basis für das professionelle Requirements Management zu schaffen. Zuerst kommen die Business Requirements, die das "Warum?" beantworten – also die Geschäftsziele der Bank. Dazu gehören konkrete Ziele wie die Senkung der durchschnittlichen Bearbeitungszeit (AHT) um 15 % oder die Reduktion der Suchzeit von 2–5 Minuten auf unter 30 Sekunden. Diese Ziele sind der Motor jedes Projekts.

Danach folgen die Stakeholder Requirements. Diese beschreiben, was die einzelnen Interessengruppen benötigen, um die Business Requirements zu erfüllen. Sie sind oft spezifischer und spiegeln die Bedürfnisse von Abteilungen, Mitarbeitenden oder Kunden wider. Schliesslich gibt es die System Requirements, die detailliert festlegen, was das System leisten muss, um die Anforderungen der Business- und Stakeholder-Ebene zu erfüllen. Dies kann von technischen Spezifikationen bis hin zu funktionalen Anforderungen reichen.

Nehmen wir an, wir haben 24 solcher Anforderungen identifiziert. Alle 24 Anforderungen gleichzeitig zu entwickeln, ist in der Realität meist unmöglich – Zeit, Budget und Ressourcen sind begrenzt. Hier kommt MoSCoW ins Spiel. Die Methode teilt die Anforderungen in vier Kategorien ein:

• Must Have (Muss-Anforderungen): Ohne diese kann das Projekt nicht live gehen oder ist nicht compliant. Dies sind die absoluten Kernfunktionen und alle regulatorischen Vorgaben. Im Banking sind das beispielsweise die vollständige Einhaltung des nDSG, der FINMA-Richtlinien und grundlegende Sicherheitsstandards. Auch die oben genannten Business Must-Haves wie die Reduktion der AHT um 15% und der Suchzeit um 50% gehören hier rein. Für ein Schweizer Bankinstitut könnten dies 17 der 24 identifizierten Anforderungen sein.
• Should Have (Soll-Anforderungen): Wichtige Anforderungen, die einen hohen Wert liefern, aber nicht zwingend für den ersten Release sind. Das Fehlen dieser Funktionen würde einen Workaround erfordern, aber das System wäre dennoch nutzbar. Sie sollten idealerweise umgesetzt werden, wenn es die Ressourcen erlauben.
• Could Have (Kann-Anforderungen): Nette Features, die das Produkt verbessern, aber einen geringeren Einfluss auf den Gesamterfolg haben. Sie werden nur umgesetzt, wenn alle Must- und Should-Haves fertiggestellt sind und noch Kapazitäten vorhanden sind.
• Won't Have (Wird-nicht-haben-Anforderungen): Anforderungen, die explizit in diesem Projekt oder in dieser Phase nicht umgesetzt werden. Diese klare Abgrenzung hilft, den Fokus zu bewahren und Erwartungen zu managen. Beispiele könnten eine vollautomatisierte Kreditentscheidung auf Basis von KI, eine Sprachschnittstelle oder ein externer Chatbot sein, die zwar wünschenswert wären, aber nicht zum initialen MVP gehören.

Diese strikte Trennung ist besonders im Banking essenziell. Die FINMA setzt klare Regeln, und das nDSG verlangt eine sorgfältige Handhabung von Personendaten. Ein "Must Have" bedeutet hier, dass ohne diese Anforderung der Betrieb nicht legal oder sicher ist. Dies schafft eine unmissverständliche Prioritätenliste, die für alle Beteiligten nachvollziehbar ist und die Grundlage für einen erfolgreichen Projektverlauf bildet.

Welche Compliance-Anforderungen sind für Schweizer KMU im Bankwesen unverzichtbar (Must-Haves)?

Alle regulatorischen Vorgaben der FINMA und des nDSG sind zwingende Must-Haves, ebenso wie Kernfunktionen für den Geschäftsbetrieb. Im Schweizer Finanzsektor sind die regulatorischen Anforderungen umfassend und nicht verhandelbar. Für ein KMU im Bankwesen bedeutet dies, dass alle Aspekte, die von der Eidgenössischen Finanzmarktaufsicht (FINMA) und dem neuen Schweizer Datenschutzgesetz (nDSG) vorgeschrieben werden, ohne Wenn und Aber als "Must Have" zu klassifizieren sind.

Die FINMA-Vorgaben umfassen ein breites Spektrum, von der Geldwäschereibekämpfung (AML) über die Einhaltung von Risikomanagement-Richtlinien bis hin zu Anforderungen an die IT-Sicherheit und die Auslagerung von Dienstleistungen. Ein KI-Projekt im Banking muss beispielsweise sicherstellen, dass alle Datenverarbeitungen den FINMA-Rundschreiben zur Operationellen Risiken (OpRisk) oder zur Corporate Governance entsprechen. Das bedeutet, dass die Datenherkunft nachvollziehbar sein muss, Modelle transparent und nachvollziehbar sind und potenzielle Bias-Risiken minimiert werden. Die Verantwortung für die Einhaltung dieser Vorgaben liegt klar beim Institut.

Parallel dazu ist das nDSG seit dem 1. September 2023 in Kraft und hat die Anforderungen an den Schutz personenbezogener Daten deutlich verschärft. Für Banken bedeutet dies unter anderem:

• Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen (Privacy by Design and Default): Systeme müssen so konzipiert sein, dass der Datenschutz von Grund auf gewährleistet ist.
• Datensicherheit: Angemessene technische und organisatorische Massnahmen zum Schutz der Daten sind Pflicht.
• Transparenz und Informationspflicht: Kunden müssen klar und verständlich darüber informiert werden, wie ihre Daten verarbeitet werden.
• Datenauskunftsrecht und Recht auf Datenlöschung: Diese Rechte müssen technisch umsetzbar sein.
• Meldepflicht bei Datenpannen: Im Falle einer Verletzung der Datensicherheit muss dies der Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) gemeldet werden.

Jede dieser nDSG-Anforderungen ist ein "Must Have". Ein KI-System, das beispielsweise Kundendaten für personalisierte Angebote analysiert, muss sicherstellen, dass die Daten anonymisiert oder pseudonymisiert werden können, dass die Einwilligung der Kunden vorliegt und dass sie ihre Rechte jederzeit wahrnehmen können. Wer hier Abstriche macht, riskiert nicht nur hohe Bussen, sondern auch einen massiven Reputationsverlust.

Neben den regulatorischen Anforderungen zählen auch jene Funktionen zu den "Must Haves", die für den Kernbetrieb des Bankgeschäfts absolut unverzichtbar sind. Dazu gehören beispielsweise die Stabilität der Kernbankensysteme, die genaue Abwicklung von Transaktionen und die Sicherstellung der Liquidität. Wenn ein KI-Projekt darauf abzielt, interne Prozesse zu optimieren, dann sind die Ziele, die direkt auf die operative Effizienz einzahlen und die Kundenzufriedenheit sichern, ebenfalls als Must-Haves zu betrachten. Die Senkung der durchschnittlichen Bearbeitungszeit (AHT) um 15 % und die Reduktion der Suchzeit um 50 % sind hierfür prägnante Beispiele aus unserer Praxis, da sie unmittelbar die Servicequalität und die Kostenstruktur beeinflussen.

Warum ist die Trennung von Pflicht (Must-Haves) und Kür (Should/Could-Haves) für den Erfolg von KI-Projekten entscheidend?

Sie sichert die Einhaltung von Vorschriften, verhindert Ressourcenverschwendung und ermöglicht eine schnelle Markteinführung eines funktionsfähigen Produkts. Die klare Abgrenzung zwischen dem, was absolut notwendig ist, und dem, was wünschenswert wäre, ist der Dreh- und Angelpunkt für den Erfolg jedes Projekts, besonders aber bei komplexen KI-Initiativen in regulierten Branchen. Ohne diese Trennung verzetteln sich Teams, Budgets explodieren, und die Markteinführung verzögert sich auf unbestimmte Zeit.

Im Kern geht es darum, ein Minimum Viable Product (MVP) zu definieren, das die Kernfunktionalität liefert und vor allem die Compliance-Anforderungen erfüllt. Dies ist der erste Schritt unserer Release-Strategie. Wenn ein Schweizer Bankinstitut 24 Anforderungen für ein neues KI-Projekt im Bereich Kundenberatung hat, ist es schlicht unmöglich, alle gleichzeitig umzusetzen. Bei unserem Praxisbeispiel konnten wir durch die MoSCoW-Methode die Anforderungen klar unterteilen: 17 Must-Haves, 6 Should-Haves und 1 Could-Have. Diese Fokussierung ermöglichte eine realistische Planung.

Stellen Sie sich vor, Sie versuchen, alles auf einmal zu bauen. Das Team wird überfordert, die Qualitätskontrolle leidet, und die Komplexität steigt exponentiell. Jede zusätzliche Funktion, die kein "Must Have" ist, bindet Entwicklungszeit, Testkapazitäten und Budget. Wenn diese Ressourcen dann fehlen, um eine kritische nDSG-Anforderung umzusetzen, steht das gesamte Projekt auf der Kippe. Eine Story Map, die in Themen, Epics und User Stories unterteilt ist und die INVEST-Kriterien nutzt, hilft uns dabei, diese Prioritäten strukturiert abzubilden und die Übersicht zu behalten.

Die konsequente Priorisierung nach MoSCoW zwingt alle Beteiligten, sich auf das Wesentliche zu konzentrieren. Sie schafft Transparenz darüber, welche Funktionen für den Go-Live zwingend erforderlich sind und welche später hinzugefügt werden können. Dies minimiert das Risiko, ein überfrachtetes Produkt zu entwickeln, das teuer, verspätet und am Ende vielleicht gar nicht compliant ist. Die frühzeitige Lieferung eines funktionsfähigen und rechtskonformen MVP schafft zudem Vertrauen bei Management und Stakeholdern und ermöglicht es, frühzeitig Feedback einzuholen und das Produkt iterativ weiterzuentwickeln.

Zudem hilft die MoSCoW-Methode, die "Will-Not-Have"-Anforderungen explizit zu benennen. Dies mag trivial erscheinen, ist aber entscheidend, um Missverständnisse zu vermeiden und den Umfang klar zu begrenzen. Wenn zum Beispiel entschieden wird, dass eine automatisierte Kreditentscheidung mittels KI oder ein externes Chatbot-Interface nicht Teil des initialen Projekts sein wird, dann wissen alle, dass diese Ressourcen für andere, wichtigere Aufgaben zur Verfügung stehen. Das spart nicht nur Entwicklungskosten, sondern auch die Zeit für Diskussionen und Neukonzeptionen.

Die MoSCoW-Methode ist mehr als nur ein Werkzeug zur Priorisierung; sie ist eine Denkweise, die Effizienz, Compliance und strategischen Fokus in Projekten verankert. Gerade in der Schweiz, wo KMU das Rückgrat der Wirtschaft bilden und gleichzeitig strengen Regulierungen unterliegen, ist diese Methode unverzichtbar.

Ich, Lukas Huber, habe in meiner Laufbahn immer wieder festgestellt: Wer seine Prioritäten nicht kennt, wird am Ende alles, aber nichts richtig machen. Besonders im Banking, wo Fehler teuer sind und das Vertrauen der Kunden das höchste Gut ist, können Sie es sich nicht leisten, Kompromisse bei den "Must Haves" einzugehen.

Nutzen Sie die MoSCoW-Methode, um Ihre Projekte auf eine solide Basis zu stellen, Ressourcen optimal einzusetzen und sicherzustellen, dass Sie ein Produkt liefern, das nicht nur innovativ ist, sondern auch alle regulatorischen Anforderungen erfüllt. Der Erfolg Ihres KI-Projekts hängt massgeblich davon ab, ob Sie bereit sind, das Wesentliche klar zu definieren und konsequent zu verfolgen.

✅ Fokus auf das Wesentliche: Die MoSCoW-Methode stellt sicher, dass Sie sich auf die kritischsten Anforderungen konzentrieren, die für den Projekterfolg und die Compliance unerlässlich sind.

✅ Risikominimierung: Durch die Priorisierung von Compliance-Anforderungen als "Must Haves" minimieren Sie rechtliche und regulatorische Risiken erheblich.

✅ Effiziente Ressourcennutzung: Sie vermeiden Ressourcenverschwendung für weniger wichtige Funktionen und setzen Ihr Budget, Ihre Zeit und Ihr Team optimal ein.

Möchten Sie mehr darüber erfahren, wie Sie Ihre KI-Projekte im regulierten Umfeld erfolgreich priorisieren können? Sprechen Sie mit uns.