Datenstrategie für Unternehmen: von Geschäftszielen zu umsetzbaren Vorhaben
Eine Datenstrategie legt fest, wofür Ihr Unternehmen Daten einsetzen will, welche Voraussetzungen dafür fehlen und wer die Umsetzung verantwortet. Ihr Ergebnis sind begründete Prioritäten: Welche Entscheidung soll besser werden? Welche Daten werden dafür benötigt? Welches Vorhaben beginnt zuerst?
In diesem Artikel
Das unterscheidet sie von einer Werkzeugliste. Ein neues Warehouse, ein Dashboard oder eine KI-Anwendung kann Teil der Umsetzung sein. Ob diese Investition sinnvoll ist, lässt sich erst beurteilen, wenn Nutzen, Datenbedarf und Verantwortung zusammenpassen. Die AWS-Erläuterung zur Datenstrategie verbindet deshalb Geschäftszweck, Menschen, Prozesse, Technik und Regeln in einem langfristigen Plan.
Dieser Leitfaden behandelt die Datenstrategie eines Unternehmens. Sie erhalten einen Weg vom Geschäftsziel zu einem ersten überprüfbaren Datenauftrag, einschließlich einer ausgefüllten und einer wiederverwendbaren Arbeitshilfe.
Mit einer Entscheidung beginnen
„Wir wollen datengetriebener werden“ lässt offen, was sich im Arbeitsalltag verändern soll. Beginnen Sie mit einer Entscheidung, die heute zu spät, mit widersprüchlichen Informationen oder nur durch aufwendige Rückfragen getroffen wird. Benennen Sie die Person, die diese Entscheidung trifft, und die Handlung, die daraus folgen soll.
Ein fiktiver Servicebereich dient im Folgenden als Arbeitsmodell. Seine Einsatzplanung möchte gefährdete Liefertermine früher erkennen und rechtzeitig zwischen Umbuchung, Eskalation und Kundeninformation entscheiden. Das ist zunächst ein fachlicher Auftrag. Die Frage nach einem Prognosemodell oder einer neuen Plattform kommt später.
Die Nutzenhypothese könnte lauten: Wenn die Einsatzplanung verbindliche Termin- und Statusinformationen gemeinsam sieht, kann sie kritische Aufträge gezielter bearbeiten. Ob das funktioniert, muss der erste Versuch zeigen. Es handelt sich weder um einen erreichten Kundenerfolg noch um eine zugesagte Einsparung.
Andere Ausgangspunkte sind ebenfalls möglich: einen Kundenbedarf früher erkennen, einen manuellen Prozess verkürzen, Leistungen zuverlässiger bereitstellen oder ein neues Angebot prüfen. Daten zu verkaufen ist dabei eine mögliche Option, kein notwendiges Ziel einer Datenstrategie. Für viele Unternehmen liegt der Nutzen zunächst in einer besseren eigenen Entscheidung.
Halten Sie pro Vorhaben drei Dinge auseinander: das Geschäftsziel, die unterstützte Entscheidung und den geplanten Datenliefergegenstand. „Liefertermine zuverlässiger einhalten“, „heute gefährdete Aufträge auswählen“ und „eine täglich aktualisierte Arbeitsliste“ gehören zusammen, sind aber unterschiedliche Ergebnisse.
Die benötigten Daten und ihre Grenzen aufnehmen
Für den ersten Anwendungsfall benötigen Sie eine überschaubare Bestandsaufnahme. Ein vollständiger Katalog sämtlicher Unternehmensdaten muss dafür noch nicht existieren. Erfassen Sie zuerst die Quellen, auf denen die ausgewählte Entscheidung tatsächlich beruht.
Im Modellfall wären das beispielsweise die Auftragsverwaltung mit zugesagtem Termin und Status sowie die Einsatzplanung mit verfügbaren Kapazitäten. Für jede Quelle halten Sie fest, wer sie fachlich verantwortet, wie ein Zugriff möglich ist und welche Informationen sich sinnvoll verknüpfen lassen. Der Name einer Datenbank beantwortet diese Fragen noch nicht.
| Zu klärende Frage | Bedeutung im fiktiven Servicebereich |
|---|---|
| Was bezeichnet der Datenwert? | Bedeutet „Termin“ die ursprüngliche Zusage, eine spätere Bestätigung oder den aktuell geplanten Einsatz? |
| Wie werden Datensätze verbunden? | Welche Auftragskennung bleibt zwischen Auftragssystem und Einsatzplanung eindeutig? |
| Wie aktuell sind die Angaben? | Wann wird eine Umbuchung erfasst, übertragen und für die Planung sichtbar? |
| Wer darf die Daten nutzen? | Welche Felder benötigt die Einsatzplanung, welche sind für ihren Zweck entbehrlich? |
| Was fehlt? | Gibt es einen verlässlichen Grund für Verzögerungen oder nur Freitext ohne gemeinsame Bedeutung? |
Metadaten machen diese Angaben auffindbar: Begriffsdefinition, Herkunft, Verantwortlicher, Aktualisierung und Nutzungsgrenze gehören zum Datenbestand. Prüfen Sie Verfügbarkeit, Aktualität, Verknüpfbarkeit und zulässige Nutzung getrennt. Eine vorhandene Datei kann technisch erreichbar und für den geplanten Zweck trotzdem ungeeignet sein.
Externe Quellen ergänzen Sie nur bei einer konkreten Lücke. Vielleicht benötigt die Planung Informationen eines Lieferpartners. Dann gehören Lieferumfang, Zugangsweg und Verwendungsbedingungen ebenso in die Liste wie die internen Daten. Weder öffentlich auffindbare noch von einem Partner angebotene Daten sollten pauschal als frei nutzbar eingeplant werden.
Reife und Qualitätslücken am Vorhaben beurteilen
Eine Reifegradprüfung wird brauchbar, wenn sie einen Engpass und seine Folge erklärt. Ein Punktescore ohne Zusammenhang zur Entscheidung hilft der Einsatzplanung wenig. Untersuchen Sie Daten, Technik, Fähigkeiten und Arbeitsweisen gemeinsam.
Im Beispiel könnte der Status „erledigt“ in einem System den abgeschlossenen Einsatz und im anderen die vollständige Rechnungsstellung bedeuten. Ein technisch korrekter Join würde diesen fachlichen Unterschied nicht beseitigen. Die erste Maßnahme wäre eine gemeinsam verantwortete Statusdefinition, nicht automatisch eine neue Schnittstelle.
Wählen Sie die für die Entscheidung kritischen Qualitätsanforderungen aus. Für die Arbeitsliste müssen Auftragskennung, Terminbezug und Status verständlich sowie ausreichend aktuell sein. Vereinbaren Sie, wer unklare Angaben korrigiert und wie die Einsatzplanung Rückmeldung gibt. Diese Arbeit erhält einen Platz in der Roadmap und im späteren Betrieb.
Ein begrenztes Tech Assessment prüft anschließend, ob die erforderlichen Zugänge, Verknüpfungen und Betriebswege vorhanden sind. Es soll zeigen, welche Lücke den ersten Liefergegenstand verhindert. Eine vollständige technische Neuplanung des Unternehmens ist dafür nicht zwingend nötig.
Verantwortung und Schutz vor der Umsetzung klären
Die Strategie bestimmt die Richtung. Datenmanagement setzt Erfassung, Pflege und Bereitstellung im Alltag um. Governance legt unter anderem fest, wer über Datenbegriffe, Qualität, Zugriffe und Nutzung entscheidet. Diese Aufgaben greifen ineinander, brauchen aber unterschiedliche Verantwortlichkeiten.
Dokumentieren Sie für den Modellfall, wer die Bedeutung der Auftragsdaten verbindlich festlegt und wer die Nutzung durch die Einsatzplanung freigibt. Der Aufbau einer Pipeline darf nicht dazu führen, dass die technische Umsetzung stillschweigend auch die fachliche Entscheidung übernimmt.
| Verantwortung | Konkrete Aufgabe im Modellfall |
|---|---|
| Geschäftlicher Sponsor | Ziel, Priorität, Budget und zulässigen Umfang des Vorhabens entscheiden |
| Fachlicher Datenowner | Termin- und Statusdefinition sowie notwendige Qualitätskorrekturen verantworten |
| Engineering | Übernahme, Verknüpfung, Aktualisierung und technische Fehlerbehandlung umsetzen |
| Analyse und Fachnutzer | Arbeitsliste und Kennzahlen fachlich prüfen und im Entscheidungsprozess verwenden |
| Betrieb und Schutzfunktionen | Überwachung, Berechtigungen, Aufbewahrung und erforderliche Prüfungen organisieren |
Data Science kommt hinzu, wenn ein tatsächlicher Modellierungs- oder Prognosebedarf besteht. In einem kleinen Team kann eine Person mehrere Rollen übernehmen. Trotzdem sollte sichtbar bleiben, in welcher Verantwortung sie eine Entscheidung trifft. Für ungeklärte Begriffe, fehlende Zugänge und ausbleibende Aktualisierungen braucht es einen benannten Eskalationsweg.
Schutzbedarf, Zugangsberechtigung, Datenschutz und ethische Folgen sind getrennte Prüfungen. Fragen Sie nicht nur, ob jemand eine Tabelle lesen kann, sondern auch, wofür die enthaltenen Daten verwendet werden sollen. Im Servicebeispiel könnte eine Kapazitätsübersicht genügen, ohne personenbezogene Detailinformationen in der Arbeitsliste zu verbreiten.
Beziehen Sie den Lebenszyklus ein: Erfassung, Speicherung, Verarbeitung, Weitergabe, Aufbewahrung und Löschung. Legen Sie Freigabepunkte und zuständige Fachstellen fest. Eine Architekturzeichnung, ein entferntes Namensfeld oder eine hohe Softwareedition ersetzt diese Entscheidungen nicht.
Zentral, dezentral oder gemeinsam organisieren
Bei einer zentralen Organisation werden Standards, Plattform und viele Umsetzungsentscheidungen gebündelt. Das kann gemeinsame Definitionen und Betrieb vereinfachen, aber ein zentrales Team auch zum Engpass machen. Bei einer dezentralen Organisation liegen fachliche Entscheidungen näher an den Bereichen; dafür steigen die Anforderungen an Abstimmung und kompatible Schnittstellen.
Eine hybride Organisation kann beispielsweise Plattformbetrieb und übergreifende Zugriffsregeln zentral halten, während Fachbereiche Datenbegriffe und fachliche Abnahme verantworten. Zentraler Speicher bedeutet dabei nicht automatisch zentrale fachliche Verantwortung. Umgekehrt benötigt ein dezentraler Bereich nicht zwingend eine eigene komplette Infrastruktur.
Wählen Sie nach Größe, fachlicher Kopplung und verfügbaren Fähigkeiten. Wenn dieselbe Auftragsdefinition mehrere Bereiche verbindet, muss ihre Änderung gemeinsam geregelt werden. Wenn verschiedene Bereiche unterschiedliche Entscheidungen treffen, können bewusst verschiedene Auswertungen desselben Bestands sinnvoll sein. Keines der Organisationsmodelle ist automatisch der Endpunkt einer Reifeentwicklung.
Die Architektur aus dem Datenweg ableiten
Erst jetzt wird die technische Frage konkret: Wie gelangen die benötigten Informationen aus den vorhandenen Systemen zur nutzbaren Entscheidung? Beschreiben Sie den Weg von Erfassung und Integration über Speicherung und Verarbeitung bis zur Bereitstellung.
Für den fiktiven Servicebereich könnte eine begrenzte Lösung Auftrags- und Planungsdaten übernehmen, gemeinsame Schlüssel prüfen, Statusregeln anwenden und eine freigegebene Arbeitsliste bereitstellen. Zu jedem Übergang gehören Datenstand, Herkunft und ein Fehlerverantwortlicher. So bleibt nachvollziehbar, auf welcher Grundlage ein Auftrag als gefährdet erscheint.
Die Anforderungen entscheiden, welche Fähigkeiten benötigt werden: ein kontrollierter Export oder eine Schnittstelle, eine geeignete Verarbeitung, ein verständliches Datenmodell und ein verwendbarer Zugang. Vorhandene Systeme können Teile davon bereits abdecken. Cloud, bestimmte Hersteller und zusätzliche Plattformen sind keine notwendigen Ergebnisse jeder Datenstrategie.
Bericht, Self-Service und KI unterscheiden
Ein wiederkehrender Bericht beantwortet bekannte Fragen nach vereinbarten Definitionen. Self-Service erlaubt Nutzern zusätzliche Auswertungen innerhalb freigegebener Daten und verständlicher Modelle. Eingebettete Analysen liefern dagegen Informationen unmittelbar in einer Fachanwendung, etwa Hinweise neben einem Auftrag. Wählen Sie danach, wo die Entscheidung tatsächlich getroffen wird.
Im Beispiel kann eine Arbeitsliste in der vorhandenen Planungsanwendung hilfreicher sein als ein zusätzliches Dashboard. Benötigt ein Analyseteam freie Untersuchungen, braucht es einen anderen Zugang und möglicherweise andere Daten. Die Oberfläche allein schafft weder Qualität noch Zuständigkeit.
Ein KI-Modell wäre ein weiterer, gesondert zu begründender Bedarf. Es benötigt passende Trainings- beziehungsweise Nutzungsdaten, Integration, Qualitätsanforderungen und Governance. Zunächst sollte erkennbar sein, welchen zusätzlichen Entscheidungsnutzen es gegenüber einer nachvollziehbaren fachlichen Regel liefern soll. Bereits gespeicherte Daten erzeugen diesen Nutzen nicht automatisch.
Ein erstes Vorhaben priorisieren
Eine Roadmap verbindet das gewünschte Zielbild mit einer machbaren Reihenfolge. Vergleichen Sie mögliche Vorhaben nach Nutzenhypothese, Datenverfügbarkeit, Umsetzbarkeit und Abhängigkeiten. Ein sichtbares Dashboard kann hinter einer unscheinbaren Begriffs- oder Zugangsentscheidung zurückstehen, wenn diese mehrere spätere Vorhaben ermöglicht.
Beteiligen Sie Sponsor, Fachnutzer und Umsetzungsteam früh. Klären Sie, wer Kapazitäten bereitstellt und wer bei einem Zielkonflikt entscheidet. Im Modellfall kann die Einsatzplanung schnelle Aktualisierung wünschen, während der Datenlieferant zunächst nur einen täglichen Export anbieten kann. Diese Grenze muss im Auftrag stehen, bevor eine Umsetzung mit anderen Erwartungen beginnt.
Die Grafik zeigt den Zusammenhang, den das erste Vorhaben herstellen soll: Eine fachliche Entscheidung führt zu Datenbedarf und Verantwortung, daraus zu einer begrenzten Maßnahme und einer überprüfbaren Rückmeldung.
Ein ausgefülltes Strategieblatt
Das folgende Blatt konkretisiert den fiktiven Servicefall. Es ist eine Arbeitshilfe, keine Behauptung über ein durchgeführtes Projekt.
| Feld | Beispielhafte Festlegung |
|---|---|
| Geschäftsziel | Gefährdete Liefertermine so erkennen, dass noch eine fachliche Reaktion möglich ist |
| Entscheidung und Nutzer | Die Einsatzplanung entscheidet, welche Aufträge heute umgebucht oder eskaliert werden |
| Benötigte Daten | Auftragskennung, verbindlicher Termin, fachlich definierter Status und verfügbare Kapazität |
| Quelle und Owner | Auftragsverwaltung und Einsatzplanung; fachlicher Owner für Auftragsstatus benannt |
| Wichtigste Lücke | Zwei Statusdefinitionen sind nicht miteinander vereinbar; die spätere Terminänderung ist nicht eindeutig gekennzeichnet |
| Erstes Vorhaben | Definitionen vereinbaren und einen begrenzten Auftragsbestand in einer gemeinsamen Arbeitsliste prüfen |
| Abhängigkeit | Freigegebener Zugang und verbindliche Zuordnung der Auftragskennungen |
| Verantwortung und Kapazität | Sponsor gibt Umfang frei; Fachowner und Engineering stellen benannte Ansprechpartner und Arbeitszeit bereit |
| Abnahme | Fachnutzer können vereinbarte Beispielaufträge erklären, richtige Termine zuordnen und unklare Fälle gezielt zurückmelden |
| Nächste Entscheidung | Arbeitsliste erweitern, Grundlagen nacharbeiten oder Versuch beenden, wenn der benötigte Informationsstand nicht erreichbar ist |
Für ein eigenes Vorhaben können Sie diese Felder übernehmen:
Wir wollen … erreichen. Dafür entscheidet … über … . Benötigt werden … aus … . Fachlich verantwortlich ist … . Heute verhindert … die Nutzung. Zuerst liefern wir … . Vorausgesetzt wird … . Freigegeben wird das Ergebnis, wenn … . Danach entscheiden wir … .
Füllen Sie die Leerstellen gemeinsam aus. Wenn niemand den Datenowner oder die Abnahme benennen kann, ist der Auftrag noch nicht bereit für eine reine Toolentscheidung. Reservieren Sie in der Roadmap auch Zeit für Qualitätsarbeit, Zugänge und Befähigung.
Fortschritt an drei Ebenen beurteilen
Unterscheiden Sie Nutzung, Datenfähigkeit und geschäftliche Wirkung. Eine veröffentlichte Arbeitsliste beweist zunächst nur ihre Bereitstellung. Ob die Einsatzplanung sie verwendet, die zugrunde liegenden Daten zuverlässig versteht und dadurch bessere Entscheidungen trifft, sind weitere Fragen.
Vereinbaren Sie vor dem Versuch eine Ausgangsbeobachtung und einen gemeinsamen Auswertungstermin. Im Modellfall könnte das Team dokumentieren, wie kritische Aufträge heute erkannt werden, welche Informationen dabei fehlen und ob die neue Liste im vereinbarten Entscheidungsprozess hilft. Verwenden Sie nachvollziehbare Beobachtungen statt nachträglich passend gewählter Erfolgszahlen.
Bleibt die Liste ungenutzt, untersuchen Sie den Grund: falscher Zeitpunkt, fehlende Berechtigung, unverständliche Definition oder ungeeigneter Arbeitsablauf. Aus diesen Befunden entstehen Änderungen an Priorität und Roadmap. Beteiligung endet deshalb nicht mit einem Workshop; sie setzt sich in fachlicher Abnahme und laufender Rückmeldung fort.
Wachstum, Zusammenarbeit und Datenaustausch einplanen
Eine erfolgreiche erste Anwendung kann weitere Anforderungen auslösen. Prüfen Sie getrennt, was wächst: die Zahl der Quellen, das Datenvolumen, die Nutzerzahl oder gleichzeitig ausgeführte Abfragen. Jede Veränderung betrifft andere Teile des Betriebs. Zusätzlicher Speicher beseitigt beispielsweise keinen Engpass bei Quellfreigaben oder fachlichen Entscheidungen.
Planen Sie Überwachung für Datenstand, Fehler, Kosten und relevante Änderungen ein. Benennen Sie, wer neue Quellen bewertet, Berechtigungen pflegt und eine geänderte Statuslogik mit den Nutzern abstimmt. Technische Kapazität und verfügbare Betriebskapazität müssen zusammenpassen. Mehr Automatisierung auf einer bestimmten Plattform garantiert weder einen tragfähigen Betrieb noch die Erfüllung aller Anforderungen.
Datenkompetenz hilft, diese Arbeit zu verteilen. Schulen Sie Fachnutzer an ihrer tatsächlichen Aufgabe: Was bedeutet der angezeigte Termin? Welche Fälle fehlen? Wann darf aus der Liste keine Entscheidung abgeleitet werden? Engineering benötigt die fachliche Bedeutung; die Fachseite muss technische Aktualisierungs- und Fehlergrenzen verstehen. Gemeinsame Beispielbesprechungen und dokumentierte Begriffe können diesen Wissenstransfer unterstützen.
Über Bereiche und Partner hinweg teilen
Silos entstehen nicht nur durch getrennte Speicher. Auch zwei technisch verbundene Systeme bleiben fachlich getrennt, wenn derselbe Status unterschiedlich verstanden wird. Vereinbaren Sie deshalb Bedeutung, Format, Identität, Schnittstelle und Nutzungszweck des Austauschs.
Für einen Lieferpartner im Modellfall wäre etwa zu klären, welche Terminänderungen übertragen werden, wie ein Auftrag identifiziert wird und wer eine widersprüchliche Angabe berichtigt. Eine technisch erfolgreiche Übermittlung ist erst ein Teil der Antwort. Interne Daten, Partnerdaten und öffentliche Quellen brauchen jeweils nachvollziehbare Zugangs- und Verwendungsbedingungen.
Wenn viele Organisationen nach gemeinsamen Regeln Daten austauschen, kann ein Datenraum als übergreifender Rahmen relevant werden. Ein Vermittler kann Parteien und Zugänge zusammenbringen. Das ist etwas anderes als die Daten allgemein zu veröffentlichen oder sämtliche Rechte daran zu übertragen. Die aktuelle Erläuterung der Europäischen Kommission zum Data Governance Act beschreibt einen Rahmen für vertrauenswürdigen freiwilligen Datenaustausch und Datenvermittlungsdienste; für personenbezogene Daten gilt die DSGVO weiter.
Für ein einzelnes internes Berichtsvorhaben ist ein solcher Rahmen nicht automatisch erforderlich. Halten Sie im Strategieblatt fest, welches konkrete Kooperationsproblem gelöst werden soll und welche Regeln dafür fehlen. So bleibt der externe Austausch ein begründeter Teil der Unternehmensstrategie.
Die passende Unterstützung auswählen
Aus dem ersten Datenauftrag lässt sich ableiten, welche Fähigkeit dem eigenen Team fehlt. Das kann fachliche Moderation für gemeinsame Begriffe sein, eine unabhängige Technikbewertung, Integrationskompetenz oder Unterstützung für den Betrieb. Diese Bedarfe sollten Sie bei der Auswahl externer Hilfe getrennt ansprechen.
Fragen Sie nach nachvollziehbaren Annahmen, Zusammenarbeit mit Ihren Fachverantwortlichen und dem geplanten Wissenstransfer. Klären Sie, welche Entscheidungen intern bleiben, welche Arbeit übergeben wird und woran Sie ein brauchbares Ergebnis erkennen. Auch mit Unterstützung braucht das Unternehmen eigene Prioritäten, Datenverantwortliche und eine fachliche Abnahme.
Wenn Ziel, Datenbedarf und erste Lücken feststehen, können Sie die technische Umsetzung mit dem bestehenden Angebot von eBiz zu Cloud Data & Intelligence weiter konkretisieren. Ein geeigneter Ausgangspunkt ist Ihr ausgefülltes Strategieblatt: eine relevante Entscheidung, benannte Daten und ein begrenztes erstes Vorhaben.