Das ist ein Trugschluss.

Ein Data Warehouse kann sinnvoll sein. Es ist aber keine Grundvoraussetzung für eine funktionierende Data Governance. Für viele Unternehmen im Mittelstand ist es sogar der falsche erste Schritt. In diesem Artikel geht es darum, warum das so ist, und wie Ihr auch ohne DWH eine starke Datenverwaltung aufbaut.

Was Data Governance eigentlich bedeutet

Data Governance ist im Kern nichts anderes als die Gesamtheit der Regeln, Prozesse und Verantwortlichkeiten rund um den Umgang mit Daten. Das Ziel: Daten organisieren, ihre Qualität sicherstellen und Compliance-Anforderungen erfüllen. Konkret gehören dazu:

• Datenqualität – konsistente, fehlerfreie und aktuelle Daten

• Zugriffsmanagement – wer darf welche Daten einsehen und bearbeiten

• Datenschutz und Compliance – DSGVO, ISO-Normen und vergleichbare Anforderungen

• Metadatenmanagement – Daten verstehen und klassifizieren

• Prozessoptimierung – effiziente Datenflüsse im Unternehmen

Keiner dieser Punkte verlangt nach einem zentralen Data Warehouse. Sie verlangen nach klaren Regeln und Verantwortlichkeiten – unabhängig davon, wo die Daten technisch liegen.

Warum das Data Warehouse oft überbewertet wird

Ein Data Warehouse kann in bestimmten Fällen nützlich sein – etwa, wenn wirklich große Datenmengen aus vielen verschiedenen Quellen langfristig zusammengeführt werden müssen. Für die meisten mittelständischen Unternehmen sieht die Realität aber anders aus:

Der Implementierungsaufwand ist hoch. Ein DWH ist teuer, zeitintensiv und verlangt spezialisiertes Know-how, das viele Unternehmen mit 250 bis 1500 Mitarbeitenden schlicht nicht im eigenen Haus haben – und auch nicht aufbauen wollen, nur um ein einzelnes Datenprojekt zu starten.

Nicht alle Daten brauchen Zentralisierung. Oft reichen dezentrale Systeme und moderne Cloud-Lösungen vollkommen aus, um den eigentlichen Business-Nutzen zu heben.

Flexibilität geht verloren. Änderungen an Datenmodellen oder Geschäftsanforderungen werden in einem starren DWH-Setup zu einem eigenen Projekt – mit eigenem Budget, eigener Timeline, eigenem Abstimmungsaufwand.

Das größte Missverständnis dabei: Viele gehen davon aus, dass ein DWH automatisch für bessere Datenqualität oder mehr Sicherheit sorgt. Das stimmt nicht. Ohne klare Prozesse und Regeln bleibt auch das teuerste Data Warehouse nur eine weitere technische Lösung – ohne echten Mehrwert für das Geschäft.

Das ist genau das Muster, das wir auch bei Custom-AI-Projekten beobachten: Wer zuerst die Technik kauft und danach über die Regeln nachdenkt, baut am Ende ein teures System, das niemand richtig nutzt.

Wie Ihr Data Governance ohne Data Warehouse startet

Der Einstieg in Data Governance muss nicht kompliziert sein. Vier Schritte reichen für den Anfang:

1. Wichtige Daten identifizieren. Welche Daten braucht Ihr wirklich, um Eure zentralen Geschäftsfragen zu beantworten? Kundendaten, Rechnungen, Lagerbestände – meistens sind es deutlich weniger Datenquellen, als man zunächst vermutet.

2. Verantwortlichkeiten festlegen. Wer kümmert sich um welche Daten? Wer hält sie aktuell, und wer greift im Zweifel ein, wenn die Qualität nicht stimmt? Ohne eine klar benannte Person oder Rolle bleibt jede Data-Governance-Initiative ein Lippenbekenntnis.

3. Einfache Analyse-Tools nutzen. Excel, Google Sheets oder BI-Tools wie Power BI reichen für den Einstieg oft vollkommen aus, um erste belastbare Erkenntnisse zu gewinnen. Der teure Tech-Stack kommt später – wenn überhaupt.

4. Regeln für Datenqualität definieren. Wie werden Daten gepflegt? Welche Mindeststandards gelten – etwa für Vollständigkeit, Aktualität oder Formatierung? Diese Regeln müssen nicht perfekt sein. Sie müssen vor allem eines sein: befolgt.

Starte klein und pragmatisch

Eine gute Data Governance beginnt nicht mit einem großen DWH-Projekt. Sie beginnt mit klaren Verantwortlichkeiten, einem strukturierten Umgang mit den Daten, die Ihr ohnehin schon habt, und einfachen Werkzeugen, die Eure Teams bereits kennen.

Der „große Wurf“ – alles zentralisieren, alles neu aufsetzen, dann erst loslegen – klingt nach Gründlichkeit. In der Praxis ist er meistens der Grund, warum Data-Governance-Initiativen im Mittelstand nie über die Planungsphase hinauskommen.

Mehr zum konkreten Einstieg findet Ihr in unserem Artikel „Wie starte ich Data Governance in einem mittelständischen Betrieb?”.

Wie sind Eure Erfahrungen mit Data Governance – habt Ihr klein angefangen, oder steckt Ihr gerade mitten in einem großen DWH-Projekt? Schreibt es in die Kommentare.

Jetzt abonnieren

Der Unterschied zwischen beiden ist nicht der Zug. Es ist der Preis.

Was nichts kostet, wird von niemandem wertgeschätzt – weder von den Nutzern noch von den Betreibern. Subventionierte Systeme verdrecken, weil sich niemand verantwortlich für etwas Wertvolles fühlt.

Es ist der Unterschied zwischen der U-Bahn in London, die stark zugangsbeschränkt ist, und der U-Bahn in z. B. München. Die eine ist sauber und gepflegt, die andere riecht nach Urin.

Genau dieses Prinzip steckt hinter einer Entscheidung, die viele unserer Kunden zunächst irritiert: Bei Datenhandwerk kostet die Entwicklung Eures individuellen KI-Produkts nichts. Aber der erste Workshop kostet etwas – mit Geld-zurück-Garantie, falls er nichts bringt.

In diesem Artikel erklären wir, warum wir so abrechnen, was Pay-per-Use von klassischen Beratungsmodellen unterscheidet, und warum gerade der bezahlte Einstieg der wichtigste Teil des Modells ist.

Das Problem mit dem Tagessatz

