Datenbasis für KI im Unternehmen: Was Papier, Excel und E-Mail bereits ermöglichen

Ein Auftrag beginnt als E-Mail mit PDF-Anhang. Eine Mitarbeiterin überträgt Kunde, Termin und Positionen in die Auftragssoftware. Die Einsatzplanung steht in Excel, der Techniker ergänzt vor Ort einen Papierbericht und die Rückfrage des Kunden landet später in einem anderen Postfach. Alle benötigten Informationen existieren. Trotzdem gibt es noch keine belastbare Datenbasis für KI im Unternehmen, weil Identitäten, Zeitpunkte und bestätigte Ergebnisse nicht durchgängig verbunden sind.

Das führt in klassischen Betrieben zu zwei gegensätzlichen Fehleinschätzungen. Die eine lautet: „Unsere Daten sind nicht perfekt, also können wir noch jahrelang keine KI einsetzen.“ Die andere: „Ein großes Sprachmodell versteht das schon, wenn wir alle Dateien hochladen.“ Beides greift zu kurz.

Ein Unternehmen benötigt für den Einstieg weder ein vollständiges Data Warehouse noch lückenlos digitalisierte Archive. Es braucht die kleinste ausreichende Datenbasis für einen klar abgegrenzten Anwendungsfall. Ein Modell kann ungeordnete Dokumente strukturieren und mögliche Zusammenhänge vorschlagen. Es kann fehlende Identitäten, unbekannte Prozessschritte und widersprüchliche Fachentscheidungen nicht dauerhaft zuverlässig reparieren.

SW Business Solutions prüft deshalb zuerst einen realen Vorgang, seine Quellen und das gewünschte Ergebnis. Vorhandene ERP-, CRM-, DMS-, Fach- und Office-Systeme bleiben erhalten, wenn sie ihre Aufgabe erfüllen. Fehlende Verbindungen, Prüfoberflächen und KI-Komponenten werden passend zum Betrieb entwickelt.

Die Datenbasis für KI im Unternehmen beginnt beim gewünschten Ergebnis

„Wir wollen unsere Daten mit KI nutzen“ beschreibt noch keinen Anwendungsfall. Die notwendige Datengrundlage unterscheidet sich je nachdem, ob ein Unternehmen Dokumente zuordnen, Nachfrage prognostizieren, Bilder prüfen oder internes Wissen auffindbar machen möchte.

Vor der Dateninventur werden fünf Punkte festgelegt:

1. Welcher konkrete Vorgang soll sich verändern?
2. Welche Entscheidung oder Arbeit soll das System vorbereiten?
3. Was gilt als überprüfbar richtiges Ergebnis?
4. Wer prüft oder korrigiert das Ergebnis?
5. An welcher Kennzahl wird der Nutzen gemessen?

Für die Zuordnung einer Bestellung zu einem Kundenauftrag werden Originaldokument, Kundenidentität, Auftragsnummern und bestätigte Zuordnungen benötigt. Eine Absatzprognose braucht dagegen Zeitreihen, Verfügbarkeit, Sortimentsänderungen und erkennbare Sonderereignisse. Ein PDF-Archiv kann für die erste Aufgabe wertvoll und für die zweite nahezu unbrauchbar sein.

Die Datenqualität wird deshalb immer bezogen auf den Verwendungszweck bewertet. Ein fehlendes Telefonnummernformat stört eine Teileprognose kaum, verhindert aber möglicherweise einen automatischen Rückrufprozess.

Die kleinste ausreichende Datenbasis besteht aus einem vollständigen Lernkreis

Ein KI-System braucht nicht zwingend sehr viele Felder. Es benötigt jedoch einen nachvollziehbaren Zusammenhang zwischen Eingabe, Kontext, Ergebnis und Rückmeldung.

Fehlt die fachliche Rückmeldung, kann ein Projekt zwar Texte klassifizieren, aber seine betriebliche Qualität kaum bewerten. Wenn Mitarbeitende Korrekturen nur telefonisch abstimmen und nicht im System erfassen, sieht der Datensatz eine falsche Zuordnung als scheinbar erfolgreich an.

Ein kleiner, sauber bestätigter Datenbestand kann für einen begrenzten Pilot geeigneter sein als ein großes Archiv ohne verlässliches Ergebnis. Die benötigte Menge hängt von Aufgabe, Variantenbreite, Fehlerkosten und gewählter Methode ab. Dafür gibt es keine seriöse allgemeine Mindestzahl.

