Forschung & Entdeckung · Schritt 01 · Wie wir arbeiten
Jedes OpenQCore-Engagement beginnt mit einer strukturierten Untersuchung. Bevor wir künstliche Intelligenz, Automatisierung, Software oder Infrastruktur vorschlagen, untersuchen wir das Problem als System: seine Ziele, Stakeholder, Arbeitsabläufe, Entscheidungen, Daten, Technologien, Abhängigkeiten, Einschränkungen, Risiken und messbare Ergebnisse.
Unser Discovery-Prozess kombiniert Forschung, Systemdenken, ingenieurwissenschaftliche Analyse und geschäftliche Argumentation, um von einer beobachteten Herausforderung zu einer gut begründeten Problemdefinition zu gelangen.
Denn die erste Frage sollte nicht lauten:
Nicht diese Frage
"Welche Technologie sollten wir einsetzen?"
Diese Frage hingegen
"Welches Problem lösen wir eigentlich — welche Belege stützen das, was verursacht es, und welches Ergebnis muss sich ändern?"
Forschung · Belege · Systemanalyse · Geschäftsanalyse · Messung
Warum die Entdeckungsphase an erster Stelle steht
Künstliche Intelligenz ist erheblich leichter zu erproben geworden. Experimente in messbaren organisatorischen Mehrwert zu verwandeln, bleibt deutlich schwieriger.
74%
der Unternehmen hatten noch nicht gezeigt, wie sie greifbaren Wert aus KI nachweisen und skalieren können.
BCG, Where's the Value in AI?, 2024 · n=1.000 leitende Führungskräfte.
Die BCG-Studie 2024, basierend auf 1.000 CxOs und leitenden Führungskräften aus mehr als 20 Sektoren und 59 Ländern, zeigte, dass nur 26 % der Unternehmen die Fähigkeiten entwickelt hatten, um über Proofs of Concept hinauszugehen und greifbaren Nutzen aus KI zu generieren.
Das bedeutet nicht, dass Technologie unwirksam ist. Es bedeutet, dass Technologie allein nicht ausreicht.
Organisationen können mit einem Modell, einer Plattform oder Automatisierungstechnologie beginnen und erst später entdecken, dass die zugrunde liegende Einschränkung woanders liegt: fragmentierte Prozesse, unzugängliche Daten, unklare Zuständigkeiten, Integrationsbeschränkungen, unzureichende Kontrollen, schlecht definierte Ziele oder ein Problem, das von vornherein nie gemessen wurde.
OpenQCore kehrt daher die Reihenfolge um: Technologie sollte als Folge des Verständnisses des Problems ausgewählt werden — nicht als Ersatz dafür, es zu verstehen.
Ein multidisziplinärer Ansatz
Komplexe organisatorische Probleme gehören selten nur zu einer einzigen Disziplin. OpenQCore untersucht sie aus drei ergänzenden Perspektiven.
Beobachten · Hinterfragen · Hypothesen bilden · Testen · Validieren
Wissenschaftliches Denken hilft uns, Beobachtungen von Annahmen zu unterscheiden, Fragen zu formulieren, konkurrierende Erklärungen zu prüfen und festzustellen, welche Belege eine Hypothese stützen oder widerlegen würden. Wir gehen nicht davon aus, dass die erste Erklärung die richtige ist.
Systeme · Schnittstellen · Daten · Abhängigkeiten · Einschränkungen · Zuverlässigkeit
Ingenieuranalysen untersuchen, wie Komponenten innerhalb des größeren Systems interagieren — Software, Infrastruktur, Daten, Menschen, Prozesse, Schnittstellen, externe Systeme und betriebliche Abhängigkeiten.
Diese Perspektive entspricht dem modernen Systems-Engineering-Denken. ISO/IEC/IEEE 15288:2023 definiert Systemlebenszyklusprozesse, die sowohl für einzelne Systemelemente als auch für Systeme-von-Systemen gelten, mit Beteiligung der Stakeholder während des gesamten Lebenszyklus.
Ziele · Wirtschaftlichkeit · Prozesse · Risiko · Wert · Messung
Die Geschäftsanalyse bestimmt, warum das Problem relevant ist. Wir untersuchen das gewünschte Ergebnis, die betroffenen Stakeholder, die betrieblichen Auswirkungen, wirtschaftliche Aspekte, organisatorische Einschränkungen und wie eine Verbesserung gemessen würde.
Die KI-Transformation wird oft vorwiegend in Begriffen von Modellen und Algorithmen diskutiert. Die Implementierungsbefunde deuten jedoch auf ein breiteres Bild hin: Die BCG-Forschung 2024 berichtete, dass ungefähr 70 % der Herausforderungen, denen Unternehmen bei KI-Initiativen begegneten, mit Menschen und Prozessen zusammenhingen, etwa 20 % mit Technologie und nur 10 % mit Algorithmen.
10%
Algorithmen
BCG Build for the Future 2024 Global Study · n=1.000.
20%
Technologie & Daten
BCG Build for the Future 2024 Global Study · n=1.000.
70%
Menschen & Prozesse
BCG Build for the Future 2024 Global Study · n=1.000.
Diese Prozentsätze sind das Forschungsrahmenwerk von BCG, kein universelles Gesetz. Sie unterstützen jedoch ein wichtiges ingenieurwissenschaftliches Prinzip: Das Modell ist eine Komponente eines größeren soziotechnischen Systems. Für OpenQCore untersucht die Discovery daher nicht nur die Intelligenzschicht, sondern auch die Betriebsumgebung, in die diese Intelligenz eingeführt würde.
Die OpenQCore-Forschungsmethodik
Discovery wird als strukturierte Abfolge von Untersuchungen durchgeführt. Die genaue Tiefe variiert je nach Auftrag, aber die analytische Struktur bleibt konsistent.
Welches Ergebnis ist wichtig — und für wen?
Wir beginnen damit, die Personen, Funktionen und Systeme zu identifizieren, die vom Problem betroffen sind. Die geäußerte Anfrage einer Organisation wird nicht automatisch als das zugrunde liegende Ziel behandelt — „wir brauchen einen KI-Agenten“ beschreibt eine mögliche Implementierung, noch nicht jedoch das Geschäfts- oder Ingenieurproblem.
Wir untersuchen
Stakeholder · Entscheidungsträger · Nutzer · Geschäftsziele · Betriebliche Ziele · Anreize · Abhängigkeiten · Widersprüchliche Anforderungen
Ergebnis
Stakeholder- und Zielmodell
Wie funktioniert das System heute tatsächlich?
Wir rekonstruieren den aktuellen Betriebsprozess, anstatt uns ausschließlich auf die Dokumentation dieses Prozesses zu verlassen. Wo sinnvoll, etablieren wir quantitative Referenzwerte für den bestehenden Workflow.
Die Analyse kann Folgendes umfassen
Prozesse · Aufgaben · Entscheidungen · Übergaben · Warteschlangen · Ausnahmen · Menschliches Eingreifen · Engpässe · Nacharbeit · Informationsfluss
Ergebnis
Betriebsmodell des aktuellen Zustands
In welcher technischen Umgebung arbeiten wir?
Wir untersuchen die Architektur rund um das Problem und analysieren die Datenumgebung separat. Das ist wichtig, weil eine KI-Funktion, die experimentell funktioniert, für den produktiven Einsatz ungeeignet sein kann, wenn die benötigten Informationen nicht zuverlässig, sicher oder in ausreichender Qualität zugänglich sind.
Wir untersuchen
Anwendungen · Dienste · APIs · Datenbanken · Infrastruktur · Integrationen · Identität · Sicherheit · Externe Abhängigkeiten — und Datenverfügbarkeit, Zugänglichkeit, Struktur, Qualität, Herkunft, Eigentümerschaft, Abdeckung, Aktualität und Sensibilität
Ergebnis
System- und Datenlandschaft
Welche externen Rahmenbedingungen prägen das Problem?
Eine technisch valide Lösung kann dennoch betrieblich oder kommerziell ungeeignet sein. Der Umfang hängt vom Auftrag ab — ein reguliertes Gesundheitssystem, eine Finanzplattform und ein internes Produktivitätstool erfordern nicht dieselben Formen der Kontextuntersuchung.
Soweit relevant, untersuchen wir
Marktbedingungen · Branchenstruktur · Regulierung · Technische Standards · Wettbewerbsumfeld · Technologielandschaft · Kundenerwartungen · Externe Abhängigkeiten
Ergebnis
Modell für Kontext und externes Umfeld
Was begrenzt den Lösungsraum?
Einschränkungen werden als Design-Inputs behandelt, nicht als Überraschungen, die erst während der Implementierung entdeckt werden. Wir trennen außerdem explizit bekannte Fakten, Annahmen, bekannte Unbekannte, Abhängigkeiten und Risiken — denn Unsicherheit sollte dokumentiert werden, nicht stillschweigend in Gewissheit umgewandelt.
Wir identifizieren relevante
Technische, operative, Budget- und Zeitbeschränkungen · Sicherheits-, Datenschutz- und regulatorische Anforderungen · Organisatorische Beschränkungen · Akzeptanzrisiken · Integrationsabhängigkeiten · Datenbeschränkungen
Ergebnis
Register für Beschränkungen, Annahmen und Risiken
Was genau muss sich ändern?
Die Discovery mündet in eine präzise Problemdefinition, die den beobachteten Zustand, Belege, Grundursachen, das betroffene System, den Ausgangszustand, den Zielzustand, Erfolgskriterien, Einschränkungen und explizite Nicht-Ziele umfasst.
Die Definition umfasst
Beobachteter Zustand · Belege · Grundursachen · Betroffenes System · Ausgangszustand · Zielzustand · Erfolgskriterien · Einschränkungen · Nicht-Ziele
Ergebnis
Validierte Problemdefinition
Der Discovery-Zyklus
Discovery ist nicht einfach eine Checkliste, die einmal von links nach rechts abgearbeitet wird.
Beobachten
Analysieren
Kartieren
Hypothesen bilden
Validieren
Definieren
Sobald ausreichende Gewissheit besteht: Validiertes Problem → Strategie & Architektur.
Anwendung der Methodik
Ein beobachtetes Problem und seine zugrunde liegende Ursache sind nicht unbedingt dasselbe. Betrachten wir ein vereinfachtes operatives Beispiel.
Beobachteter Zustand: Kundenanfragen benötigen 48 Stunden zur Bearbeitung.
Hinweise im Workflow: Anfragen durchlaufen mehrere manuelle Genehmigungsschritte.
Systemhinweise: Relevante Informationen liegen über mehrere voneinander getrennte Anwendungen verteilt vor.
Datenhinweise: Die gleichen Informationen werden wiederholt abgerufen und überprüft.
Hypothese zur Grundursache: Fragmentierte Arbeitsabläufe und unzugängliche Informationen führen zu wiederholter manueller Arbeit.
An diesem Punkt kann das einfache Hinzufügen einer konversationellen Schnittstelle zwar das kundenseitige Erlebnis verbessern, ohne jedoch die zugrunde liegende Verarbeitungsbeschränkung zu lösen. Die ingenieurtechnische Frage ändert sich daher von "Wie fügen wir KI hinzu?" zu "Welche Intervention verändert den kausalen Mechanismus, der das unerwünschte Ergebnis erzeugt?" — diese Unterscheidung ist zentral für Research & Discovery.
Beobachtung: Manuelle Dokumentenprüfung ist mit einem erheblichen Verarbeitungsengpass verbunden.
Hypothese: Ein kontrollierter Workflow für Dokumentenintelligenz kann die manuelle Prüfung reduzieren und gleichzeitig die erforderlichen Verifikationskontrollen aufrechterhalten.
Erforderliche Belege: Repräsentative Dokumente · Bestehende Fehlerraten · Ausnahmemuster · Prüfanforderungen · Verarbeitungszeiten
Bewertung: Extraktionsqualität · Ausnahmerate · Anteil manueller Prüfungen · Verarbeitungszeit · Ausfallarten
Entscheidung: Unterstützen · Anpassen · Hypothese verwerfen
Das Ziel ist nicht, zu beweisen, dass eine vorgeschlagene Technologie funktioniert. Das Ziel ist festzustellen, ob die Belege ihren Einsatz rechtfertigen.
Erfolg vor der Implementierung definieren
Wenn Erfolg erst nach der Implementierung definiert wird, kann fast jedes Ergebnis als Erfolg interpretiert werden. OpenQCore legt daher während der Entdeckungsphase relevante Baselines und Bewertungskriterien fest.
Durchlaufzeit
Wie lange dauert der Prozess?
Kosten pro Vorgang
Welche Ressourcen verbraucht jede Transaktion?
Fehlerrate
Wie häufig liefert der Prozess ein falsches Ergebnis?
Durchsatz
Wie viel Arbeit kann das System verarbeiten?
Menschlicher Aufwand
Wie viel manuelle Eingriffe sind erforderlich?
Zuverlässigkeit
Wie konsistent erbringt das System seine Leistung?
Qualität der Entscheidungen
Wie genau bzw. konsistent werden Entscheidungen getroffen?
Automatisierungsgrad
Welche Vorgänge können ohne manuelle Eingriffe abgeschlossen werden?
Risikoexposition
Welche Betriebs-, Sicherheits- oder Compliance-Risiken bestehen?
Erfahrungsmetriken
Wie wirkt sich der Prozess auf Kund:innen, Mitarbeitende oder andere Nutzer:innen aus?
Die Struktur ist einfach: Ausgangslage → Intervention → Ziel → Messung → Bewertung.
Wenn die gewünschte Veränderung nicht beschrieben werden kann, lässt sich der Erfolg der Lösung nicht sinnvoll bewerten.
KI erfordert eine kontextbezogene Risikoanalyse
Bei KI-bezogenen Projekten prüft die Discovery außerdem, ob die vorgeschlagene Nutzung von KI für den Kontext, in dem sie eingesetzt wird, geeignet ist. Das AI Risk Management Framework des NIST ordnet Aktivitäten zur KI-Risikobewertung vier Funktionen zu und beschreibt Risikomanagement ausdrücklich als kontinuierlichen Prozess über den gesamten KI-Lebenszyklus hinweg, statt als einmalige Compliance-Maßnahme.
Das Framework benennt außerdem Merkmale vertrauenswürdiger KI, darunter Validität und Zuverlässigkeit, Sicherheit, Resilienz, Rechenschaftspflicht und Transparenz, Erklärbarkeit und Interpretierbarkeit, Schutz der Privatsphäre sowie der Umgang mit schädlichen Verzerrungen.
Beabsichtigte Nutzung
Potenzielle Ausfallmodi
Menschliche Aufsicht
Sensibilität der Daten
Folgen von Entscheidungen
Sicherheit
Zuverlässigkeit
Anforderungen an die Bewertung
Betriebliche Kontrollen
Governance-Anforderungen
Das bedeutet nicht, dass jedes Projekt dieselbe Governance-Architektur benötigt. Risikokontrollen sollten dem System, seinem Kontext und den Folgen eines Ausfalls angemessen sein.
Belege vor einer Empfehlung
Wir suchen die Intervention, die durch die Belege gestützt wird. Aktuelle Erkenntnisse bekräftigen weiterhin die Bedeutung der Neugestaltung von Arbeitsprozessen, statt KI einfach über bestehende Abläufe zu legen.
~2/3
von Organisationen hatten noch nicht damit begonnen, KI im gesamten Unternehmen zu skalieren.
McKinsey, The State of AI: Global Survey 2025.
39%
berichteten über KI-bezogene EBIT-Auswirkungen auf Unternehmensebene.
McKinsey, The State of AI: Global Survey 2025.
Die gleiche Forschung identifiziert die Neugestaltung von Arbeitsabläufen als ein zentrales Merkmal von Organisationen, die größeren Nutzen aus KI ziehen — ein Grund, weshalb OpenQCore das Betriebsmodell rund um die Technologie untersucht, statt die Bereitstellung selbst zum Ziel zu machen.
OpenQCore beginnt die Discovery nicht mit einer vorgegebenen technischen Lösung. Die Belege können darauf hindeuten, dass die geeignete Intervention Prozessneugestaltung, Systemintegration, konventionelle Softwareentwicklung, Datenarchitektur, Workflow-Automatisierung, Analytik, künstliche Intelligenz oder eine Kombination davon ist. In manchen Fällen können die Belege zeigen, dass die Entwicklung neuer Technologie überhaupt nicht gerechtfertigt ist.
OpenQCore empfiehlt keine künstliche Intelligenz, nur weil sie gerade angesagt ist. Wir empfehlen sie, wenn Problem, Beweise, Wirtschaftlichkeit und betriebliche Einschränkungen ihren Einsatz rechtfertigen — und wir sagen klar, wenn sie das nicht tun.
Problem → Evidenz → Anforderungen → Einschränkungen → potenzielle Maßnahmen → Bewertung → Best-Fit-Ansatz — nicht: KI → irgendwo einen Einsatz suchen.
Die Auswahl der Technologie folgt der Untersuchung.
Annahmen werden identifiziert und nicht als Tatsachen dargestellt.
Wichtige Schlussfolgerungen sollten mit den sie stützenden Belegen verknüpft sein.
Bei Unsicherheit sollten konkurrierende Erklärungen in Betracht gezogen werden.
Erfolgskriterien werden nach Möglichkeit vor der Umsetzung definiert.
Unbekannte Faktoren und Einschränkungen bleiben sichtbar.
Der Analysegrad sollte die Kosten, die Komplexität und das Risiko der Entscheidung widerspiegeln.
Was Discovery produziert
Research & Discovery soll nicht mit einer Präsentation voller Beobachtungen enden. Es sollte Artefakte erzeugen, die eine technische Entscheidung informieren können. Je nach Umfang des Engagements können dies beinhalten:
Der Problemkontext, Belege, Beobachtungen und wesentliche Erkenntnisse.
Wer betroffen ist, wer Entscheidungen trifft und welche Ergebnisse von Bedeutung sind.
Wie Arbeit und Informationen heute durch die Organisation fließen.
Anwendungen, Schnittstellen, Datenquellen, Abhängigkeiten und technische Beschränkungen.
Evidenzgestützte Erklärungen für den beobachteten Zustand.
Aktuelle Leistung im Vergleich zu relevanten operativen oder technischen Kennzahlen.
Funktionale, technische, operative und Governance-Anforderungen, die während der Discovery-Phase identifiziert wurden.
Technische, Daten-, Integrations- und operative Machbarkeit, sofern erforderlich.
Potenzielle Maßnahmen, priorisiert nach Evidenz, Nutzen, Machbarkeit und Risiko.
Bekannte Einschränkungen, Annahmen, Abhängigkeiten und wesentliche Risiken.
Ziele, Kennzahlen und Bewertungsansatz.
Das Entscheidungs-Gate für die Discovery
Der Zweck der Discovery ist nicht sicherzustellen, dass ein Projekt fortgeführt wird. Es geht darum festzustellen, ob es fortgeführt werden sollte. Ein Discovery-Einsatz kann daher mit einer von mehreren Richtungen enden:
Das Problem ist ausreichend definiert, die Evidenz spricht für eine Intervention und ein technischer Umsetzungsweg erscheint machbar.
Wesentliche Unsicherheiten bleiben bestehen und zusätzliche Belege sind erforderlich.
Das ursprüngliche Problem oder die vorgeschlagene Intervention stimmt nicht mit den Untersuchungsergebnissen überein.
Das Ziel bleibt gültig, aber eine andere technische oder operative Intervention ist geeigneter.
Der erwartete Nutzen, die Machbarkeit oder das Risiko rechtfertigen keine Umsetzung.
Das Nicht-Umsetzen eines falschen Systems kann genauso wertvoll sein wie das Umsetzen des richtigen Systems.
Von Research zur Architektur
Research & Discovery existiert nicht getrennt vom Engineering-Lebenszyklus. Seine Ergebnisse werden zu Eingaben für die nächste Phase: Evidenz → Validierte Problemdefinition → Anforderungen → Beschränkungen & Risiken → Erfolgskriterien → Strategie & Architektur.
Architektur sollte nicht als Sammlung bevorzugter Technologien beginnen. Sie sollte sich aus einem nachvollziehbaren Verständnis dessen ergeben, was das System erreichen muss, unter welchen Einschränkungen, für welche Anspruchsgruppen, auf welchem akzeptablen Risikoniveau und in Bezug auf welche messbaren Ergebnisse.
Schritt 02
Leiten Sie aus einem validierten Problem eine technische Systemausrichtung ab.
Sie müssen nicht mit einer KI-Strategie ankommen. Bringen Sie die operative Herausforderung, technische Einschränkung, Forschungsfrage oder das Geschäftsziel mit. Wir beginnen damit festzustellen, was tatsächlich passiert — und was die Belege sagen, was als Nächstes geschehen sollte.
Forschungs- und methodische Referenzen
Wir geben diese Quellen offen an, statt sie zu verbergen, weil unsere Methodik auf etablierten Grundsätzen wissenschaftlicher Forschung, Systemtechnik, Requirements Engineering, Geschäftsanalyse und Risikomanagement beruht.
Boston Consulting Group — Wo liegt der Wert in KI? (2024)
Basierend auf einer Umfrage unter 1.000 CxOs und leitenden Führungskräften aus mehr als 20 Branchen und 59 Ländern; die Quelle der oben genannten 74% / 26%-Angaben und des 10–20–70-Prinzips.
McKinsey & Company — Der Stand der KI: Globale Umfrage 2025
Quelle für die Daten zur Skalierung und zum EBIT-Einfluss auf Unternehmensebene sowie für die Erkenntnis über die Bedeutung der Neugestaltung von Workflows bei leistungsstärkeren Organisationen.
ISO/IEC/IEEE 15288:2023 — System- und Softwaretechnik — Prozesse des Systemlebenszyklus
Die maßgebliche technische Referenz, um Systeme, ihre Elemente, ihren Lebenszyklus und die Stakeholder strukturiert zu betrachten.
ISO/IEC/IEEE 29148:2018 — Requirements Engineering
Legt Prozesse und Informationsgegenstände für das Requirements Engineering über System- und Softwarelebenszyklen hinweg fest; ISO bestätigte die Ausgabe nach einer Prüfung im Jahr 2024 als aktuell.
NIST — Risikomanagementrahmen für Künstliche Intelligenz (AI RMF 1.0)
Unterstützt kontextbezogenes KI-Risikodenken durch Govern, Map, Measure and Manage, mit kontinuierlichem Risikomanagement über den KI-Lebenszyklus hinweg. Das AI RMF 1.0 von NIST befindet sich in aktiver Überarbeitung, weshalb wir die Version ausdrücklich nennen, anstatt zu suggerieren, sie sei stets die aktuellste endgültige Veröffentlichung.