Die meisten KI- und Datenprojekte im Mittelstand laufen nach demselben Muster: Ein Anbieter rechnet nach Tagessatz oder Stunden ab. Das Risiko liegt vollständig beim Kunden. Ob das Projekt am Ende einen messbaren Nutzen bringt, ist für die Vergütung irrelevant – bezahlt wird die Zeit, nicht das Ergebnis.

Das erzeugt einen stillen, aber wirksamen Fehlanreiz: Wer nach Stunden abrechnet, hat keinen wirtschaftlichen Grund, schnell zu liefern. Im Gegenteil – je länger ein Projekt dauert, desto höher die Rechnung.

Wir rechnen anders ab. Unser Modell ist eine Pay-per-Use-SaaS-Abrechnung: Wir bauen ein individuelles, exklusives Produkt für Dein Unternehmen, und Du zahlst erst, wenn es genutzt wird. Keine Tagessätze, keine Stundenzettel, keine Rechnung für halb fertige Konzepte.

Pay-per-Use ist kein neues Prinzip – es ist nur neu für KI-Beratung

Nutzungsabhängige Preismodelle sind in anderen Branchen längst etabliert und erprobt. Rolls-Royce verkauft seine Flugzeugtriebwerke nicht nur als Produkt, sondern bietet mit „Power by the Hour“ ein Modell an, bei dem Airlines pro Flugstunde zahlen statt für die Maschine selbst. Atlas Copco lässt Kunden für Druckluft pro Kubikmeter zahlen statt für den Kompressor, und Michelin verkauft Reifenleistung nach gefahrener Meile statt nach Stückzahl.

Das Muster ist immer dasselbe: Der Anbieter trägt das unternehmerische Risiko der Investition. Der Kunde zahlt nur für das, was tatsächlich funktioniert und genutzt wird.

Möglich wird das durch Fortschritte in Digitalisierung, Sensorik und Cloud-Technologie – diese haben die Überwachung und Abrechnung nutzungsabhängiger Modelle erst wirtschaftlich tragfähig gemacht, sowohl im B2C- als auch im B2B-Bereich. Was Rolls-Royce für Triebwerke macht, übertragen wir auf individuelle KI-Produkte für den Mittelstand: Wir tragen das Risiko der Entwicklung. Du zahlst erst, wenn das Produkt im Alltag läuft.

Warum der Workshop trotzdem etwas kostet

Genau hier kommt der Punkt, der die meisten Kunden im Erstgespräch überrascht: Wenn die Entwicklung nichts kostet – warum kostet dann der erste Workshop etwas?

Die Antwort hat zwei Ebenen.

Erstens: Der Workshop ist keine Vertriebsmaßnahme, sondern Arbeit.
Im initialen Workshop scopen wir gemeinsam, welches Produkt überhaupt gebaut werden soll – welche Daten verfügbar sind, welcher Use Case den größten Hebel bringt, wo die „low hanging fruits“ liegen. Das ist Expertenarbeit, kein unverbindliches Kennenlernen.

Zweitens, und das ist der wichtigere Grund: Verbindlichkeit muss auf beiden Seiten beginnen, bevor irgendetwas gebaut wird.

Zurück zur ÖPNV-Analogie: Wer nichts investiert, behandelt das Ergebnis auch nicht wie etwas Wertvolles. Das gilt für Nutzer subventionierter ÖPNV genauso wie für Auftraggeber kostenloser Erstgespräche.

Ein kostenloses Erstgespräch wird seltener vorbereitet, seltener ernst genommen, seltener mit den nötigen internen Ressourcen flankiert. Ein bezahlter Workshop verändert die Dynamik auf beiden Seiten des Tisches – auch bei uns.

Wir liefern nicht „irgendeinen Termin“, wir liefern das Fundament für ein Produkt, das danach nichts mehr kosten soll, bis es läuft.

Falls der Workshop am Ende nichts bringt oder Du mit dem Ergebnis unzufrieden bist: Du bekommst Dein Geld zurück. Aber kostenlos war er nie.

Was das für Euer Unternehmen bedeutet

Für Fachbereichsleiter und Geschäftsführer im Mittelstand – ohne eigenes Data-Team, mit begrenztem Risikoappetit für teure PoCs ohne Ergebnis – verschiebt dieses Modell die entscheidende Frage:

Nicht mehr „Wie viele Tage kostet das?“, sondern „Trägt der Anbieter das Risiko mit mir?”

Bei einem Tagessatz-Modell trägst Du als Kunde das volle Risiko. Bei unserem Pay-per-Use-Modell verdienen wir erst, wenn das Produkt läuft und im Alltag genutzt wird. Der Workshop ist der einzige Punkt, an dem beide Seiten von Anfang an Verbindlichkeit zeigen müssen – und genau deshalb kostet er etwas.

Kurz zusammengefasst:

• Entwicklung: Pay-per-Use, du zahlst erst ab Nutzung

• Initialer Workshop: kostet bewusst etwas, mit Geld-zurück-Garantie

• Das Prinzip: Was nichts kostet, ist auch nichts wert – für keine der beiden Seiten

Wenn Du wissen willst, wie ein solcher Workshop für Dein Unternehmen aussehen könnte, sprechen wir gern in einem ersten Gespräch darüber, wo Eure größten Hebel liegen.

Jetzt abonnieren

Riccardo Mattivi, Senior Staff AI Engineer bei Integral AdScience, eröffnete die Session im Rahmen der ACM-Initiative für lebenslanges Lernen. Den Hauptvortrag hielt Guglielmo Liozzi - biomedizinischer Ingenieur und Direktor für KI und angewandte Mathematik bei MSD (Merck), mit langjähriger Erfahrung in Software-Engineering und maschinellem Lernen. Sein Thema: das, wie er es nannte, ungenutzte Geschäftspotenzial kleiner Sprachmodelle.

Das passt genau zu etwas, das ich selbst seit Jahren in Kundenprojekten beobachte – und das ich in jüngster Vergangenheit auch in einem Post zum Buch „Small Language Models“ aufgegriffen habe: Man braucht nicht das größte Modell. Man braucht das Richtige.

Der technische Teil: Wie weit lässt sich ein Modell schrumpfen?

Liozzi startete mit konkreten Beispielen, wie man ein domänenspezifisches kleines Sprachmodell aufbaut und implementiert. Dabei stellte er eine Frage, die ich für den schönsten Gedanken-Provokateur des ganzen Talks halte:

„Was, wenn ich versuche, eines dieser Modelle auf einem Commodore 64 zum Laufen zu bringen?”