Eine Quelleninventur zeigt, welche Wahrheit wo entsteht

Die Bestandsaufnahme beginnt nicht mit dem Export aller Dateien. Zuerst werden Systeme, Ordner, Postfächer, Listen und Papierbelege entlang eines Vorgangs erfasst.

Für jede Quelle werden dieselben Fragen beantwortet:

• Welche Information entsteht hier erstmals?
• Wer pflegt oder bestätigt sie?
• Welche Identität verbindet sie mit anderen Quellen?
• In welchem Format und Zeitraum liegt sie vor?
• Kann sie vollständig und wiederholbar exportiert werden?
• Welche Berechtigungen und Aufbewahrungsregeln gelten?
• Welche bekannten Fehler oder Ausnahmen gibt es?

Das Ergebnis ist kein allgemeines IT-Inventar, sondern eine Prozesskarte. Im Beispiel kann das CRM den Kunden führen, die Fachsoftware den Auftrag, Excel die operative Reihenfolge, das Postfach die Originalanfrage und der Papierbericht den Befund. Die Frage lautet nicht, welches System „am modernsten“ ist. Entscheidend ist, welches System für welches Objekt führend bleibt.

Das Fraunhofer ISST nennt in einem 2026 veröffentlichten Data-Readiness-Framework fünf Dimensionen für datenintensive Anwendungen: Metadaten, Datenherkunft und Verarbeitungslinie, Datenqualität, Interoperabilität und Data Governance. Der Ansatz wurde an drei Digital-Twin-Demonstratoren erprobt. Er liefert damit einen nützlichen Prüfrahmen, aber keine pauschale Reifezertifizierung für jeden Betrieb.

Papier ist eine Datenquelle, aber noch kein durchsuchbarer Prozess

Papierberichte enthalten häufig Unterschriften, Messwerte, Skizzen und Fachbeobachtungen. Sie müssen nicht vollständig rückwirkend digitalisiert werden. Ein Betrieb sollte zuerst klären, welche Dokumenttypen für den ausgewählten Anwendungsfall benötigt werden.

Ein kontrollierter Digitalisierungsweg trennt:

1. Scan oder Foto als unverändertes Original
2. Bildverbesserung und Texterkennung
3. extrahierte Felder mit technischer Sicherheit
4. fachlich bestätigte Werte
5. Zuordnung zu Kunde, Auftrag, Anlage oder Projekt

Ein Sprach- oder Dokumentenmodell kann „Dichtung am Flansch erneuert“ erkennen. Ohne eindeutige Anlagen- und Auftragsnummer bleibt unklar, zu welchem Betriebsmittel der Befund gehört. Der Scan wird deshalb nicht durch einen KI-Text ersetzt. Original, Extraktion und Bestätigung bleiben getrennt.

Für neue Vorgänge kann ein besseres mobiles Formular wirtschaftlicher sein als die dauerhafte Erkennung handschriftlicher Berichte. Altakten werden nur dann aufgearbeitet, wenn ihr Informationswert die Kosten rechtfertigt. Der Beitrag zur Dokumentenverarbeitung mit KI zeigt diesen Datenweg für Rechnungen, Verträge und Formulare ausführlicher.

Excel ist nicht automatisch ein Ausschlusskriterium

Eine Excel-Datei kann für einen Pilot ausreichen, wenn Spalten eindeutig, Einheiten stabil und Änderungen nachvollziehbar sind. Problematisch wird sie, wenn Farben fachliche Zustände ausdrücken, mehrere Tabellen dieselben Objekte unterschiedlich benennen oder Formeln beim Kopieren unbemerkt verändert werden.

Vor der Nutzung werden mindestens folgende Punkte geprüft:

• eine Zeile beschreibt genau ein fachliches Ereignis oder Objekt
• Spalten haben feste Bedeutung und Datentypen
• Datum, Dezimaltrennzeichen und Einheiten sind eindeutig
• leere Zelle, Null und „nicht zutreffend“ werden unterschieden
• Kunden, Artikel oder Anlagen besitzen stabile Kennungen
• Formeln und manuelle Eingaben sind erkennbar getrennt
• Version, Quelle und Stichtag sind dokumentiert

