In unserer Schulungs- und Beratungspraxis sprechen wir oft von der Idee, sich auf den geschäftlichen Nutzen zu konzentrieren". Geschäftswert in Unternehmen data warehousing ist definiert als "etwas von Wert für das Unternehmen" (ob Sie es glauben oder nicht, wir glauben, dass es manchmal gesagt werden sollte).
Der Grund, warum ein Unternehmen ein Budget für das Enterprise data warehouse einrichtet, ist in der Regel, dass es Berichte oder Dashboards mit verwertbaren Informationen benötigt.
Auf der anderen Seite ist das wichtigste Gegenargument, dass das Unternehmen data warehouse mehr ist als nur Berichte und Dashboards. Es gibt tatsächlich eine Menge weiterer technischer Komponenten (nicht-funktionale Anforderungen), die erstellt werden müssen, einschließlich, aber nicht beschränkt auf:
- Infrastruktur und Lagerung
- Einrichtung von Netzwerken und Sicherheit
- Mehrere Umgebungen
- Leistungsoptimierung
- Aufrechterhaltung der Sicherheit
- Datenschutzverpflichtungen erfordern die Löschung von Verbraucherdaten
- Dokumentation
- Automatisierte kontinuierliche Bereitstellung
- Eine Prüfstrategie ist erforderlich
- Prüfbarkeit und Datenherkunft
- Operative Aspekte
- Qualität der Daten und Datenbereinigung (gute, schlechte und hässliche Daten)
- Daten- und Informationsmanagement
- Verwaltung von Metadaten
- Datenlager Automatisierung
Das ist in Ordnung, und wir sind damit völlig einverstanden. Allerdings sind all diese nichtfunktionalen Anforderungen für den Geschäftsanwender von zweitrangiger Bedeutung. Ihnen ist es (in der Regel) egal, dass das Unternehmens-data warehouse mit einer ausgefallenen neuen Technologie entwickelt wurde oder dass die Bereitstellung vollautomatisch erfolgt.
Wen interessiert das?
Ich schon, denn ich bin ein Techniker. Aber sollte das die Wirtschaft wirklich interessieren?
Die kurze Antwort lautet: "Nun ja, vielleicht".
Nein, denn es ist nicht ihre primäre Absicht, warum sie überhaupt auf die Idee gekommen sind, ein data warehouse für Unternehmen einzuführen (ich wette, wegen des Bedarfs an Berichterstattung und Dashboarding).
Ja, denn sie sind an einer soliden, dokumentierten, getesteten, stabilen usw. Lösung interessiert. Die Umsetzung all dieser nicht-funktionalen Anforderungen hat also Priorität, aber leider nur sekundäre Priorität.
Und niemand erwartet, dass diese nicht-funktionalen Anforderungen im ersten Sprint umgesetzt werden - stattdessen haben wir in der Regel mehr Zeit, sie umzusetzen. Und ja, jeder erwartet, dass die Funktionalität irgendwann zur Verfügung steht. Aber auch hier gilt: nicht nach dem ersten Sprint.
Die regelmäßige Bereitstellung von Berichten oder Dashboards zeigt den Geschäftsanwendern jedoch den Projektfortschritt und macht transparenter, wofür (und wie viel) sie bezahlen.
Deshalb konzentrieren wir uns in unseren Projekten darauf, den tatsächlichen Geschäftswert zu liefern, ohne dabei den Blick für die nichtfunktionalen Anforderungen zu verlieren.
Aber nur als zweite Priorität.
Was meinen Sie dazu? Sind Sie einverstanden? Oder können Sie eine dritte Perspektive in die Diskussion einbringen? Ich freue mich auf Ihre Kommentare!
Das Beste,
Michael Olschimke
Hallo Michael,
Dem stimme ich zu. Aber wie stellen wir sicher, dass die priorisierten nicht-technischen Anforderungen in den nachfolgenden Sprints berücksichtigt werden, wenn das Geschäft zu sehr auf die
Geschäftswert.
Gibt es einen Mittelweg, den Sie vorschlagen, wenn es um nichtfunktionale Anforderungen an EDW geht?
Hallo Prabhu,
In unseren Sprints haben wir immer auch einige nicht-funktionale Anforderungen im Arbeitspensum enthalten. Während der Fokus eindeutig auf dem Geschäftswert liegt, liefert jeder Sprint auch einige nicht-funktionale Anforderungen. Die Priorisierung beider Gruppen von Funktionalitäten wird von der Geschäftsseite vorgenommen (wobei ich zugeben muss, dass die Priorisierung der nicht-funktionalen Anforderungen eher von der Geschäftsseite "getrieben" als "gemacht" wird).
Ich hoffe, das hilft,
Mike