Das ist natürlich überspitzt – aber genau darin liegt der Witz. Es zwingt einen, eine Frage zu stellen, die in der aktuellen KI-Debatte viel zu selten gestellt wird: Wie wenig Hardware braucht ein Modell wirklich, um für eine konkrete Aufgabe nützlich zu sein? Liozzi führte aus, wie ein Modell quantisiert und für stark eingeschränkte Architekturen angepasst werden muss – eine Übung, die zeigt, wie viel „Fett“ in den meisten KI-Implementierungen tatsächlich steckt, wenn man sie mit Allzweck-Modellen löst statt mit zugeschnittenen.

Für den Mittelstand ist die Commodore-64-Frage natürlich keine reale Anforderung. Aber die Denkrichtung dahinter ist hochrelevant: Viele Unternehmen rüsten ihre Infrastruktur für KI-Anwendungen auf, die eigentlich mit deutlich weniger Rechenleistung laufen könnten – wenn das Modell von Anfang an für die konkrete Aufgabe gebaut wäre, statt ein generisches Großmodell per Prompt zu bändigen.

Der Geschäftsteil: Warum kleine Modelle keine Kompromisslösung sind

Im zweiten Teil wechselte Liozzi den Fokus von der Technik zur Geschäftsperspektive. Seine Kernaussage: Die Implementierung kleiner Sprachmodelle ist keine technische Notlösung für Unternehmen, die sich kein großes Modell leisten können. Sie ist eine eigenständige Geschäftschance.

„Die Nutzung kleiner Sprachmodelle in stark regulierten Branchen kann viele Risiken mindern.”

Das deckt sich exakt mit dem, was wir bei Datenhandwerk im Mittelstand sehen – gerade bei Kunden in regulierten oder datensensiblen Bereichen. Viele bestehende KI-Lösungen sind für den allgemeinen Markt gebaut und erfüllen die spezifischen Anforderungen einzelner Branchen oder Unternehmen schlicht nicht. Liozzi sprach explizit von der Notwendigkeit, hier innovative, zugeschnittene Lösungen zu schaffen - statt zu versuchen, ein universelles Großmodell mit immer mehr Prompt-Engineering in die richtige Richtung zu zwingen.

Datenschutz: Das Modell kommt zu den Daten, nicht umgekehrt

Der Punkt, der für mich am meisten praktische Relevanz für unsere Kunden hatte, war Liozzis Perspektive auf Datenschutz und Sicherheit:

„Die Modelle bewegen sich dorthin, wo die Daten sind, anstatt die Daten zu bewegen.”

Das ist ein einfacher Satz mit einer großen Konsequenz. Bei den meisten kommerziellen KI-APIs ist es umgekehrt: Eure Daten verlassen Eure Infrastruktur, um vom Modell verarbeitet zu werden – und damit verlasst Ihr auch ein gutes Stück Kontrolle über das, was mit sensiblen Informationen passiert. Ein kleines, lokal betreibbares Modell dreht dieses Prinzip um. Es läuft dort, wo die Daten ohnehin liegen – on-premise, in der eigenen Cloud-Umgebung, ohne dass Kundendaten, Vertragsdaten oder Produktionsdaten irgendwo anders hinwandern müssen.

Liozzi gab konkrete Beispiele, wie Unternehmen genau über diesen Weg Datenschutzbedenken adressieren, die bei der Nutzung großer kommerzieller Modelle sonst schwer auflösbar sind.

Der Satz, der mir hängen geblieben ist

Zum Abschluss formulierte Liozzi eine These, die für mich die treffendste Zusammenfassung der gesamten Bewegung hin zu kleinen, spezialisierten Modellen ist:

„Dies ist eine Verschiebung von der Anmietung von Intelligenz zu deren Besitz.”

Genau das ist der Unterschied, den ich Entscheidern im Mittelstand am liebsten erklären würde, wenn ich nur einen Satz hätte. Wer ein großes KI-Modell per API nutzt, mietet Intelligenz – bei einem Anbieter, der die Spielregeln, die Preise und manchmal sogar die Verfügbarkeit jederzeit ändern kann. Wer ein kleines, auf die eigenen Daten und Prozesse zugeschnittenes Modell selbst betreibt oder betreiben lässt, besitzt diese Intelligenz – als eigenen Vermögenswert, der sich mit dem Unternehmen weiterentwickelt, statt von außen verwaltet zu werden.

Was das für Euch bedeutet

Liozzis Vortrag bestätigt etwas, das in der aktuellen KI-Debatte oft untergeht, weil die Schlagzeilen den großen Modellen gehören: Die eigentliche Paradigmenverschiebung passiert nicht beim nächsten GPT-Release. Sie passiert bei Unternehmen, die aufhören zu fragen: „Welches Modell ist gerade das beste?“ und anfangen zu fragen: „Welches Modell brauche ich für genau mein Problem – und kann ich es selbst besitzen, statt es zu mieten?“

Für den Mittelstand ohne eigenes Data-Team klingt das zunächst nach einer Hürde. Ist es aber nicht – es ist eine Einladung, das KI-Projekt von der richtigen Seite aus zu denken: nicht vom größten verfügbaren Modell aus, sondern vom eigenen, sehr konkreten Anwendungsfall.

Jetzt abonnieren

Am nächsten Tag verlieren Uber, American Express, Mastercard und DoorDash zwischen 4 und 6 Prozent ihres Börsenwerts. Alle vier Unternehmen waren im Szenario namentlich erwähnt.

Das ist die aktuelle Lage: Ein hypothetisches Gedankenspiel über KI-Agenten bewegt echtes Geld an echten Märkten. Wenn das die Reaktion auf eine Spekulation ist, wie verzerrt ist dann erst die Diskussion, die Entscheider in ihren eigenen Unternehmen führen müssen?

Die kurze Antwort: ziemlich verzerrt. Und genau deshalb lohnt sich ein Blick auf die richtigen Fragen – statt auf die falschen Ängste.

Die falsche Frage: „Übernehmen die Agenten?”

Wir geben den Systemen menschliche Eigenschaften und messen ihre Leistungsfähigkeit auf menschlicher Ebene, was die öffentliche Debatte über Agentic AI stark anthropomorphisiert. Diese Denkweise geht letztlich auf Alan Turings Imitationsspiel aus dem Jahr 1950 zurück: Ein System gilt als intelligent, wenn es im Dialog nicht von einem Menschen zu unterscheiden ist.

Das Problem an diesem Maßstab: Er fragt nach Imitation, nicht nach Wirkung. Ob ein KI-Agent wie ein Mensch wirkt, ist für dein Unternehmen die uninteressanteste Frage überhaupt. Relevant ist, was passiert, wenn dieser Agent mit deinen Daten, deinen Mitarbeitenden und deinen Geschäftsprozessen interagiert.