Zusammengeführte Zellen, wechselnde Überschriften und Kommentare als einziges Fehlerprotokoll erschweren einen wiederholbaren Import. Diese Mängel lassen sich häufig durch eine kontrollierte Vorlage oder einen Importdienst beheben. Ein vollständiger Systemwechsel ist dafür nicht notwendig.

Excel bleibt ungeeignet als dauerhafte führende Datenbank, wenn viele Personen gleichzeitig schreiben, Berechtigungen differenziert sein müssen oder jede Änderung revisionsnah nachvollziehbar sein soll. Dann benötigt der Prozess eine zentrale Anwendung oder einen klaren Übergang in das Fachsystem.

E-Mail liefert Kontext, aber keine sichere Stammdatenidentität

E-Mails enthalten Anfrage, Tonfall, Anlagen und Gesprächsverlauf. Sie sind wertvoll für Klassifikation und Zusammenfassung. Absenderadresse und Signatur reichen jedoch nicht immer für die eindeutige Zuordnung zu einem Kunden, Standort oder Vertrag.

Ein belastbarer E-Mail-Prozess prüft Absenderdomäne, bekannte Kontakte, Referenznummern, offene Vorgänge und genannte Standorte. Das System zeigt mögliche Treffer mit den verwendeten Merkmalen. Bei mehreren plausiblen Kunden fragt es nach oder legt einen Klärfall an.

Weitergeleitete Nachrichten und lange Verläufe enthalten veraltete Angaben. Anlagen können frühere Versionen sein. Die Verarbeitung trennt deshalb neue Nachricht, zitierte Historie und Anhänge. Ein Modell darf eine alte Terminangabe nicht als aktuellen Auftrag übernehmen.

Gemeinsame Postfächer benötigen Zuständigkeit und Status. Wenn Mitarbeitende parallel antworten, entsteht trotz guter Klassifikation doppelte Arbeit. In diesem Fall löst ein Ticket- oder CRM-Workflow den Engpass zuverlässiger als zusätzliche KI.

Stammdaten geben variablen Informationen eine Identität

Kundenname, Artikelbezeichnung oder Maschinenname können sich in Dokumenten unterschiedlich schreiben. Eine stabile interne ID verbindet diese Varianten mit demselben Objekt. Ohne diese Identität entstehen Dubletten, zersplitterte Historien und falsche Auswertungen.

Wichtige Stammdatenobjekte sind je nach Betrieb Kunden, Standorte, Kontakte, Artikel, Anlagen, Fahrzeuge, Mitarbeiterrollen und Verträge. Für jedes Objekt wird festgelegt:

• welches System die führende ID vergibt
• welche Pflichtmerkmale gelten
• wer neue Datensätze anlegt und freigibt
• wie Dubletten behandelt werden
• wie Änderungen und Gültigkeitszeiträume abgebildet werden
• wie alte Kennungen weiter zugeordnet bleiben

KI kann ähnliche Namen und mögliche Dubletten finden. Sie sollte Kunden oder Anlagen nicht automatisch zusammenführen. Zwei gleich benannte Niederlassungen können rechtlich oder betrieblich getrennte Einheiten sein.

Eine gute Stammdatenbasis verringert zugleich den KI-Bedarf. Wenn Lieferantenartikelnummern bereits in einer gepflegten Zuordnungstabelle stehen, ist ein deterministischer Lookup verlässlicher und günstiger als eine semantische Suche.

Datenqualität besitzt mehrere unabhängige Dimensionen

„Die Daten sind zu schlecht“ ist keine verwertbare Diagnose. Qualität wird je Feld und Aufgabe getrennt betrachtet:

Das Fraunhofer IPT beschreibt für Produktionsdaten eine Vorverarbeitung aus Integration, Bereinigung, Erweiterung, Reduktion und Transformation. Die Reihenfolge zeigt: Zusammenführen und Bereinigen sind eigene fachliche Arbeitsschritte. Eine automatisierte Vorverarbeitung kann sie unterstützen, aber nicht jede Lücke korrekt interpretieren.

Ein fehlender Messwert kann einen Sensorausfall, eine nicht durchgeführte Messung oder einen Exportfehler bedeuten. Eine statistische Ergänzung wäre nur dann vertretbar, wenn Zweck und Fehlerfolgen dies zulassen. Für einen abrechnungs- oder sicherheitsrelevanten Einzelwert kann sie unzulässig sein.

