Proof of Value KI für Schweizer KMU
- Amanda Frey

- vor 11 Minuten
- 10 Min. Lesezeit

KI-Projekte beginnen in vielen Unternehmen mit einer naheliegenden Frage: Funktioniert die Lösung technisch überhaupt? Diese Frage ist berechtigt. Für Schweizer KMU reicht sie aber oft nicht aus. Denn ein Test, der im Demo-Setup überzeugt, beantwortet noch nicht, ob im Tagesgeschäft tatsächlich ein Nutzen entsteht.
Genau hier wird der Unterschied zwischen einem Proof of Concept und einem Proof of Value KI relevant. Während ein Proof of Concept vor allem die technische Machbarkeit prüft, fragt ein Proof of Value nach dem geschäftlichen Wert: Spart die Lösung Zeit? Senkt sie Fehler? Verkürzt sie Durchlaufzeiten? Wird sie im Team akzeptiert? Und steht der Aufwand in einem vernünftigen Verhältnis zum Nutzen?
Wer einen KI-Pilot im KMU so aufsetzt, dass nicht nur Technik, sondern auch Wirkung messbar wird, kann fundierter entscheiden. Das spart unnötige Testschlaufen und reduziert das Risiko, dass ein Projekt als interessante Demo endet, aber nie produktiv wird.
Proof of Concept und Proof of Value im KI-Kontext: Der Unterschied in einem KMU
Ein Proof of Concept prüft, ob etwas grundsätzlich funktioniert. Im KI-Kontext kann das bedeuten, dass ein Modell Dokumente erkennt, Anfragen klassifiziert oder Vorschläge für die Bearbeitung erstellt. Die Leitfrage lautet: Ist die technische Umsetzung möglich?
Ein Proof of Value geht einen Schritt weiter. Hier steht nicht nur im Vordergrund, ob die Lösung funktioniert, sondern ob sie im konkreten Prozess einen messbaren Mehrwert erzeugt. Die Leitfrage lautet: Lohnt sich der Einsatz im Alltag?
Für KMU ist diese Unterscheidung besonders wichtig. Die Ressourcen für Tests, Anpassungen und Rollout sind meist begrenzt. Deshalb sollte ein Pilot nicht nur zeigen, dass eine KI grundsätzlich einsetzbar ist, sondern auch, ob sie in einer realen Arbeitssituation tragfähig ist.
Ein Beispiel:
Ein Unternehmen testet eine KI zur automatischen Vorprüfung von eingehenden E-Mails. Im Proof of Concept zeigt sich, dass die Inhalte technisch sauber erkannt und vorsortiert werden können. Das ist ein guter erster Schritt. Erst im Proof of Value wird jedoch klar, ob die Mitarbeitenden dadurch wirklich entlastet werden, ob weniger Rückfragen entstehen und ob die Bearbeitung insgesamt schneller wird.
Wichtig ist: Ein Proof of Concept ist nicht falsch. Er kann sinnvoll sein, wenn zuerst eine technische Unsicherheit geklärt werden muss. Problematisch wird es dann, wenn ein PoC bereits als ausreichende Entscheidungsgrundlage für den produktiven Einsatz verstanden wird. Gerade bei KI und Automatisierung braucht es zusätzlich die Frage nach dem konkreten Nutzen im Arbeitsalltag.
Warum technische Machbarkeit allein noch kein gutes KI-Projekt ergibt
Viele KI-Projekte scheitern nicht an der Technik, sondern an der Überführung in die Praxis. Ein Labor-Setup, ein sauber vorbereiteter Datensatz oder eine gut moderierte Demo sagen oft wenig darüber aus, wie stabil eine Lösung im echten Betrieb funktioniert.
Der Grund ist einfach: Der Alltag ist unordentlicher als der Test. Daten sind unvollständig, Prozesse werden unterschiedlich gelebt, Sonderfälle treten häufiger auf als erwartet, und die Zeit für manuelle Nachkontrollen ist begrenzt. Eine technisch funktionierende Lösung kann deshalb betrieblich trotzdem unpassend sein.
Typische Unterschiede zwischen technischem Erfolg und betrieblicher Relevanz sind:
Die KI liefert gute Resultate, aber die Nachbearbeitung ist zu aufwendig.
Die Qualität stimmt nur bei ideal aufbereiteten Daten.
Der Prozess ist gar nicht klar genug definiert, um Wirkung sauber zu messen.
Die Mitarbeitenden vertrauen den Vorschlägen nicht und umgehen die Lösung.
Der Integrationsaufwand in bestehende Abläufe ist höher als gedacht.
Der Nutzen entsteht nur in Ausnahmefällen, nicht im täglichen Volumen.
Ein klassischer Fall im KMU ist die automatisierte Verarbeitung von Dokumenten. Ein Test mit 100 sauber ausgewählten Rechnungen kann überzeugen. Im Betrieb kommen aber unterschiedliche Formate, unvollständige Angaben und verschiedene Ausnahmen dazu. Dann zeigt sich, ob die Lösung nur in der Demo funktioniert oder ob sie tatsächlich einen relevanten Teil der Arbeit verlässlich unterstützt.
Deshalb ist ein KI-Projekt erst dann gut gestartet, wenn nicht nur die Frage «geht das?» beantwortet wird, sondern auch «bringt das im Alltag genug?». Wer ein KI Projekt starten will, sollte diese zweite Frage von Anfang an in den Aufbau des Piloten integrieren.
Welche Messgrössen ein Proof of Value für KMU braucht
Ein Proof of Value steht und fällt mit den richtigen Messgrössen. Ohne klare Kriterien bleibt der Pilot interpretierbar, aber nicht entscheidbar. Dann entsteht zwar Erfahrung, aber keine belastbare Grundlage für den nächsten Schritt.
Für KMU sind vor allem Kennzahlen sinnvoll, die direkt mit dem Prozess und dem Arbeitsalltag verbunden sind. Dazu gehören insbesondere:
Zeitersparnis pro Vorgang oder pro Woche
Fehlerreduktion bei Erfassung, Prüfung oder Weiterverarbeitung
Verkürzte Durchlaufzeit vom Eingang bis zum Abschluss
Qualitätsverbesserung in Form von mehr Vollständigkeit oder konsistenteren Ergebnissen
Nutzerakzeptanz im betroffenen Team
Aufwand für Ausnahmen oder manuelle Korrekturen
Diese Kennzahlen sollten vor dem Pilot festgelegt werden. Erst dann ist klar, woran Erfolg oder Misserfolg gemessen wird. Nachträglich gewählte Kriterien führen oft dazu, dass ein Projekt schön gerechnet oder vorschnell verworfen wird.
Harte und weiche Nutzenindikatoren unterscheiden
Für einen belastbaren Proof of Value ist die Kombination aus harten und weichen Indikatoren sinnvoll.
Harte Indikatoren sind direkt messbar. Dazu zählen etwa:
Bearbeitungszeit pro Fall
Anzahl Fehler pro 100 Vorgänge
Anzahl manuell nachbearbeiteter Fälle
Dauer bis zur Freigabe oder Übergabe
Weiche Indikatoren sind ebenfalls relevant, auch wenn sie weniger exakt in Franken oder Minuten ausgedrückt werden können. Dazu gehören:
Vertrauen in die Resultate
Verständlichkeit der Anwendung
Akzeptanz im Team
wahrgenommene Entlastung
Bereitschaft, die Lösung dauerhaft zu nutzen
Gerade bei KI ist diese Unterscheidung wichtig. Eine Lösung kann auf dem Papier Zeit sparen, aber im Team auf Skepsis stossen. Dann wird sie nicht konsequent eingesetzt, und der erwartete Nutzen bleibt aus.
Kennzahlen immer am konkreten Prozess ausrichten
Kennzahlen sind nur dann hilfreich, wenn sie zum gewählten Anwendungsfall passen. Bei einer KI für die E-Mail-Klassifikation sind andere Messgrössen relevant als bei einer automatisierten Dokumentenprüfung oder bei einem Assistenten für interne Wissenssuche.
Ein sinnvoller Ansatz für einen Automatisierungs-Pilot im KMU ist deshalb:
Ausgangslage messen
Zielwert oder Zielkorridor definieren
Pilot unter realistischen Bedingungen durchführen
Vorher-Nachher-Vergleich dokumentieren
Nicht jede Verbesserung muss spektakulär sein. Auch eine moderate Zeitersparnis kann wertvoll sein, wenn sie regelmässig anfällt und in einem stabilen Prozess entsteht. Umgekehrt ist eine beeindruckende Demo wenig wert, wenn der Effekt im Alltag kaum spürbar ist.
Wie gross ein KI-Pilot sein sollte, damit er aussagekräftig bleibt
Ein guter Pilot ist weder zu klein noch zu breit. Wenn der Umfang zu eng gewählt wird, entstehen keine belastbaren Aussagen. Wenn er zu gross ist, wird der Pilot langsam, teuer und schwer steuerbar.
Für Schweizer KMU ist ein klar abgegrenzter Rahmen meist am sinnvollsten: ein Prozess, ein Team, ein definierter Anwendungsfall. Genau dort lässt sich beobachten, wie sich die Lösung unter realen Bedingungen verhält.
Geeignete Beispiele für einen Pilotumfang sind:
automatische Vorqualifikation eingehender Serviceanfragen in einem Team
KI-gestützte Prüfung bestimmter Dokumenttypen in einem Teilprozess
Unterstützung bei der internen Wissenssuche für eine klar definierte Nutzergruppe
Erkennung wiederkehrender Muster in einem standardisierten operativen Ablauf
Weniger geeignet ist ein Start mit mehreren Bereichen gleichzeitig, offenen Zielbildern oder einer zu grossen Anzahl Sonderfälle. Das erschwert die Auswertung und verlangsamt die Entscheidungen.
Ein sinnvoller Pilot ist klein genug für schnelle Erkenntnisse und gross genug für echte Aussagekraft. Das bedeutet konkret:
genug Volumen, damit sich Muster zeigen
echte Daten statt nur Testdaten
reale Anwenderinnen und Anwender
ein begrenzter Zeitraum mit klaren Messpunkten
definierte Verantwortlichkeiten für Auswertung und Entscheid
Wichtig ist auch die klare Abgrenzung zur Endlosschlaufe. Ein Pilot sollte nicht in eine diffuse Testphase übergehen, in der immer neue Varianten ausprobiert werden, ohne dass je entschieden wird. Ein strukturierter Rahmen mit Zielbild, Messgrössen und Review-Termin verhindert genau das.
Wie Swiss Process Solutions solche Vorhaben strukturiert, zeigt auch unser Ansatz: nicht toolgetrieben, sondern ausgehend von Prozess, Nutzen und Umsetzbarkeit.
Datenqualität, Prozessklarheit und Nutzerakzeptanz als Erfolgsfaktoren
Auch der beste Pilot liefert wenig Erkenntnis, wenn die Grundlagen nicht stimmen. Drei Faktoren sind dabei besonders wichtig: Datenqualität, Prozessklarheit und Akzeptanz im Team.
Datenqualität: Ohne brauchbare Grundlage keine verlässliche Bewertung
KI arbeitet nicht losgelöst vom Umfeld. Wenn Daten unvollständig, uneinheitlich oder schwer zugänglich sind, leidet nicht nur die technische Leistung, sondern auch die Beurteilung des Nutzens. Denn dann bleibt unklar, ob die Lösung an sich ungeeignet ist oder ob schlicht die Ausgangslage zu schwach war.
Im KMU-Kontext geht es dabei oft nicht um riesige Datenmengen, sondern um brauchbare und konsistente Daten:
Sind die relevanten Informationen vorhanden?
Sind Formate einheitlich genug?
Gibt es genügend Beispiele für typische Fälle?
Lassen sich Resultate sauber überprüfen?
Schwache Daten bedeuten nicht automatisch, dass ein Vorhaben gestoppt werden muss. Sie können aber ein Hinweis sein, dass zuerst Vorarbeiten nötig sind, bevor ein PoV KI sinnvoll wird.
Prozessklarheit: KI ersetzt keine unklaren Abläufe
Ein häufiger Denkfehler ist die Annahme, dass KI unklare Prozesse ausgleichen könne. In der Praxis ist eher das Gegenteil der Fall: Je diffuser ein Ablauf, desto schwieriger wird es, Nutzen zu messen und Verantwortlichkeiten zu definieren.
Wenn nicht klar ist, wie ein Prozess heute funktioniert, welche Varianten es gibt und wo die eigentlichen Engpässe liegen, lässt sich auch kaum beurteilen, ob eine KI wirklich hilft. Dann verbessert der Pilot möglicherweise Symptome, aber nicht die Ursache.
Deshalb gilt: KI funktioniert auf klaren Prozessen besser, sie ersetzt sie nicht. Vor einem Pilot sollte deshalb mindestens beantwortet sein:
Wo beginnt und endet der betrachtete Prozess?
Welche Schritte sind standardisiert, welche nicht?
Welche Ausnahmen kommen häufig vor?
Wo entsteht heute der grösste Aufwand oder Fehleranteil?
Nutzerakzeptanz: Wert entsteht erst, wenn die Lösung verwendet wird
Ein technisch solider Pilot kann trotzdem scheitern, wenn die betroffenen Teams nicht mitziehen. Das ist keine Frage von Widerstand gegen Technik, sondern oft eine Folge unklarer Erwartungen, fehlender Einbindung oder mangelnder Transparenz.
Akzeptanz entsteht eher dann, wenn:
die betroffenen Teams früh einbezogen werden
der Zweck des Piloten verständlich ist
klar ist, was gemessen wird und was nicht
Rückmeldungen aus dem Alltag ernst genommen werden
die Lösung nachvollziehbar in bestehende Abläufe eingebettet wird
Gerade im KMU, wo Teams eng zusammenarbeiten, wirkt sich Nutzerakzeptanz direkt auf den Erfolg eines Piloten aus. Sie gehört deshalb nicht an den Rand des Projekts, sondern in die Bewertungslogik.
Für die strategische Einordnung solcher Fragen kann auch eine vorgelagerte Beratung und Analyse sinnvoll sein, insbesondere wenn mehrere Anwendungsfälle im Raum stehen und priorisiert werden müssen.
So wird aus einem Pilot eine Entscheidung: weiterführen, anpassen oder stoppen
Ein Pilot ist nur dann sinnvoll, wenn am Ende eine Entscheidung möglich ist. Dazu braucht es eine klare Logik, die über das Gefühl hinausgeht. «Es wirkt vielversprechend» ist kein belastbarer Entscheidungszustand.
Nach einem Proof of Value sollten mindestens folgende Fragen beantwortet werden:
Ist der Nutzen messbar?
Wurden die definierten Kennzahlen verbessert, etwa bei Zeit, Fehlern oder Durchlaufzeit?
Ist der Aufwand vertretbar?
Wie hoch sind Pflege, Integration, Nachbearbeitung und organisatorische Abstimmung?
Ist die Lösung robust genug für den Alltag?
Funktioniert sie nicht nur in Standardfällen, sondern auch unter realistischen Bedingungen?
Ist die Datenlage ausreichend?
Reicht die Qualität der verfügbaren Daten, um die Lösung stabil zu betreiben?
Wird die Lösung im Team angenommen?
Nutzen die betroffenen Mitarbeitenden die Anwendung sinnvoll und konsistent?
Passt der Anwendungsfall zur Organisation?
Ist der Prozess geeignet, um den Einsatz weiter auszubauen?
Aus diesen Fragen ergeben sich in der Regel drei Optionen.
Weiterführen
Ein Projekt sollte weitergeführt werden, wenn der Nutzen nachweisbar ist, die Lösung im Alltag tragfähig wirkt und der Aufwand in einem vernünftigen Verhältnis zur Wirkung steht. Das bedeutet nicht, dass bereits alles perfekt sein muss. Entscheidend ist, dass die Richtung stimmt und die offenen Punkte überschaubar sind.
Anpassen
Nicht jeder Pilot liefert sofort ein klares Ja oder Nein. Oft zeigt sich, dass der Use Case richtig gewählt wurde, der Zuschnitt aber noch nicht passt. Dann kann eine Anpassung sinnvoll sein, etwa:
Scope enger fassen
Datenbasis verbessern
Prozessschritte vorab standardisieren
Nutzungslogik vereinfachen
Zielkennzahlen schärfen
Diese Variante ist vor allem dann sinnvoll, wenn ein plausibler Nutzen erkennbar ist, die Aussagekraft des ersten Piloten aber noch begrenzt bleibt.
Stoppen
Auch ein Stopp kann ein gutes Ergebnis sein. Wenn der Nutzen nicht sichtbar wird, der Aufwand zu hoch bleibt oder die Voraussetzungen nicht gegeben sind, ist ein früher Entscheid oft wirtschaftlicher als ein langes Festhalten am Projekt.
Wichtig ist dabei die saubere Dokumentation der Erkenntnisse. Ein gestopptes Vorhaben ist kein verlorenes Projekt, wenn klar festgehalten wird, warum es nicht weitergeführt wurde. Diese Erkenntnisse helfen bei späteren Priorisierungen und verhindern, dass dieselben Fehler wiederholt werden.
Wann sich eine Potenzialanalyse vor dem Pilot lohnt
Viele Schwierigkeiten in KI-Projekten entstehen nicht erst im Pilot, sondern bereits davor: Der falsche Prozess wird gewählt, die Messgrössen sind zu unscharf oder die Risiken werden zu spät erkannt. Genau deshalb lohnt sich in vielen Fällen eine vorgelagerte Potenzialanalyse.
Sie hilft dabei, vor dem Start zu klären:
Welche Prozesse sich überhaupt für KI oder Automatisierung eignen
Wo im Arbeitsalltag realistischer Nutzen entstehen kann
Welche Voraussetzungen bereits gegeben sind
Welche Risiken bei Daten, Prozessreife oder Akzeptanz bestehen
Welche Anwendungsfälle priorisiert werden sollten
Gerade für KMU ist das relevant. Nicht jeder spannende Use Case ist auch ein guter Startpunkt. Ein Projekt mit viel Sichtbarkeit, aber schwachen Grundlagen, bindet schnell Ressourcen ohne klare Wirkung. Ein kleinerer, gut geeigneter Prozess kann dagegen deutlich mehr Lernwert und bessere Entscheidungsgrundlagen liefern.
Eine Potenzialanalyse verbindet Strategie, Prozessverständnis und Priorisierung. Sie betrachtet nicht nur, was technisch möglich wäre, sondern was organisatorisch sinnvoll, messbar und wirtschaftlich vertretbar ist. Damit entsteht eine sauberere Ausgangslage für einen späteren Pilot.
Den nächsten KI-Pilot mit klarer Bewertungsbasis starten
Ein guter Start in ein KI-Projekt beginnt nicht mit der Frage nach der spannendsten Technologie, sondern mit der Frage nach dem konkreten Nutzen. Genau hier liegt der Unterschied zwischen einem reinen Machbarkeitstest und einem wertorientierten Vorgehen.
Für Schweizer KMU heisst das in der Praxis:
ein klares Zielbild definieren
Messgrössen vor dem Pilot festlegen
den Pilotumfang sinnvoll begrenzen
Datenlage und Prozessklarheit ehrlich prüfen
die Nutzerakzeptanz aktiv einbeziehen
nach dem Pilot anhand klarer Kriterien entscheiden: weiterführen, anpassen oder stoppen
Wer so vorgeht, spart spätere Korrekturen und gewinnt schneller Klarheit darüber, ob ein Vorhaben wirklich tragfähig ist. Ein Proof of Value KI ersetzt den technischen Test nicht in jedem Fall, ergänzt ihn aber um die entscheidende betriebliche Perspektive.
Wenn vor dem nächsten Pilot geklärt werden soll, welcher Prozess geeignet ist, welche Kennzahlen relevant sind und wo Chancen und Risiken liegen, ist eine strukturierte Potenzialanalyse ein sinnvoller nächster Schritt.
Häufig gestellte Fragen
Worin liegt der praktische Unterschied zwischen Proof of Concept und Proof of Value bei KI-Projekten?
Ein Proof of Concept prüft in erster Linie, ob eine KI-Lösung technisch funktioniert. Ein Proof of Value untersucht zusätzlich, ob im realen Arbeitsalltag ein messbarer Nutzen entsteht. Für KMU ist diese Unterscheidung wichtig, weil ein funktionierender Test noch nicht zeigt, ob sich der Einsatz im Betrieb tatsächlich lohnt.
Welche Kennzahlen eignen sich, um den Nutzen eines KI-Pilots im KMU zu beurteilen?
Geeignet sind vor allem prozessnahe Kennzahlen wie Zeitersparnis, Fehlerreduktion, kürzere Durchlaufzeiten, weniger manuelle Nachbearbeitung und bessere Ergebnisqualität. Ergänzend sollten auch weiche Faktoren wie Nutzerakzeptanz, Vertrauen in die Resultate und tatsächliche Nutzung im Team berücksichtigt werden.
Wie gross sollte ein KI-Pilot sein, damit die Ergebnisse verlässlich sind?
Ein KI-Pilot sollte auf einen klar abgegrenzten Prozess, ein Team oder einen konkreten Anwendungsfall fokussieren. Er muss klein genug sein, um schnell durchgeführt und ausgewertet zu werden, aber gross genug, damit reale Daten, typische Ausnahmen und tatsächliches Nutzungsverhalten sichtbar werden.
Welche Rolle spielen Datenqualität und Prozessklarheit bei einem Proof of Value?
Beides ist zentral. Schlechte oder uneinheitliche Daten verfälschen die Resultate und erschweren die Beurteilung der Lösung. Unklare Prozesse machen es fast unmöglich, Nutzen sauber zu messen. KI kann bestehende Abläufe unterstützen, ersetzt aber keine fehlende Prozessklarheit.
Wann sollte ein KI-Pilot nach dem Test weitergeführt und wann gestoppt werden?
Weitergeführt werden sollte ein Pilot, wenn der Nutzen messbar ist, der Aufwand vertretbar bleibt und die Lösung im Alltag robust funktioniert. Ein Stopp ist sinnvoll, wenn der Mehrwert ausbleibt, die Datenlage ungenügend ist oder der organisatorische Aufwand zu hoch wird. Dazwischen liegt die Option, den Ansatz gezielt anzupassen und erneut zu prüfen.
Wie hilft eine Potenzialanalyse vor dem Start eines KI-Projekts?
Eine Potenzialanalyse hilft, geeignete Prozesse zu identifizieren, Nutzen und Risiken vorab einzuschätzen und Prioritäten zu setzen. Dadurch wird vermieden, dass ein Pilot mit unklaren Zielen, falschem Scope oder schwachen Voraussetzungen startet. Für KMU schafft das eine bessere Grundlage für fundierte Entscheidungen.