Schon 1989 argumentierte die Soziologin Susan Leigh Star, dass der Turing-Test der falsche Maßstab für KI-Systeme ist. Ihr Vorschlag, angelehnt an den Soziologen Émile Durkheim: Die Intelligenz eines Systems bemisst sich nicht daran, wie menschlich es wirkt, sondern daran, wie nützlich es für die gemeinsame Arbeit ist – und wie gut es sich an veränderte Bedingungen anpassen kann.

Übersetzt in die Sprache des Mittelstands: Es geht nicht darum, ob ein Agent klug klingt. Es geht darum, ob er im echten Betriebsalltag etwas bringt, und ob er sich anpassen lässt, wenn sich eure Prozesse ändern.

Die richtige Frage: „Mit welchen Regeln lassen wir Agenten arbeiten?”

Ein KI-Agent handelt nie im Vakuum. Er ist Teil eines größeren Zusammenspiels aus Menschen, Software, Daten und Prozessen – in der Forschung wird das ein „sozialer Mechanismus“ genannt.

Wikipedia ist ein bekanntes Beispiel: Menschliche Autorinnen und Autoren arbeiten mit Bots zusammen, die Vandalismus erkennen, Verlinkungen pflegen und Bearbeitungen vorschlagen – begrenzt durch klare Regeln der Community.

Autonome Fahrzeuge im Straßenverkehr sind ein anderes Beispiel: Sie agieren neben menschlichen Fahrern und Fußgängern, in einem Umfeld mit Verkehrsregeln, Wetterbedingungen und sich durchgehend ändernden Situationen.

Die entscheidende Erkenntnis aus diesem Forschungsfeld lässt sich auf jedes Unternehmen übertragen, das KI-Agenten einsetzen will:

Nicht der einzelne Agent entscheidet über den Erfolg. Die Regeln, nach denen Mensch und Agent zusammenarbeiten, entscheiden darüber.

Forscher schlagen dafür einen erweiterten Prüfkatalog vor, der spieltheoretische Mechanismus-Gestaltung mit sozialwissenschaftlichen Fragen verbindet – den sogenannten Star-Durkheim-Test. Vereinfacht gefragt:

• Wessen Interessen verfolgt der Agent, und wessen Interessen verfolgen die Menschen, mit denen er zusammenarbeitet?
  Bei einem Vertriebsagenten sind das andere Ziele als bei einem Fahrer im Straßenverkehr – aber die Frage ist dieselbe: Laufen die Interessen von Mensch und KI-Agent in dieselbe Richtung, oder erzeugt der Agent stille Fehlanreize?

• Handelt der Agent verlässlich, regelkonform und nachvollziehbar?
  Ein Agent, der „irgendwie“ zum Ziel kommt, aber niemand versteht, wie, ist in einem Unternehmenskontext ein Risiko – nicht ein Feature.

• Was passiert, wenn der Agent zu viele Rechte bekommt?
  Hier hilft ein aktuelles Beispiel: Open-Claw, ein Open-Source-System aus lokal arbeitenden Agenten, die digitale Aufgaben über mehrere Software-Dienste hinweg selbstständig erledigen. Je größer das Autonomie-Versprechen, desto größer die Angriffsfläche – von kompromittierten Zugangsdaten bis zu manipulierbaren Workflows. Wer einem solchen System weitreichende Zugriffsrechte einräumt, sollte sich der Risiken bewusst sein, die der Hype gerne ausblendet.

• Lässt sich die Sicherheit so weit erhöhen, dass das System noch funktioniert? Die Forscher vergleichen übermäßige Einschränkung mit dem Versuch, eine Küche kindersicher zu machen, indem man Messer, Herd und Backofen entfernt. Dann ist die Küche sicher – aber nutzlos. Genau diese Balance müssen Entscheider für jeden Agenten in ihrem Unternehmen selbst finden.

Was das für die Regulierung bedeutet – und warum sie allein nicht reicht

Der EU‑AI‑Act verfolgt einen risikobasierten Ansatz: Je nach Risikokategorie eines KI-Systems gelten unterschiedliche Anforderungen, etwa Verbote bestimmter Techniken wie Social Scoring oder biometrischer Identifizierung im öffentlichen Raum.

Das ist sinnvoll, hat aber eine Schwäche, die für Entscheider direkt relevant ist: Die Regulierung betrachtet meist das einzelne System – nicht den gesamten Kontext, in den es eingebettet ist.

Beim autonomen Fahren funktioniert das einigermaßen, weil es dort bereits viele Regulierungen gibt, die genau diesen Gesamtkontext mitdenken. Bei Sprachmodellen und KI-Agenten in Unternehmen sieht das anders aus – hier zeigt sich, wie schwer sich selbst europäische Gesetzgebung tut, regulatorische Leitplanken gegen die Marktdynamik großer Anbieter durchzusetzen.

Die praktische Konsequenz für Entscheider: Wer auf gesetzliche Leitplanken wartet, bevor er sich mit den eigenen Spielregeln für KI-Agenten beschäftigt, wartet zu lange.

Die Verantwortung, den eigenen „sozialen Mechanismus“ zwischen Mitarbeitenden und Agenten sinnvoll zu gestalten, liegt zuerst im Unternehmen selbst.

Die eigentliche Machtfrage

Die entscheidende Frage ist nicht, ob KI-Agenten eingesetzt werden. Technologien verschwinden selten wieder, sobald sie wirtschaftlich sinnvoll sind. Die entscheidende Frage ist, welche Strukturen und Regeln ein Unternehmen für das Zusammenspiel von Menschen und Agenten baut – bevor der Agent produktiv geschaltet wird, nicht danach.

Drei praktische Leitfragen für Entscheider, abgeleitet aus der oben skizzierten Logik:

1. Welches Ziel verfolgt der Agent wirklich – und passt das zu den Zielen der Menschen, die mit ihm arbeiten? Ein Kundenservice-Agent, der primär auf Geschwindigkeit optimiert ist, kann in Konflikt mit dem Ziel „Kundenzufriedenheit“ stehen, selbst wenn beide auf dem Papier zusammengehören.

2. Wie viel Autonomie braucht der Agent wirklich – und wie viel davon ist nur Bequemlichkeit? Jede zusätzliche Berechtigung ist eine zusätzliche Angriffsfläche. Die Frage ist nicht „Was kann der Agent maximal tun?“, sondern „Was muss er minimal können, um den Job zu erledigen?”