Historische Daten zeigen häufig den alten Prozess

Ein Modell lernt aus der Vergangenheit. Wenn sich Sortiment, Personal, Maschinen, Preise oder Erfassung geändert haben, beschreibt ein Teil der Historie nicht mehr den heutigen Ablauf. Eine große Zeitspanne ist daher nicht automatisch besser.

Vor einem Pilot werden Prozessbrüche markiert:

• Einführung oder Wechsel eines Fachsystems
• neue Artikel- oder Anlagenkennungen
• veränderte Geschäftszeiten oder Zuständigkeiten
• neue Formulare und Pflichtfelder
• außergewöhnliche Betriebsunterbrechungen
• geänderte Preis-, Vertrags- oder Qualitätsregeln

Diese Zeiträume können getrennt ausgewertet, mit Merkmalen gekennzeichnet oder ausgeschlossen werden. Die Entscheidung wird dokumentiert. Andernfalls interpretiert ein Modell den Systemwechsel möglicherweise als reale Veränderung der Nachfrage oder Fehlerhäufigkeit.

Für die spätere Qualitätsprüfung werden ältere Daten zum Entwickeln und zeitlich spätere Daten zum Testen verwendet. Ein zufälliges Vermischen kann dazu führen, dass fast identische Vorgänge in beiden Mengen auftauchen und die Leistung zu gut erscheint.

Ein fachliches Ziel benötigt bestätigte Beispiele

Bei überwachtem Machine Learning wird ein Ziel benötigt: richtige Dokumentklasse, bestätigte Störung, tatsächlicher Bedarf oder fachlich festgestellter Fehler. Dieses Label ist nicht automatisch korrekt, nur weil es in einer Datenbank steht.

Ein Storno kann beispielsweise Nachfrageausfall, Lieferproblem, Doppelerfassung oder Kundenentscheidung bedeuten. Werden alle Fälle als „kein Bedarf“ markiert, lernt eine Prognose eine falsche Ursache. Freitextgründe müssen gegebenenfalls in ein fachlich definiertes Schema überführt werden.

Die verantwortlichen Fachkräfte legen fest, welche Beispiele eindeutig sind und welche als unsicher gelten. Uneinigkeit wird nicht durch Mehrheitsabstimmung verdeckt. Sie zeigt möglicherweise, dass die Zieldefinition selbst unklar ist.

Für Such- und Assistenzsysteme werden statt Trainingslabels freigegebene Dokumente, Metadaten und Berechtigungen benötigt. Auch dort ist ein Prüfset sinnvoll: typische Fragen, erwartete Quelle und Fälle, in denen keine Antwort gegeben werden darf.

Nicht jeder KI-Anwendungsfall benötigt eigenes Modelltraining

Die Datenanforderung hängt von der technischen Lösung ab:

• Regelautomatisierung benötigt eindeutige Felder und fachliche Bedingungen.
• Standard-KI-Dienst verarbeitet neue Dokumente oder Texte anhand definierter Ausgaben.
• Wissenssuche mit Sprachmodell benötigt freigegebene Dokumente, Metadaten und Zugriffsregeln.
• Prognosemodell benötigt historische Zeitreihen, Einflussgrößen und bestätigte Zielwerte.
• Bildmodell benötigt repräsentative, korrekt gekennzeichnete Aufnahmen aus dem späteren Einsatz.

Ein Betrieb muss nicht sämtliche Unternehmensdaten in ein Sprachmodell laden. Für die Klassifikation einer Service-E-Mail genügen möglicherweise Nachricht, ausgewählte Stammdaten und offene Vorgänge. Preise, Personalakten und fremde Projekte gehören nicht in diesen Datenfluss.

Der Fraunhofer-IIS-Ansatz für KI-Readiness bewertet einen konkreten unternehmensspezifischen Anwendungsfall nach wirtschaftlichem Nutzen, technischer Machbarkeit sowie Akzeptanz und Reife. Datenverfügbarkeit und Datenqualität sind Teil dieser Prüfung. Genau diese Eingrenzung verhindert, dass eine allgemeine „KI-Reife“ ohne Bezug zum Prozess behauptet wird.

Zugängliche Daten sind mehr als sichtbare Daten

