Mittelstand
KI auf den eigenen Daten – ohne Daten
Die üblichen KI-Vorhaben scheitern im Mittelstand nicht an der Technik, sondern an der Reihenfolge: Erst soll eine Datenplattform entstehen, dann ein Team, dann ein Anwendungsfall. Nach zwei Jahren gibt es Infrastruktur und noch keine beantwortete Frage. Dieser Weg dreht die Reihenfolge um.
Warum es üblicherweise scheitert
Die Voraussetzungen sind meist da. Die Reihenfolge ist falsch.
Ein mittelständisches Unternehmen mit einer gewachsenen Individual- oder Branchensoftware hat fast immer genau das, worauf es ankommt: eine Datenbank mit Jahren echter Geschäftsvorfälle und einen Sourcecode, in dem die Fachlogik steht. Was fehlt, sind nicht Daten, sondern eine Beschreibung ihrer Bedeutung.
Trotzdem beginnen KI-Vorhaben regelmäßig mit dem Aufbau einer Plattform: Datendrehscheibe, Warehouse, Lakehouse, Kompetenzteam. Das ist nicht falsch gedacht, aber es ist teuer, langsam und – entscheidend – es liefert bis zum Schluss keinen prüfbaren Nutzen.
Nach zwei Jahren steht dann Infrastruktur, für die niemand mehr einen Anwendungsfall benennen kann, der nicht auch vorher schon möglich gewesen wäre.
Der Einstieg hier braucht diese Vorarbeit nicht. Datenmodell und Sourcecode des vorhandenen Systems werden gelesen; daraus entsteht die Beschreibung ihrer Bedeutung. Das System bleibt unverändert, es wird nichts migriert und keine zweite Datenhaltung aufgebaut.
Der erste prüfbare Nutzen ist damit keine Plattform, sondern eine beantwortete Frage – gestellt von jemandem aus Ihrem Fachbereich, mit einem Ergebnis, das er selbst beurteilen kann.
Voraussetzungen
Was Ihr Haus tatsächlich mitbringen muss.
Vier Dinge. Keines davon ist ein Projekt, drei davon sind Zugänge.
Eine relationale Datenbank mit lesendem Zugang
Umgesetzt sind PostgreSQL und MySQL. Ein lesender Benutzer genügt; es wird nichts geschrieben, nichts angelegt und nichts verändert.
Lesenden Zugriff auf den Sourcecode
Dort steht die Fachlogik, die im Schema fehlt – Statusbedeutungen, Berechnungen, Fallunterscheidungen. Ohne diesen Zugriff müsste die Bedeutung erraten werden, und genau das soll der Ansatz vermeiden.
Zwei Personen aus dem Fachbereich
Menschen, die beurteilen können, ob eine Zahl stimmt. Sie sind der wichtigste Beitrag – nicht als Projektrolle, sondern in Form von einigen Stunden verteilt über die Pilotphase.
Eine Handvoll echter Fragen
Fragen, deren Antwort Sie heute nicht kennen oder nur mit Aufwand bekommen. Sie sind der Maßstab: Was daran nicht funktioniert, ist ein Befund und keine Ausrede.
Nicht nötig sind: ein Data Warehouse, ein Datenkatalog, ein KI-Team, eine bereinigte Datenbasis oder eine aktuelle Dokumentation. Veraltete Dokumentation ist der Normalfall und kein Hindernis – gelesen wird der Code, nicht das Handbuch.
Zwei Wege
Plattform zuerst oder Frage zuerst.
Beide Wege können am Ende funktionieren. Sie unterscheiden sich darin, wann Sie erfahren, ob sie funktionieren.
Der kleinste sinnvolle Anfang
Ein System, fünf Fragen, ein Fachbereich.
Nicht das ganze Unternehmen und nicht alle Datenquellen. Der Zuschnitt ist bewusst klein, damit das Ergebnis eindeutig ist.
- 1
Ein System auswählen
Das System, in dem das meiste Geschäftswissen steckt – meist die zentrale Branchen- oder Individualsoftware. Weitere Quellen kommen später oder gar nicht.
- 2
Fünf Fragen aufschreiben
Fragen aus dem Alltag eines Fachbereichs, deren Antwort heute Aufwand kostet. Bei zwei davon sollten Sie die richtige Antwort kennen – das sind Ihre Kontrollfälle.
- 3
Analyse und erste Antworten
Datenmodell und Sourcecode werden gelesen, die semantische Schicht entsteht KI-gestützt. Innerhalb weniger Stunden steht eine Basis, mit der sich diese Fragen stellen lassen.
- 4
Gemeinsam bewerten
Ihre Fachleute prüfen die Antworten. Wo eine falsch ist, wird die zugrunde liegende Regel korrigiert – nicht die Antwort. Danach gilt die Korrektur für jede gleichartige Frage.
- 5
Entscheiden
Am Ende steht eine belegte Einschätzung, ob der Ansatz in Ihrem System trägt. Wenn nicht, haben Sie eine Antwort und keine Plattform, die Sie danach betreiben müssen.
Aufwand und Risiko
Was der Einstieg intern kostet.
Ehrlich benannt, soweit es sich ohne Kenntnis Ihres Systems benennen lässt. Alles, was von Datenmodell und Fragestellung abhängt, wird im Gespräch geklärt statt hier pauschaliert.
- Interne Arbeitszeit
- Im Wesentlichen die Zeit Ihrer Fachleute für das Formulieren und Bewerten der Fragen, verteilt über die Pilotphase. Kein eigenes Projektteam, keine freigestellte Stelle.
- IT-Aufwand
- Lesender Datenbankzugang, Zugriff auf den Sourcecode und eine Umgebung für den Betrieb als Container. Keine Änderung an bestehenden Anwendungen.
- Eingriff in den Betrieb
- Keiner. Der Zugriff ist ausschließlich lesend; das laufende System wird nicht verändert und nicht abgeschaltet.
- Bindung
- Individuelle Einführung, danach monatliche Plattformlizenz. Der Umfang der Einführung hängt von Datenmodell und Fragestellung ab und wird vorab unverbindlich geklärt.
- Ausstieg
- Zugang entziehen, Container abschalten. Es bleibt kein veränderter Datenbestand zurück, weil keiner angelegt wurde. Die semantische Schicht ist Ihr Eigentum und bleibt lesbar.
- Entwicklungsstand
- Pilot- und Validierungsphase. Das Produkt entsteht derzeit mit einer kleinen Zahl von Pilotkunden – wer jetzt einsteigt, prägt mit, was als Nächstes umgesetzt wird. Der heutige Stand steht offen auf den Produktseiten.
Wann ein anderer Weg näher liegt
Drei Fälle, in denen wir zuerst woandershin zeigen.
Wenn Ihr Geschäftswissen nicht in einer Datenbank, sondern in Dokumenten, Mails und Dateiablagen steckt: Heute werden relationale Datenbestände ausgewertet, die Anbindung von Dokumenten ist in Arbeit. Melden Sie sich trotzdem – genau solche Fälle entscheiden mit, was als Nächstes entsteht.
Wenn Sie eine Standardsoftware einsetzen, für die der Hersteller fertige Auswertungen liefert, und Ihre Fragen darin vorkommen. Dann ist der Weg über den Hersteller günstiger – und das sagen wir Ihnen lieber vorher als hinterher.
Wenn heute noch niemand im Haus verbindlich sagen kann, ob eine Antwort fachlich stimmt. Diese eine Person ist die Voraussetzung, an der alles hängt: Gibt es sie, ist der Rest Handwerk. Gibt es sie noch nicht, ist sie der erste Schritt – und dabei helfen wir.
Häufige Fragen
Fehlt Ihnen eine Frage? Ausführliche Antworten zu Betrieb und Datenzugriff stehen auf der Sicherheitsseite.
- Wir haben keine Datenabteilung. Geht das trotzdem?
Ja, und das ist der Regelfall in dieser Größenklasse. Gebraucht werden keine Data Engineers, sondern Menschen, die Ihre Fachlichkeit kennen – meist sind das dieselben Personen, die heute die Sonderauswertungen in Excel bauen.
Die technische Arbeit an der semantischen Schicht liegt nicht bei Ihnen. Was bei Ihnen liegt, ist die fachliche Entscheidung, ob eine Definition richtig ist.
- Sollten wir nicht auf die KI-Funktion unseres Softwareanbieters warten?
Wenn Ihr Anbieter eine solche Funktion angekündigt hat und Ihre Fragen damit beantwortet werden, ist das der einfachere Weg. Das lohnt sich zu prüfen, bevor man etwas Eigenes beginnt.
Zwei Dinge sollten Sie dabei klären: ob die Funktion Ihre eigenen Anpassungen und Zusatzfelder kennt – gewachsene Installationen unterscheiden sich vom Standard – und wo die Verarbeitung stattfindet. Bei einer Cloud-Funktion des Anbieters ist die Frage nach dem Datenabfluss neu zu stellen.
- Wir haben ERP, CRM und eine Eigenentwicklung. Womit fangen wir an?
Mit dem System, in dem die Fragen entstehen, die Sie heute nicht beantworten können. Das ist meist nicht das größte System, sondern das mit der eigensten Fachlichkeit.
Systemübergreifende Auswertungen sind möglich, aber der falsche Anfang: Sie verdoppeln den Analyseaufwand, bevor geklärt ist, ob der Ansatz in Ihrem Haus überhaupt trägt.
- Unsere Datenqualität ist nicht gut. Müssen wir erst aufräumen?
Nein – und in der Praxis ist es umgekehrt nützlich. Weil jede Antwort ihre Herleitung mitführt, werden Datenprobleme als solche sichtbar, statt sich in einer Kennzahl zu verstecken.
Ein Aufräumprojekt vorweg hat dasselbe Problem wie ein Plattformprojekt: Es kostet, bevor jemand weiß, welche Felder überhaupt gebraucht werden. Nach den ersten echten Fragen ist diese Liste deutlich kürzer.
- Reicht unsere Systemausstattung dafür aus?
Betrieben wird die Schicht als Container; die Anforderungen liegen im Bereich einer normalen Serveranwendung. Die Datenbanklast entspricht der einer lesenden Auswertung, nicht der eines zweiten Systems.
Was von Ihrer Umgebung abhängt, ist die Frage, ob und wie ein Sprachmodell erreichbar ist – im Betriebsmodus mit externem Modell braucht es eine ausgehende Verbindung. Ein vollständig lokal betriebenes Modell ist in Arbeit.
Verwandte Themen
Angrenzende Fragen, jeweils auf einer eigenen Seite beantwortet.
KI für Unternehmens
Welche Ansätze es gibt, KI auf eigene Unternehmensdaten zu bringen – und woran sie in der Praxis scheitern.
KI für Legacy- und Individual
Wenn das Fachwissen im Sourcecode steckt und die Dokumentation veraltet ist.
KI in bestehende Software integrieren
Was in Ihrer Systemlandschaft angepasst werden muss – und was ausdrücklich unverändert bleibt.
Conversational BI
Auswertungen im Dialog statt im Report – und was mit dem vorhandenen BI-Werkzeug passiert.
Ein Gespräch von vierzig Minuten genügt, um zu sagen, ob Ihr System dafür taugt – und wenn nicht, warum nicht.