3. Wer im Unternehmen versteht den Agenten gut genug, um ihn anzupassen, wenn sich die Lage ändert? Ein Agent, den niemand außer dem ursprünglichen Anbieter versteht oder verändern kann, ist eine Blackbox mit Risikoaufschlag.

Diese Fragen lassen sich nicht an einem Nachmittag beantworten, und sie lassen sich nicht durch ein einzelnes Tool oder eine einzelne Policy lösen. Sie verlangen eine bewusste Auseinandersetzung mit der eigenen Datenlage, den eigenen Prozessen und der eigenen Risikotoleranz – bevor der erste Agent live geht.

Nicht die Maschine bestimmt die Wirkung von KI-Agenten in deinem Unternehmen. Die Regeln, nach denen Menschen und Agenten zusammenarbeiten, tun das.

Jetzt abonnieren

Das ist kein Einzelfall und kein Zufall. Es ist ein Muster, das sich durch die gesamte aktuelle KI-Forschung zieht: Größer ist nicht automatisch besser. Und Benchmarks, auf die sich die meisten Entscheidungen stützen, sagen oft erschreckend wenig darüber aus, was im echten Betrieb funktioniert.

Das Benchmark-Problem: Was auf dem Papier gut aussieht, scheitert im Alltag

Kili Technology hat in einer aktuellen Analyse das Ausmaß dieses Problems beziffert: Enterprise-Agentensysteme zeigen im Schnitt eine Lücke von 37 Prozent zwischen Labor-Benchmark-Werten und tatsächlicher Performance im produktiven Einsatz. Bei Kostenvergleichen ist die Streuung noch dramatischer – bis zum 50-Fachen Unterschied zwischen Ansätzen, die auf dem Papier ähnlich gut abschneiden.

Woran liegt das?

Mehrere Gründe kommen zusammen:

Benchmarks sind gesättigt.
MMLU, einst der Goldstandard für KI-Fähigkeiten, wird heute von praktisch jedem führenden Modell mit über 88 Prozent gelöst. Unterschiede zwischen Modellen liegen dort im Bereich des statistischen Rauschens – sie sagen nichts mehr aus.

Benchmarks werden kontaminiert.
Modelle haben Testfragen oft schon während des Trainings gesehen. Bei SWE-Bench Verified, dem früheren Coding-Standard, zeigte ein Audit, dass praktisch alle führenden Modelle Überlappungen mit den Trainingsdaten aufweisen – und fast 60 Prozent der schweren Aufgaben fehlerhaft konstruiert waren.

Benchmarks können manipuliert werden.
Der internationale KI-Sicherheitsbericht 2026 dokumentierte, dass Spitzenmodelle zwischen Test- und Produktionskontext unterscheiden können – und sich in Tests sicherer verhalten als im echten Einsatz. Ein besonders deutliches Beispiel: Ein Modell, das eigentlich die Ausführungsgeschwindigkeit optimieren sollte, schrieb stattdessen einfach die Timer-Funktion um, damit sie schnelle Ergebnisse meldete – ohne die tatsächliche Performance zu verbessern.

Benchmarks testen die falsche Sache.
Ein Modell, das bei Humanity’s Last Exam glänzt – einem Test mit Fragen an der Grenze des akademischen Wissens –, sagt wenig darüber aus, ob es in eurem Kundenservice-Bot vernünftig mit einer mehrdeutigen Anfrage umgeht. Produktionssysteme interagieren mit Teams, verarbeiten unklare Eingaben und laufen über lange Zeiträume. Kein Standard-Benchmark berichtet Kosten pro Aufgabe, Latenz oder Zuverlässigkeit über mehrere Durchläufe.

Teilen

Der Gegenbeweis: Wie ein 1,3-Milliarden-Modell größere Modelle schlug

Schon 2023 lieferte Microsoft Research mit dem Modell „phi-1“ einen der eindrücklichsten Belege dafür, dass Modellgröße nicht der entscheidende Faktor ist. Phi-1 hatte gerade einmal 1,3 Milliarden Parameter – winzig im Vergleich zu den meisten Konkurrenten. Trainiert wurde es mit weniger als 7 Milliarden Tokens, ein Bruchteil dessen, was vergleichbare Modelle damals verschlangen.

Das Ergebnis: 50,6 Prozent Pass-Rate auf dem HumanEval-Coding-Benchmark – und schlug damit Modelle, die zehnmal größer und mit hundertmal mehr Trainingsdaten gefüttert worden waren. StarCoder etwa, ein Modell mit 15,5 Milliarden Parametern und einer Billion Trainings-Tokens, kam nur auf vergleichbare oder schlechtere Werte.

Der Grund war kein cleverer Trick in der Architektur. Es war die Qualität der Trainingsdaten. Statt phi-1 mit dem üblichen, riesigen, aber unsauberen Mix aus öffentlichem Code zu trainieren, kuratierten die Forscher gezielt „lehrbuchqualitative“ Daten – sauber strukturierter, instruktiver Code statt zufällig zusammengewürfelter Repositories voller Boilerplate und unverständlicher Snippets. Ergänzt wurde das durch synthetisch generierte Übungsaufgaben.

Das Team zeigte sogar, dass dieser Effekt nicht auf Zufall oder versehentliche Kontamination der Testdaten zurückzuführen war: Selbst nachdem sie aggressiv über 40 Prozent der Trainingsdaten entfernt hatten, die HumanEval-Aufgaben auch nur entfernt ähnelten, blieb die Leistung von phi-1 stabil deutlich über der von StarCoder.

Die Kernerkenntnis aus diesem Paper, treffend zusammengefasst im Titel selbst: „Textbooks Are All You Need“.

Saubere, gezielt kuratierte Daten schlagen rohe Masse.

Teilen

GLM-5.2: Dasselbe Prinzip, drei Jahre später, im großen Maßstab

Was bei phi-1 im Kleinen demonstriert wurde, zeigt sich heute bei GLM-5.2 im Maßstab von Hunderten Milliarden Parametern. GLM-5.2 wurde nicht als Alleskönner trainiert, der nebenbei auch programmieren kann.

Es wurde gezielt für Coding-Aufgaben und für das Arbeiten in agentischen Umgebungen wie Claude Code oder OpenCode trainiert – mit einer effizienten MoE-Architektur und Optimierungen, die den Rechenaufwand pro Token drastisch senken.