Informationen können in einer Anwendung sichtbar, aber technisch kaum wiederholbar exportierbar sein. Ein manueller CSV-Export eignet sich für einen einmaligen Test. Für den Betrieb braucht es einen definierten Zugriff mit Zeitstempel, Schema, Berechtigung und Fehlerbehandlung.

Bei jeder Quelle wird geprüft:

• vorhandene API, Datenbankansicht oder geplanter Datei-Export
• vollständiger oder inkrementeller Abruf
• stabile Kennungen und Änderungszeitpunkte
• Rate Limits, Lizenz- und Nutzungsbedingungen
• Rückschreibemöglichkeit und erlaubte Felder
• Verhalten bei Ausfall und Wiederholung

Der Beitrag Systemintegration im Mittelstand ordnet APIs, EDI, Middleware und Dateiwege ein. SW Business Solutions entwickelt bei Bedarf API-Schnittstellen und individuelle Konnektoren, ohne das führende Fachsystem durch eine parallele KI-Datenbank zu ersetzen.

Datenherkunft und Versionen müssen bis zum Ergebnis sichtbar bleiben

Ein zusammengeführter Datensatz darf seine Herkunft nicht verlieren. Für jedes relevante Feld werden Quelle, Importzeit, Transformation und gegebenenfalls manuelle Korrektur gespeichert. Das ermöglicht eine konkrete Fehleranalyse.

Wenn ein Modell einen Auftrag falsch zuordnet, muss erkennbar sein, ob die Kundennummer bereits im Eingang fehlte, beim Import abgeschnitten wurde oder das Modell trotz korrekter Daten falsch entschied. Ohne diese Linie wird jeder Fehler pauschal der KI zugeschrieben oder im Gegenteil als Anwenderproblem abgetan.

Auch Modell, Prompt, Regeln und Wissensbestand erhalten Versionen. Ein später erneut verarbeiteter Vorgang kann sonst ein anderes Ergebnis liefern, ohne dass die Ursache nachvollziehbar ist. Die Softwarearchitektur von SW Business Solutions legt diese Zuständigkeiten und Protokolle vor der Produktivsetzung fest.

Zugriffsrechte gelten auch für Suche, Training und Test

Eine KI-Suche darf nicht mehr Informationen offenlegen als die ursprünglichen Systeme. Dokumente aus Personal, Recht, Kalkulation oder Kundenprojekten benötigen getrennte Berechtigungen. Eine gemeinsame Volltextsuche ohne Rollenprüfung kann bestehende Schutzgrenzen aufheben.

Vor der Nutzung werden Zweck, betroffene Personen, erforderliche Felder, Aufbewahrung und mögliche externe Dienste geprüft. Testdaten werden minimiert oder geeignet pseudonymisiert, wenn echte Identitäten für die Aufgabe nicht nötig sind. Eine Kopie auf einem Entwicklerrechner ist keine neutrale Zwischenablage.

Bei externen Modellen werden Datenfluss, Speicherort, Protokollierung, Unterauftragnehmer, Aufbewahrung und Löschung technisch und vertraglich bewertet. Sensible Daten werden nicht allein deshalb übertragen, weil ein Anbieter die Eingabe technisch ermöglicht.

Korrekturen benötigen einen kontrollierten Rückweg

Mitarbeitende müssen einen Vorschlag bestätigen, ändern oder ablehnen können. Die Oberfläche zeigt Eingabe, verwendete Quellen und erzeugtes Ergebnis nebeneinander. Eine Korrektur erfasst möglichst einen fachlichen Grund.

Diese Rückmeldung verbessert zunächst den einzelnen Vorgang. Sie darf nicht automatisch jedes Modell verändern. Ein Sonderfall, Kulanz oder bewusster Regelverstoß würde sonst als neuer Standard gelernt. Geeignete Korrekturen werden gesammelt, geprüft und versioniert in Regeln, Wissensbestand oder Trainingsdaten übernommen.

Ebenso wichtig ist die Meldung „keine sichere Entscheidung möglich“. Ein Modell, das jeden Vorgang zwangsweise einer Klasse zuordnet, verdeckt Datenlücken. Eine Klärklasse mit messbarem Anteil ist im Betrieb wertvoller als künstliche Vollständigkeit.

Ein Data Warehouse ist mögliche Ausbaustufe, keine Eintrittskarte