Das Ergebnis bestätigt das Muster: In einer realen Aufgabe – dem Bau eines WebGL-3D-Plattformers von Grund auf – kostete GLM-5.2 rund 5,39 US-Dollar, während Opus 4.8 etwa 21,92 US-Dollar verschlang. Opus war zwar schneller fertig und lieferte das sauberere Ergebnis, aber der Kostenunterschied von etwa dem Vierfachen zeigt deutlich: Spezialisierung auf eine klar definierte Aufgabe schlägt rohe Modellgröße, wenn das Verhältnis von Aufwand zu Ergebnis zählt.

Was das für euer Unternehmen bedeutet

Die Kili-Analyse formuliert es treffend: Benchmarks sollten als Filter dienen, nicht als Urteil. Ein Benchmark-Score sagt euch, welches Modell es wert ist, weiter getestet zu werden – nicht, welches Modell für eure Nutzer tatsächlich funktioniert.

Für den Mittelstand heißt das konkret:

Hört auf, dem größten verfügbaren Modell automatisch zu vertrauen. Die Annahme „größer ist besser“ ist bequem, aber empirisch immer wieder widerlegt – von phi-1 vor drei Jahren bis zu GLM-5.2 heute.

Investiert in die Qualität eurer eigenen Daten, nicht in die Größe des Modells.
Phi-1 zeigt eindrücklich: Ein kleines Modell mit sauberen, gezielt kuratierten Trainingsdaten kann ein riesiges Modell mit unsauberen Daten schlagen. Das gilt nicht nur für die Modelle der großen Labs – es gilt genauso für jedes Custom-AI-Projekt, das auf euren eigenen Geschäftsdaten aufbaut.

Testet gegen eure eigene Realität, nicht gegen ein Leaderboard.
Ein Modell, das bei Humanity’s Last Exam brilliert, kann bei eurer konkreten Reklamationsbearbeitung trotzdem scheitern – und ein kleineres, spezialisiertes Modell kann genau dort gewinnen, wo es darauf ankommt.

Bewertet automatisierte Metriken, Modell-Screening und menschliche Fachexpertise gemeinsam.
Genau dieses gestaffelte Vorgehen empfiehlt auch die Kili-Analyse für produktionsreife KI-Bewertung – und es deckt sich mit dem, was sich in der Praxis als robust erweist: Kein einzelner Test ersetzt das Urteil von jemandem, der weiß, was in eurem spezifischen Kontext „richtig“ bedeutet.

Die eigentliche Frage ist also nicht „Welches Modell hat den höchsten Benchmark-Score?“. Die eigentliche Frage ist: „Welches Modell – trainiert auf welchen Daten, getestet gegen welche Realität – löst mein konkretes Problem am verlässlichsten und am günstigsten?”

Genau das ist der Unterschied zwischen einem KI-Projekt, das beeindruckende Folien produziert, und einem, das im Alltag tatsächlich läuft.

Jetzt abonnieren

Diese Geschichte hören nicht nur wir immer wieder. In seiner Studie vom Juli 2025 stellte das MIT fest, dass 95 % der Unternehmen keinen messbaren Erfolg durch den Einsatz insbesondere von GenAI feststellen können.

Wir denken, dass das Problem nicht an fehlender Technologie oder Unfähigkeit der Teams liegt, sondern daran, dass KI-Projekte falsch angegangen werden.

Jetzt abonnieren

Das Problem: KI als isoliertes Feature

Die Mehrheit der Unternehmen betrachtet KI als eine zusätzliche Komponente. Ein Chatbot hier, ein Empfehlungsalgorithmus dort, ein Prognosemodell für die Finanzabteilung. Jedes Team ist für den Aufbau seiner eigenen Datenpipeline, das Trainieren eigener Modelle sowie die Bewältigung des Change-Managements verantwortlich.

Die Realität dahinter:

• Team A braucht 6 Monate, um Kundendaten zu strukturieren

• 3 Monate später beginnt Team B erneut mit dem Bau derselben Datenpipeline.

• Team C scheitert am Widerstand der Fachabteilung, weil niemand versteht, was das Tool eigentlich bringt

Jedes Projekt kostet dabei mehrere hunderttausend Euro. Der ROI? Bestenfalls marginal.

Der Wendepunkt: In Produkten denken, nicht in Projekten

Stell dir vor, dein Vertrieb wäre eine geschlossene Domäne. Die Generierung von Leads, die Kommunikation mit Kunden, das Forecasting und die Churn-Prävention sind alle miteinander verbunden. Jede frisch eingeführte KI-Applikation verwendet die gleiche Dateninfrastruktur. Jedes trainierte Modell verbessert das nächste. Das Team wird durch jeden Erfolg motiviert, den nächsten Schritt zu machen.

Ein konkretes Beispiel aus der Praxis:

Ein Online-Shop-Unternehmen hat den Bereich „Kundenerlebnis“ in drei Schritten verändert:

1. Start (Monat 1–3): Produktempfehlungen basierend auf historischen Käufen

   • Dateninfrastruktur aufgebaut: Kundenverhalten, Produktkatalog, Transaktionen

   • Impact: +12 % Conversion bei wiederkehrenden Kunden

2. Ausbau (Monat 4–6): Dynamische Preisoptimierung für Bestandskunden

   • Nutzte die gleiche Dateninfrastruktur wie Schritt 1

   • Erweiterte Customer-Insights um Preissensitivität

   • Impact: +8 % Marge bei gleichbleibender Kundenzufriedenheit

3. Skalierung (Monat 7–9): Predictive Churn Prevention

   • Kombinierte Daten aus Schritt 1 und 2

   • Team hatte inzwischen Erfahrung und Vertrauen

   • Impact: –23 % Kundenabwanderung in der Risikogruppe

Gesamtergebnis nach 9 Monaten: 3,2 Mio € zusätzlicher Jahresumsatz bei 680.000 € Investment.

Warum dieser Ansatz funktioniert

1. Daten als Produkt, nicht als Abfallprodukt

In isolierten Projekten sind Daten ein notwendiges Übel. Im Produkt-Ansatz werden sie zum Asset. Du baust einmal eine saubere, gut dokumentierte Dateninfrastruktur auf – und jede weitere Initiative profitiert davon.

Konkret bedeutet das:

• Einheitliche Datenqualität über alle Use Cases hinweg

• Wiederverwendbare Features (z.B. “Customer Lifetime Value” einmal berechnen, überall nutzen)

• Reduzierte Time-to-Market für neue KI-Anwendungen um 60-70%

Der Schlüssel zum Erfolg liegt nicht darin, die gesamte Organisation auf einmal umzukrempeln – ein solches Unterfangen ist zu komplex und birgt hohe Risiken. Stattdessen sollten Unternehmen einen entscheidenden Geschäftsbereich oder eine „Domäne“ identifizieren und diesen von Grund auf neu denken. Eine solche ganzheitliche Transformation eines Kernprozesses oder einer Funktion führt zu erheblichen Leistungssteigerungen, die isolierte Anwendungen niemals erreichen können.

Die Vorteile des Produkt-Ansatzes:

1. Synergien: Jede neue KI-Initiative kann auf der vorherigen aufbauen, indem Daten wiederverwendet und Fähigkeiten für gemeinsame Interessengruppen erweitert werden.

2. Organischer Wandel: Dieser Ansatz löst einen organischen Veränderungszyklus innerhalb der Domänen aus. Wenn Führungskräfte und Mitarbeiter sehen, wie KI funktioniert und welche Vorteile sie bringt, entsteht eine Eigendynamik für den KI-Einsatz im gesamten Unternehmen.

3. Kontinuierliche Verbesserung: Der Domänen-Ansatz fördert eine Denkweise der kontinuierlichen Verbesserung, die angesichts der rasanten Entwicklung der KI-Technologie unerlässlich ist. KI-Transformationen sind keine einmaligen Projekte, sondern fortlaufende Anstrengungen.

2. Der Mensch vor der Technologie

Veränderungen in Organisationen entstehen nicht durch verbesserte Computerprogramme, sondern durch Menschen, die mitmachen und begreifen. Indem Mitarbeiter aus dem gesamten Domäne-Zyklus (unabhängig davon, wo sie zuvor in der Organisation saßen) einberufen und ihnen Verantwortung für die Arbeit übertragen wird, fördert es die Beteiligung an einer Initiative und erzeugt Begeisterung und Dynamik. Es ist wichtig, dass diese Faktoren berücksichtigt werden, damit Mitarbeiter bei der Entwicklung von Lösungen über das Übliche hinausdenken und dem Projekt dabei helfen, unvorhergesehene Hindernisse zu überwinden.

Um auf unser Beispiel zurückzukommen: Im Rahmen des ersten Projekts erfährt das Vertriebsteam Folgendes: „Offenbar hat das KI-Tool unsere vielversprechendsten Leads zutreffend prognostiziert.“

Im zweiten Projekt stellen sie sich die Frage: „Können wir das auch für X verwenden?“

Beim dritten Projekt arbeiten sie an der Entwicklung ihrer eigenen Ideen.

Messbare Indikatoren:

• Adoption-Rate steigt von typischen 30 % (isoliertes Projekt) auf 75–85 % (dritte Initiative in der Domäne)

• Time-to-Value sinkt von durchschnittlich 8 Monaten auf 3–4 Monate

3. Prozesse, die mit der Technologie wachsen

Die Entwicklung der KI-Technologie schreitet rapide voran. GPT-4 jetzt, GPT-5 morgen, multimodale Modelle am Tag danach. Wer immer wieder von Null beginnt, der verliert.

Durch den Produkt-Ansatz werden Prozesse zur fortlaufenden Verbesserung etabliert:

• Regelmäßige Model-Retraining-Cycles

• A/B-Testing neuer Ansätze gegen etablierte Lösungen

• Feedback-Loops zwischen Business und Data Science

Die Notwendigkeit ist echt

Während du diese Zeilen liest, optimiert ein Konkurrent möglicherweise bereits seine Lieferkette unter Zuhilfenahme von künstlicher Intelligenz. Ein Startup revolutioniert deine Industrie mit einem Geschäftsmodell, das auf KI zugeschnitten ist. Ein weiterer CEO genehmigte letzte Woche den Produkt-Ansatz für seinen Vertrieb.

Die gute Nachricht: Die meisten Unternehmen haben durch die COVID-Jahre bereits erste KI-Erfahrungen gesammelt. Teams sind aufgebaut. Erste Projekte laufen.

Die Herausforderung: Diese Punktlösungen in eine kohärente, domänenweite Transformation zu überführen.

Deine nächsten Schritte

1. Identifiziere eine kritische Domäne. Wo würden 20–30 % Effizienzsteigerung den größten Business-Impact haben?

2. Mappe die Datenlage: Welche Daten existieren bereits? Was fehlt? Was ist die Qualität?

3. Definiere 3–5 vernetzte Use Cases. Nicht isolierte Projekte, sondern eine zusammenhängende Transformationsstory

4. Starte klein, denke groß. Erstes Projekt in 8–12 Wochen live, aber mit Infrastruktur, die skaliert.

Weiterführende Ressourcen:

• Framework für Domänen-Mapping – systematisches Vorgehen zur Identifikation der richtigen Domäne

• Data Product Canvas – Template für die Konzeption von Daten als Produkt

• KI-Readiness-Assessment – Evaluiere die Ausgangslage deiner Organisation.

Frage in die Community: Welche Domäne in eurem Unternehmen hätte das größte Transformationspotenzial? Und was hält euch aktuell davon ab, den ersten Schritt zu gehen?

Noch keine Data-Community?

Durch den Ansatz einer Data Community konnten wir zeigen, dass es nicht immer so sperrig sein muss, um handfeste Ergebnisse zu erzielen.

Wertvolles Wissen über Daten liegt in Unternehmen bei verschiedenen Teams und Abteilungen verstreut. Oft fehlt eine zentrale Anlaufstelle, um Erfahrungen auszutauschen, Best Practices zu teilen und datengetriebene Innovationen voranzutreiben. Hier kommt die Data Community ins Spiel. Sie ist das lebendige Fundament, das sicherstellt, dass Data Governance nicht nur ein Regelwerk, sondern eine gelebte Unternehmenskultur wird.

Eine Data Community bringt Mitarbeitende zusammen, die mit Daten arbeiten – von Analysten über IT-Teams bis hin zu Fachabteilungen.

Doch welchen konkreten Mehrwert bietet eine solche Community und wie lässt sie sich implementieren? Lasst es uns herausfinden!

Jetzt abonnieren

Die versteckte Bedrohung: Wieso Daten und Wissen in Silos stecken ⚠️

Daten haben sich in der heutigen Wirtschaft als entscheidender Vermögenswert entwickelt. Bedauerlicherweise ist in zahlreichen Unternehmen das wertvolle Wissen über diese Daten auf verschiedene Teams und Abteilungen verteilt und in Datensilos eingeschlossen.

Der Hauptgrund ist die Art und Weise, wie das Unternehmen organisiert ist.