Für einen begrenzten Pilot können kontrollierte Exporte aus zwei oder drei Quellen genügen. Eine kleine Integrationsschicht vereinheitlicht Kennungen, prüft Schema und stellt einen versionierten Datensatz bereit. Erst wenn mehrere Anwendungsfälle dauerhaft dieselben Daten benötigen, kann eine zentrale Datenplattform wirtschaftlich werden.

Die Entscheidung hängt von Aktualität, Volumen, Nutzerzahl, Historisierung, Berechtigungen und Betriebsverantwortung ab. Eine Datenbank allein schafft keine Governance. Ohne fachliche Eigentümer und Qualitätsregeln wird lediglich die Unordnung zentral kopiert.

Die Datenanalyse von SW Business Solutions beginnt deshalb mit Quelle und Verwendung. Dashboard, Datenplattform oder Modell folgen aus dem konkreten Informationsbedarf, nicht aus einem vorab gewählten Architekturtrend.

Der Go-/No-Go-Check trennt lösbare Lücken von echten Blockern

Vor dem Pilot wird jeder Punkt mit einem belegbaren Status bewertet:

„Erst verbessern“ ist kein Scheitern. Oft entsteht daraus ein kleines Digitalisierungsprojekt: eindeutige Auftragsnummer im Betreff, strukturierter Abschlussgrund, mobile Erfassung oder automatischer Export. Danach kann derselbe Anwendungsfall erneut geprüft werden.

Ein Pilot verwendet einen repräsentativen, abgegrenzten Datenausschnitt

Ein sinnvoller Einstieg ist die Klassifikation und Zuordnung eines wiederkehrenden Anfrageformats. Der Pilot kann so ablaufen:

1. Prozess, Zielklasse und Fehlerkosten festlegen.
2. Quellen und führende Identitäten dokumentieren.
3. einen zusammenhängenden historischen Zeitraum exportieren
4. Dubletten, fehlende Werte und Prozessbrüche untersuchen
5. eindeutige Beispiele fachlich bestätigen
6. eine einfache Regel- oder manuelle Baseline definieren
7. KI auf einem getrennten späteren Zeitraum prüfen
8. Vorschläge im Schattenbetrieb neben dem heutigen Prozess anzeigen
9. Klärfälle, Korrekturen und Bearbeitungszeit messen
10. anhand vorher definierter Kriterien über den nächsten Schritt entscheiden

Der Pilot enthält keine automatisch erzeugten Erfolgsbeispiele. Fälle, die Mitarbeitende wegen fehlender Informationen nicht sicher entscheiden können, bleiben auch im Prüfdatensatz unsicher. Das schützt vor einer scheinbar hohen Qualität auf künstlich vereinfachten Daten.

SW Business Solutions prüft Daten und Prozess gemeinsam

SW Business Solutions beginnt nicht mit dem Verkauf eines Modells. Gemeinsam mit Fachbereich und IT wird ein realer Vorgang verfolgt: vom Eingang über Stammdaten und Entscheidung bis zur Korrektur. Dadurch wird sichtbar, welche Daten bereits ausreichen und welche Lücke den Einsatz tatsächlich blockiert.

Die Umsetzung kann folgende Bausteine umfassen:

• Quellen- und Prozessinventur
• Datenqualitätsprofil für relevante Felder
• Mapping von Kunden, Aufträgen, Artikeln oder Anlagen
• strukturierte Exporte und Schnittstellen
• Dokumenten- und E-Mail-Verarbeitung
• Prüfoberfläche und Klärwarteschlange
• versionierter Test- und Bewertungsdatensatz
• Rollen, Protokollierung und Monitoring
• begrenzter KI- oder Automatisierungspilot

Die KI-Integration von SW Business Solutions verbindet geeignete Standarddienste oder individuelle Modelle mit den vorhandenen Systemen. Wo ein Formular, eine feste Regel oder klassische Automatisierung genügt, wird keine unnötige KI-Schicht aufgebaut.

Für den ersten Check reichen ein typischer Vorgang, die beteiligten Dateien und ein fachlich bestätigtes Ergebnis. SW Business Solutions ermittelt daraus die kleinste belastbare Datenbasis und einen messbaren nächsten Schritt. So wird ein Projekt weder wegen unperfekter Daten vorschnell verworfen noch mit ungeklärten Voraussetzungen gestartet.