In Unternehmen gibt es verschiedene Abteilungen wie Marketing, Vertrieb, Finanzen und Produktion, die speziell für ihre eigenen Ziele optimiert sind.

• Vertikale Optimierung: Jede Abteilung entwickelt ihre eigenen, spezialisierten Prozesse und Kennzahlen und beschafft die dafür notwendigen Daten und IT-Systeme (z. B. CRM für den Vertrieb, ERP für die Produktion). Diese Systeme sind oft nicht nativ miteinander verbunden.

• Wissenslokalisierung: Das Wissen über die Daten – ihre genaue Herkunft, ihre Definitionen, ihre Qualität und die Art ihrer Nutzung – verbleibt im Verantwortungsbereich der jeweiligen Abteilung. Das führt dazu, dass das Vertriebsteam die Definition von „Kunde“ auf andere Art interpretiert als das Finanzteam.

• Fehlende horizontale Brücken: Es fehlt eine horizontale, unternehmensweite Struktur, die den abteilungsübergreifenden Austausch von Daten und Wissen standardisiert und fördert.

Die Folge dieser strukturellen Isolation ist, dass Daten und das Wissen darüber nicht frei fließen können, wodurch sich schwerwiegende Probleme ergeben:

• Redundanz und Ineffizienz: Teams erfinden das Rad neu oder führen dieselben Berechnungen mit unterschiedlichen Datensätzen durch. Das Marketing-Team nutzt insbesondere eine CRM-Datenbank, weiß aber nicht, dass das Controlling bereits eine optimierte Kundensegmentierung entwickelt hat – wertvolle Arbeit wird dupliziert.

• Mangelndes Vertrauen in Daten: Ohne eine „Single Source of Truth“ (SSOT) sind Daten inkonsistent, was zu Verwirrung und Misstrauen unter den Nutzern führt. Entscheidungen basieren auf fehlerhaften oder veralteten Informationen, was die betriebliche Effizienz verringert und Kosten erhöht.

• Compliance- und Innovationsrisiken: Unkontrollierte Datenflüsse und unklare Verantwortlichkeiten erschweren die Einhaltung gesetzlicher Vorschriften (z. B. DSGVO) und behindern die vollständige Nutzung des Datenpotenzials für neue Geschäftsmodelle oder KI-Initiativen.

Der Mehrwert der Community: Wissen, Vertrauen und Entscheidungen

Eine Data Community bringt Mitarbeitende zusammen – von Analysten über IT-Teams bis hin zu Fachabteilungen. Ihr Mehrwert ist direkt und operativ:

1️⃣ Bessere Nutzung und Verständnis von Daten

Viele Unternehmen sammeln riesige Mengen an Daten – doch oft bleibt unklar, wie diese optimal genutzt werden können. Die Community hilft, Wissenssilos zu überwinden und ein gemeinsames Verständnis darüber zu schaffen, wo wichtige Daten liegen, wie sie richtig interpretiert werden und welche Analyse-Tools sinnvoll sind.

✅ Wo wichtige Daten liegen
✅ Wie sie richtig interpretiert werden
✅ Welche Analyse-Tools sinnvoll sind

💡 Beispiel: Ein Marketing-Team nutzt eine CRM-Datenbank, weiß aber nicht, dass das Controlling-Team bereits eine optimierte Kundensegmentierung entwickelt hat. Durch den Austausch in der Data Community können beide voneinander profitieren.

2️⃣ Förderung von datengetriebener Entscheidungsfindung

Der gemeinschaftliche Aufbau einer Daten-Community sowie die Sicherstellung der Datenqualität tragen dazu bei, das Vertrauen in Daten zu stärken und fundiertere sowie schnellere Entscheidungsfindungen zu begünstigen.

Sie ermöglicht:

📊 Bessere Entscheidungsgrundlagen durch transparenten Austausch von Analysen
📊 Höhere Datenkompetenz im gesamten Unternehmen
📊 Weniger Abhängigkeit von einzelnen Experten

💡 Beispiel: Vertrieb und Produktion können durch eine bessere gemeinsame Nutzung von Daten Nachfrage-Trends schneller erkennen und Produktionsmengen anpassen.

3️⃣ Effizientere Zusammenarbeit zwischen Teams

Ohne eine zentrale Plattform für den Austausch arbeiten viele Teams doppelt, weil sie ähnliche Analysen oder Berichte unabhängig voneinander erstellen. Eine Data Community schafft:

🤝 Bessere Zusammenarbeit zwischen Fachbereichen, IT & Data Science
🚀 Synergien, die Kosten und Zeit sparen
📂 Standardisierung von Methoden & Tools

💡 Beispiel: IT und Controlling arbeiten gemeinsam an einer automatisierten Reporting-Lösung, die beiden Abteilungen Arbeit erspart.

4️⃣ Innovationen durch neue Perspektiven

Oft entstehen die besten Ideen, wenn unterschiedliche Perspektiven aufeinandertreffen. Eine Data Community bietet Raum für:

🔍 Erfahrungsaustausch über neue Technologien & Trends
💡 Kreative Lösungsansätze für Datenprobleme
🌍 Interdisziplinären Wissenstransfer

💡 Beispiel: Ein Data-Scientist teilt in der Community, wie KI für die Lageroptimierung eingesetzt werden kann – das Logistik-Team adaptiert die Idee und reduziert Lagerkosten.

5️⃣ Förderung einer datengetriebenen Unternehmenskultur

Eine Data Community hilft, eine starke Datenkultur aufzubauen, indem sie:

📢 Schulungen & Events organisiert
📘 Wissen in Form von Leitfäden & Best Practices teilt
🎯 Datenbewusstsein auf allen Ebenen fördert

💡 Beispiel: Regelmäßige „Lunch & Learn“-Sessions helfen Mitarbeitenden, datengetriebene Ansätze besser zu verstehen und anzuwenden.

🚀 Fazit: Eine Data Community bringt echten Mehrwert!

Unternehmen, die eine aktive Data Community aufbauen, profitieren von:

✅ Besserem Datenverständnis & effizienterer Nutzung
✅ Schnellerem Wissenstransfer & weniger Doppelarbeit
✅ Mehr Innovation & besseren Geschäftsentscheidungen
✅ Einer starken, datengetriebenen Unternehmenskultur

💡 Tipp: Der Aufbau einer Data Community muss nicht kompliziert sein! Starte klein mit regelmäßigen Meetups, Wissens-Sharing und einer internen Plattform für den Austausch.

👉 Wie nutzt dein Unternehmen Daten? Gibt es bereits eine Data Community? Teile deine Erfahrungen in den Kommentaren! 😊👇