Power BI-Implementierungsplanung: BI-Lösungsplanung

Hinweis

Dieser Artikel ist Teil der Artikelreihe zur Power BI-Implementierungsplanung. Diese Reihe konzentriert sich in erster Linie auf die Power BI-Erfahrung in Microsoft Fabric. Eine Einführung in die Artikelreihe finden Sie unter Power BI-Implementierungsplanung.

Dieser Artikel soll Ihnen bei der Planung von Lösungen helfen, die Ihre Business Intelligence-Strategie (BI) unterstützen. Er wendet sich in erster Linie an folgende Zielgruppen:

• BI- und Analysemanager*innen: Entscheidungsträger, die für die Überwachung des BI-Programms und strategisch wichtige BI-Lösungen verantwortlich sind
• COE- (Center of Excellence), IT- und BI-Teams: Teams, die BI-Unternehmenslösungen für ihre Organisation entwerfen und bereitstellen
• Fachkräfte (SMEs) und Inhaltsbesitzer*innen und -ersteller*innen: Teams und Einzelpersonen, die Analysen in einer Abteilung unterstützen und Lösungen in Szenarien mit Self-Service, Abteilungs-BI oder Team BI entwerfen und bereitstellen

Eine BI-Strategie ist ein Plan zum Implementieren, Verwenden und Verwalten von Daten und Analysen. Sie definieren Ihre BI-Strategie, indem Sie mit der strategischen BI-Planung beginnen. Die strategische Planung hilft Ihnen dabei, Ihre BI-Fokusbereiche und -Ziele zu identifizieren. Um die Vorgehensweise zum Erreichen Ihrer BI-Ziele zu ermitteln, beschreiben Sie bestimmte Schlüsselergebnisse mithilfe der taktischen Planung. Fortschritte in Richtung dieser Schlüsselergebnisse erreichen Sie, indem Sie BI-Lösungen planen und bereitstellen.

Hinweis

Im OKR-Framework (Objectives and Key Results) sind Ziele klar formulierte, allgemeine Beschreibungen von dem, was Sie erreichen möchten. Im Gegensatz dazu sind Schlüsselergebnisse spezifische, erreichbare Ergebnisse, um den Fortschritt in Richtung eines Ihrer Ziele zu messen.

Darüber hinaus sind Initiativen oder Lösungen Prozesse oder Tools, die Ihnen dabei helfen, ein oder mehrere Schlüsselergebnisse zu erreichen. Lösungen erfüllen bestimmte Datenanforderungen für Benutzer*innen. Eine Lösung kann in verschiedenen Formen vorliegen (z. B. Datenpipeline, Data Lakehouse oder Power BI-Semantikmodell bzw. -Bericht).

Weitere Informationen zu OKRs finden Sie unter OKRs (Microsoft Viva Goals).

Es gibt viele Ansätze zum Planen und Implementieren von BI-Lösungen. In diesem Artikel wird ein Ansatz beschrieben, mit dem Sie BI-Lösungen planen und implementieren können, die Ihre BI-Strategie unterstützen.

Das folgende Diagramm zeigt, wie Sie die BI-Lösungsplanung durchführen.

Führen Sie die folgenden Schritte aus, um die BI-Lösungsplanung durchzuführen.

Schritt	Beschreibung
1	Stellen Sie ein Projektteam zusammen, das Anforderungen sammelt und den Entwurf der Lösung definiert.
2	Planen Sie die Lösungsbereitstellung, indem Sie zunächst Tools und Prozesse einrichten.
3	Führen Sie eine Machbarkeitsstudie (Proof of Concept, PoC) für die Lösung durch, um Annahmen über den Entwurf zu überprüfen.
4	Erstellen und überprüfen Sie Inhalte mithilfe iterativer Entwicklungs- und Validierungszyklen.
5	Stellen Sie die Lösung bereit, und unterstützen und überwachen Sie sie, nachdem sie in der Produktionsumgebung veröffentlicht wurde.

Hinweis

Die BI-Lösungsplanung gilt sowohl für Projekte für Self-Service-BI als auch für Unternehmens-BI.

Weitere Informationen finden Sie in der Reihe zur Power BI-Migration. Auch wenn es in der Reihe um die Migration geht, sind die wichtigsten Aktionen und Überlegungen auch für die Lösungsplanung relevant.

Schritt 1: Erfassen der Anforderungen

Sie beginnen mit der Lösungsplanung, indem Sie zuerst Anforderungen erfassen und den Lösungsentwurf definieren.

Hinweis: Die strategische und taktische Planung erfolgt durch ein Arbeitsteam, das die Initiative leitet. Im Gegensatz dazu wird die Lösungsplanung von einem Projektteam geleitet, das aus Inhaltsbesitzer*innen und -ersteller*innen besteht.

Das Sammeln der richtigen Anforderungen ist wichtig für eine erfolgreiche Lösungsbereitstellung und -einführung. Eine effektive Möglichkeit, Anforderungen zu erfassen, besteht darin, die richtigen Projektbeteiligten zu identifizieren und einzubeziehen, gemeinsam das zu lösende Problem zu definieren und dieses gemeinsame Verständnis des Problems zu nutzen, um einen Lösungsentwurf zu erstellen.

Im Folgenden finden Sie einige Vorteile der Verwendung eines gemeinsamen Ansatzes zum Erfassen von Anforderungen.

• Angaben von Benutzer*innen führen zu nützlicheren Entwürfen: Indem Sie die Benutzer*innen in die Diskussion zum Sammeln der Anforderungen einbinden, können Sie geschäftsbezogene Datenanforderungen effektiver erfassen. Beispielsweise können Benutzer*innen Inhaltsersteller*innen zeigen, wie sie vorhandene Lösungen verwenden und Feedback zur wahrgenommenen Effektivität dieser Lösungen geben.
• Vermeiden von Annahmen und Verringern von Änderungsanforderungen: In Diskussionen mit Benutzer*innen werden häufig Nuancen, Ausnahmen und verborgene Komplexitäten aufgedeckt. Diese Erkenntnisse verringern die Wahrscheinlichkeit von Anforderungen in einer späteren Phase, die aufwendig zu behandeln sein können.
• Die Einbeziehung der Benutzer*innen steigert die Akzeptanz der Lösung: Indem Sie die Benutzer*innen in den Entwurf und die frühe Entwicklung einbeziehen, bieten Sie ihnen die Möglichkeit, das Endergebnis zu beeinflussen. Die Beteiligung kann Benutzer*innen auch ein Gefühl des Besitzes und der Verantwortlichkeit für die Lösung vermitteln. Stark involvierte Benutzer*innen werden die Lösung wahrscheinlicher unterstützen und ihre Community in der Praxis bei der effektiven Nutzung anleiten.
• Entwürfe definieren die Erwartungen von Projektbeteiligten und Geschäftsbenutzer*innen: Indem Sie Modelle oder Illustrationen des Lösungsentwurfs erstellen, können Sie Projektbeteiligten deutlich zeigen, was die Lösung bringen wird. Es hilft auch dabei, ein gegenseitiges Verständnis der erwarteten Projektergebnisse zu etablieren. Dieser Prozess wird auch als Entwurfsdenkenbezeichnet und kann eine effektive Möglichkeit sein, komplexe Probleme zu verstehen und zu lösen.

Sie können verschiedene Ansätze verwenden, um Benutzer*innen einzubinden und Anforderungen zu erfassen. Sie können z. B. Anforderungen in einem Geschäftsentwurf und einem technischen Entwurf erfassen (dies wird in späteren Abschnitten dieses Artikels ausführlich beschrieben).

Ein Geschäftsentwurf stellt einen Ansatz zum Erfassen von Geschäftsanforderungen dar. Der Schwerpunkt liegt auf der Einbindung von Geschäftsbenutzer*innen in Sitzungen zum Geschäftsentwurf, um die Lösung gemeinsam zu entwerfen. Die Ausgabe eines Geschäftsentwurfs besteht aus Lösungssimulationen und einer verständlichen Entwurfsdokumentation.

Der technische Entwurf stellt einen Ansatz dar, um geschäftliche Anforderungen in technische Anforderungen zu übersetzen und Annahmen für den Entwurf zu berücksichtigen. Der technische Entwurf konzentriert sich auf die Überprüfung des Geschäftsentwurfs und das Definieren des anzuwendenden technischen Ansatzes. Um den Entwurf zu überprüfen, setzen sich Inhaltsersteller*innen in der Regel bei Bedarf mit technischen Fachkräften in themenspezifischen Diskussionen zum technischen Entwurf zusammen.

Wichtig

Ein häufiger Grund für Fehler bei der Implementierung sind falsch erfasste Anforderungen. Viele Teams sammeln die falschen Anforderungen, da sie mit den falschen Projektbeteiligten zusammenarbeiten, z. B. Entscheidungsträger*innen, die Vorgaben für die zu erstellenden Lösungen machen.

Das Einbinden von Geschäftsbenutzer*innen über Ansätze für die Zusammenarbeit wie einem Geschäftsentwurf kann helfen, bessere Anforderungen zu erfassen. Bessere Anforderungen führen oftmals zu einer effizienteren Entwicklung und stabileren Lösungen.

Hinweis

Für einige Teams ist die Einführung eines strukturierten Prozesses zur Anforderungserfassung eine große Änderung. Sie sollten diese Änderung umsichtig begleiten und darauf achten, dass sie die Lösungsplanung nicht unterbrechen. Es wird empfohlen, nach Möglichkeiten zu suchen, diese Ansätze an die Arbeitsweise Ihres Teams anzupassen.

Vorbereiten der Lösungsplanung

Bereiten Sie zunächst die Lösungsplanung vor, und berücksichtigen Sie dabei die in den folgenden Abschnitten beschriebenen Faktoren.

• Identifizieren der verantwortlichen Personen für die Lösungsplanung: Im Rahmen der taktischen BI-Planung hat das Arbeitsteam ein priorisiertes Backlog von Lösungen erstellt. Bei der Lösungsplanung ist ein Projektteam für das Entwerfen, Entwickeln und Bereitstellen einer oder mehrerer Lösungen aus dem Backlog verantwortlich. Für jede Lösung im Backlog sollten Sie ein Projektteam zusammenstellen, das für diese Lösung verantwortlich ist. Neben der BI-Lösungsplanung sollte das Projektteam folgende Schritte ausführen:
  • Definieren der Zeitpläne und Meilensteine für die Lösungsplanung
  • Identifizieren und Einbinden der richtigen Projektbeteiligten für die Anforderungserfassung
  • Einrichten eines zentralen Orts für Kommunikation, Dokumentation und Planung
  • Einbinden von Projektbeteiligten zum Sammeln der Anforderungen
  • Kommunizieren und Koordinieren der Arbeit mit den Projektbeteiligten und Geschäftsbenutzer*innen
  • Orchestrieren iterativer Entwicklungs- und Testzyklen mit Geschäftsbenutzer*innen
  • Dokumentieren der Lösung
  • Binden Sie Benutzer*innen in die Lösung ein, indem Sie einen Schulungsplan definieren und einführen.
  • Bereitstellen von Support für Lösungen nach der Bereitstellung
  • Berücksichtigen Sie angemessene Benutzeranforderungen, um die Lösung nach der Bereitstellung zu ändern order zu aktualisieren.
  • Übergeben der Lösung (bei Bedarf) nach der Bereitstellung
• Zentralisieren von Kommunikation und Dokumentation: Es ist wichtig, dass das Projektteam die Kommunikation und Dokumentation für die BI-Lösungsplanung zentralisiert. Das Projektteam sollte z. B. Anforderungen, die Kommunikation von Projektbeteiligten, Zeitpläne und Projektleistungen zentralisieren. Erwägen Sie, die gesamte Dokumentation in einem zentralen Portal zu speichern.
• Planen der Anforderungserfassung: Das Projektteam sollte zunächst die Sitzungen für den Geschäftsentwurf planen, um die Geschäftsanforderungen zu sammeln. Diese Sitzungen haben die Form interaktiver Besprechungen und können einem ähnlichen Format folgen wie die Workshops für die strategische Planung.

Tipp

Erwägen Sie, die für die Lösung verantwortlichen Supportteams frühzeitig im Prozess der Anforderungserfassung festzulegen und einzubeziehen. Um die Lösung effektiv zu unterstützen, benötigen die Supportteams ein umfassendes Verständnis der Lösung, ihres Zwecks und der Benutzer*innen. Dies ist besonders wichtig, wenn das Projektteam nur aus externen Berater*innen besteht.

Sammeln von Geschäftsanforderungen

Das Sammeln der richtigen Geschäftsanforderungen ist entscheidend für den Entwurf einer geeigneten Lösung. Um die richtigen Anforderungen zu erfassen und einen effektiven Lösungsentwurf zu definieren, kann das Projektteam seine Geschäftsentwurfssitzungen zusammen mit Geschäftsbenutzer*innen durchführen.

Die Geschäftsentwurfssitzungen haben folgende Ziele:

• Bestätigen Sie den ursprünglichen Lösungsbereich.
• Definieren und Verstehen des Problems, für das die Lösung vorgesehen ist
• Identifizieren der wichtigsten Projektbeteiligten für die Lösung
• Sammeln der richtigen Geschäftsanforderungen
• Vorbereiten eines Lösungsentwurfs, der die geschäftlichen Anforderungen erfüllt
• Vorbereiten der unterstützenden Entwurfsdokumentation

Das folgende Diagramm zeigt, wie Geschäftsanforderungen gesammelt und der Lösungsentwurf mithilfe eines Geschäftsentwurfs definiert wird.

Das Diagramm zeigt die folgenden Schritte.

Element	Beschreibung
	Das Projektteam beginnt den Geschäftsentwurf, indem es den Lösungsbereich bestätigt, der zuerst in der taktischen Planung dokumentiert wurde. Es sollte klar machen, welche Geschäftsbereiche, Systeme und Daten die Lösung umfasst.
	Das Projektteam identifiziert wichtige Projektbeteiligte aus der Benutzercommunity, die zu den Geschäftsentwurfssitzungen eingeladen werden sollen. Wichtige Projektbeteiligte sind Benutzer*innen mit ausreichendem Wissen und Vertrauenswürdigkeit, um die Themenbereiche der Lösung darzustellen.
	Das Projektteam plant Geschäftsentwurfssitzungen. Die Planung umfasst die Benachrichtigung von Projektbeteiligten, das Organisieren von Besprechungen, das Vorbereiten von Ergebnissen und das Interagieren mit Geschäftsbenutzer*innen.
	Das Projektteam sammelt und untersucht vorhandene Lösungen, die derzeit von den Geschäftsbenutzer*innen verwendet werden, um vorhandene geschäftliche Datenanforderungen zu erfüllen. Um diesen Prozess zu beschleunigen, kann das Projektteam relevante Untersuchungen aus der strategischen BI-Planung nutzen, die im Kommunikationshub dokumentiert wurden.
	Das Projektteam führt Geschäftsentwurfssitzungen mit Projektbeteiligten durch. Bei diesen Sitzungen handelt es sich um kleine, interaktive Besprechungen, bei denen das Projektteam den Projektbeteiligten die Geschäftsdatenanforderungen erläutert.
	Das Projektteam schließt den Geschäftsentwurf ab, indem es den Projektbeteiligten und anderen Benutzer*innen einen Lösungsentwurf für Feedback und zur Genehmigung vorstellt. Der Geschäftsentwurf ist erfolgreich, wenn die Beteiligten sich darauf einigen, dass der Entwurf ihnen hilft, ihre Geschäftsziele zu erreichen.

Der Geschäftsentwurf wird mit den folgenden Ergebnissen abgeschlossen.

• Lösungsentwürfe: Diagramme mit Modellen, Prototypen oder Drahtmodellen veranschaulichen den Lösungsentwurf. Diese Dokumente übersetzen die Anforderungen in eine konkrete Entwurfsblaupause.
• Liste der Geschäftsmetriken: Hierzu gehören quantitative Bereiche, die in der Lösung erwartet werden, einschließlich Geschäftsdefinitionen und erwarteter Aggregationen. Wenn möglich, sollten Sie sie den Benutzer*innen nach Wichtigkeit sortiert vorlegen.
• Liste der Geschäftsattribute: Dies sind relevante Attribute und Datenstrukturen, die in der Lösung erwartet werden, einschließlich Geschäftsdefinitionen und Attributnamen. Fügen Sie nach Möglichkeit Hierarchien ein, und präsentieren Sie die Attribute den Benutzer*innen nach Wichtigkeit sortiert.
• Zusätzliche Dokumentation: Dies umfasst Beschreibungen der wichtigsten funktionalen oder Complianceanforderungen. Diese Dokumentation sollte so genau wie nötig und so knapp wie möglich sein.

Die Ergebnisse des Geschäftsentwurfs werden für den technischen Entwurf verwendet und in diesem überprüft.

Tipp

Lösungssimulationen, Prototypen oder Drahtmodelldiagramme können die erwarteten Ergebnisse sowohl für Entwickler*innen als auch für Endbenutzer*innen deutlich machen. Das Erstellen effektiver Simulationen erfordert keine künstlerischen Fähigkeiten oder Talente. Sie können einfache Tools wie Microsoft Whiteboard, PowerPoint oder sogar nur einen Stift und ein Blatt Papier verwenden, um den Entwurf zu veranschaulichen.

Sammeln technischer Anforderungen

Nach Abschluss des Geschäftsentwurfs überprüft das Projektteam seine Ergebnisse mithilfe eines technischen Entwurfs. Der Ansatz für den technischen Entwurf ähnelt dem für den Geschäftsentwurf. Während sich der Geschäftsentwurf auf Geschäftsdatenanforderungen konzentriert, liegt der Fokus beim technischen Entwurf auf den technischen Aspekten einer Lösung. Ein wichtiges Ergebnis des technischen Entwurfs ist der Lösungsplan, der den endgültigen Lösungsentwurf beschreibt und nachvollziehbare Schätzungen des Implementierungsaufwands liefert.

Hinweis

Im Gegensatz zum Geschäftsentwurf ist der technische Entwurf größtenteils eine unabhängige Untersuchung von Quelldaten und Systemen, die von Inhaltsersteller*innen und -besitzer*innen durchgeführt wird.

Der technische Entwurf hat folgende Ziele:

• Überprüfen der Ergebnisse des Geschäftsentwurfs
• Berücksichtigen technischer Annahmen im aktuellen Entwurf
• Identifizieren relevanter Datenquellen im Geltungsbereich und Definieren von Feldberechnungen und Zuordnungen von Feldquellen für jede Datenquelle
• Übersetzen der geschäftlichen Anforderungen in technische Anforderungen
• Erstellen von Schätzungen für den erforderlichen Aufwand bei der Implementierung

Das Projektteam bindet technische oder funktionale Projektbeteiligte in begrenzten, themenspezifischen Sitzungen für den technischen Entwurf ein. Diese Sitzungen sind interaktive Besprechungen mit den funktionalen Projektbeteiligten, bei denen technische Anforderungen gesammelt werden sollen. Die Beteiligten sind für bestimmte Funktionsbereiche verantwortlich, die für eine effektive Funktion der Lösung erforderlich sind.

Beispiele für Projektbeteiligte beim technischen Entwurf sind:

• Sicherheits- und Netzwerkteams: verantwortlich für die Gewährleistung der Sicherheit und Compliance der Daten
• Funktionale Teams und Data Stewards: verantwortlich für die Zusammenstellung der Quelldaten
• Architekt*innen: Besitzer*innen bestimmter Plattformen, Tools oder Technologien

Das Projektteam beteiligt sich an den Sitzungen zum technischen Entwurf, um technische Aspekte der Lösung zu besprechen. Zu den technische Aspekten kann Folgendes gehören:

• Datenquellenverbindungen: Details zum Herstellen einer Verbindung mit Datenquellen und zum Integrieren von Datenquellen
• Netzwerke und Datengateways: Details zu privaten Netzwerken oder lokalen Datenquellen
• Quellzuordnung für Felder: Datenzuordnungen von Geschäftsmetriken und Attributen zu Datenquellenfeldern
• Berechnungslogik: Übersetzung von Geschäftsdefinitionen in technische Berechnungen
• Technische Features: Features oder Funktionen, die zur Unterstützung geschäftlicher Anforderungen erforderlich sind

Tipp

Das Projektteam, das den Geschäftsentwurf durchgeführt hat, sollte auch den technischen Entwurf durchführen. Aus praktischen Gründen können jedoch auch andere Personen den technische Entwurf leiten. In diesem Fall beginnen Sie den technischen Entwurf, indem Sie die Ergebnisse des Geschäftsentwurfs überprüfen.

Im Idealfall sollten die Personen, die den technischen Entwurf leiten, über umfassende Kenntnisse zu den Ergebnissen und Geschäftsbenutzer*innen verfügen.

Das folgende Diagramm zeigt, wie Geschäftsanforderungen mithilfe eines technischen Entwurfs in technische Anforderungen übersetzt werden.

Das Diagramm zeigt die folgenden Schritte.

Element	Beschreibung
	Das Projektteam beginnt mit dem technischen Entwurf, indem es den Datenquellenbereich basierend auf den Ergebnissen des Geschäftsentwurfs definiert. Der Datenquellenbereich legt fest, welche Daten zum Erstellen der Lösung erforderlich sind. Um die richtigen Datenquellen zu ermitteln, befragt das Projektteam die geschäftlichen und funktionalen Fachkräfte (SMEs).
	Das Projektteam bestimmt die technischen oder funktionalen Projektbeteiligten, die später zu den Sitzungen für den technischen Entwurf eingeladen werden sollen.
	Das Projektteam plant kurze, themenbezogene Sitzungen mit den funktionalen Projektbeteiligten, um technische Aspekte der Lösung zu diskutieren. Die Planung umfasst die Benachrichtigung von Projektbeteiligten, das Organisieren von Besprechungen und das Vorbereiten von Projektergebnissen.
	Das Projektteam untersucht die technische Anforderungen. Die Untersuchung umfasst das Definieren von Feldberechnungen und Datenquellenzuordnungen sowie das Umsetzen der Annahmen zum Geschäftsentwurf mit einer technischen Analyse und Dokumentation.
	Bei Bedarf lädt das Projektteam Projektbeteiligte zu den Sitzungen für den technischen Entwurf ein. Die Sitzungen konzentrieren sich auf einen bestimmten technischen Aspekt der Lösung, z. B. auf die Sicherheit oder auf Datenquellenverbindungen. In diesen Sitzungen sammelt das Projektteam qualitatives Feedback von Projektbeteiligten und Fachkräfte (SMEs).
	Das Projektteam bereitet seine Ergebnisse mithilfe eines Lösungsplans vor, den es den Projektbeteiligten und Entscheidungsträger*innen präsentiert. Der Plan ist eine Iteration und Erweiterung der Ergebnisse des Geschäftsentwurfs und enthält den endgültigen Entwurf, Schätzungen und andere Ergebnisse.
	Der technische Entwurf sollte mit einer abschließenden Besprechung mit allen Projektbeteiligten und Entscheidungsträgern enden, bei der entschieden wird, ob der Prozess fortgesetzt werden soll. Diese Besprechung bietet eine letzte Gelegenheit, die Lösungsplanung zu bewerten, bevor Ressourcen für die Entwicklung der Lösung reserviert werden.

Hinweis

Der technische Entwurf kann eine unerwartete Komplexität aufdecken, die die Lösungsplanung aufgrund der aktuellen Ressourcenverfügbarkeit oder der Bereitschaft der Organisation möglicherweise undurchführbar macht. In diesem Fall sollte die Lösung im nachfolgenden taktischen Planungszeitraum neu bewertet werden. Abhängig von der Dringlichkeit der Geschäftsdatenanforderungen möchten Entscheidungsträger*innen (z. B. die leitenden Sponsor*innen) möglicherweise trotzdem mit einer Machbarkeitsstudie (Proof of Concept, PoC) oder nur einem Teil der geplanten Lösung fortfahren.

Der technische Entwurf endet mit einem Lösungsplan, der die folgenden Ergebnisse liefert.

• Tools und Technologien: Liste der relevanten technischen Hilfsmittel, die für die Implementierung der Lösung erforderlich sind. Die Liste enthält in der Regel relevante neue Lizenzoptionen (z. B. Fabric-Kapazität oder Premium-Einzelbenutzerlizenzen), Features und Tools.
• Definierte Liste von Geschäftsmetriken: Berechnungen und Feldquellzuordnungen der Geschäftsmetriken für alle betroffenen Datenquellen. Für dieses Ergebnis verwendet das Projektteam die Liste der Geschäftsmetriken, die im Geschäftsentwurf erstellt wurde.
• Definierte Liste von Geschäftsattributen: Feldquellzuordnungen der Geschäftsattribute für alle betroffenen Datenquellen. Für dieses Ergebnis verwendet das Projektteam die Liste der Geschäftsattribute, die im Geschäftsentwurf erstellt wurde.
• Überarbeitete Entwürfe: Überarbeitungen des Lösungsentwurfs basierend auf Änderungen oder ungültigen Annahmen im Geschäftsentwurf. Überarbeitete Entwürfe sind aktualisierte Versionen der Modelle, Prototypen oder Drahtmodelldiagramme, die im Geschäftsentwurf erstellt wurden. Wenn keine Überarbeitungen erforderlich sind, kommunizieren Sie, dass der technische Entwurf den Geschäftsentwurf bestätigt.
• Schätzung des Aufwands: Schätzung der Ressourcen, die zum Entwickeln, Unterstützen und Warten der Lösung erforderlich sind. Die Schätzung dient als Grundlage für die endgültige Entscheidung darüber, ob mit der Implementierung der Lösung fortgefahren werden soll.

Wichtig

Stellen Sie sicher, dass das Projektteam die Projektbeteiligten über Änderungen oder unerwartete Entdeckungen im technischen Entwurf benachrichtigt. Zu diesen Sitzungen zum technischen Entwurf sollten weiterhin relevante Geschäftsbenutzer*innen eingeladen werden. Stellen Sie jedoch sicher, dass die Projektbeteiligten nicht unnötigerweise mit komplexen technischen Informationen konfrontiert werden.

Tipp

Da sich die Geschäftsziele ständig weiterentwickeln, ist zu erwarten, dass sich auch die Anforderungen ändern. Gehen Sie nicht davon aus, dass die Anforderungen für BI-Projekte unveränderlich sind. Wenn Sie Probleme mit sich ändernden Anforderungen haben, kann dies ein Hinweis darauf sein, dass der Prozess der Anforderungserfassung nicht effektiv war oder dass Ihre Entwicklungsworkflows kein regelmäßiges Feedback einschließen.

Prüfliste: Wichtige Entscheidungen und Aktionen sollten beim Sammeln der Anforderungen sind:

• Klären der Besitzer*innen der Lösungsplanung: Stellen Sie für jede Lösung sicher, dass die Rollen und Zuständigkeiten für das Projektteam klar sind.
• Klären Sie den Geltungsbereich der Lösung: Der Geltungsbereich der Lösung sollte bereits im Rahmen der taktischen BI-Planung dokumentiert werden. Möglicherweise müssen Sie zusätzliche Zeit und Arbeit aufwenden, um den Geltungsbereich zu verdeutlichen, bevor Sie mit der Lösungsplanung beginnen.
• Identifizieren und Informieren von Projektbeteiligten: Identifizieren Sie die Projektbeteiligten für Geschäftsentwürfe und technische Entwürfe. Informieren Sie sie im Voraus über das Projekt, und erläutern Sie den Geltungsbereich, die Ziele, die erforderliche Zeit und die Ergebnisse des Geschäftsentwurfs.
• Planen und Durchführen von Geschäftsentwurfssitzungen: Moderieren Sie die Geschäftsentwurfssitzungen, um Informationen von Projektbeteiligten und Geschäftsbenutzer*innen zu erhalten. Fordern Sie die Benutzer*innen auf zu veranschaulichen, wie sie vorhandene Lösungen verwenden.
• Dokumentieren von Geschäftsmetriken und -attributen: Erstellen Sie mithilfe vorhandener Lösungen und der Informationen von den Projektbeteiligten eine Liste mit Geschäftsmetriken und -attributen. Ordnen Sie in den technischen Entwürfen die Felder der Datenquelle zu, und beschreiben Sie die Berechnungslogik für quantitative Felder.
• Entwerfen des Lösungsentwurfs: Erstellen Sie iterative Simulationen basierend auf den Vorgaben der Projektbeteiligten, die das erwartete Lösungsergebnis visuell widerspiegeln. Stellen Sie sicher, dass die Simulationen die geschäftlichen Anforderungen genau darstellen und erfüllen. Teilen Sie Geschäftsbenutzer*innen mit, dass die Simulationen während des technischen Entwurfs noch überprüft (und möglicherweise überarbeitet) werden müssen.
• Erstellen des Lösungsplans: Untersuchen Sie Quelldaten und relevante technische Aspekte, um sicherzustellen, dass der Geschäftsentwurf umsetzbar ist. Beschreiben Sie ggf. die wichtigsten Risiken und Gefahren für den Entwurf sowie alternative Ansätze. Bereiten Sie bei Bedarf eine Überarbeitung des Lösungsentwurfs vor, und besprechen Sie diese mit den Projektbeteiligten.
• Erstellen von Aufwandsschätzungen: Schätzen Sie im Rahmen des endgültigen Lösungsplans den Aufwand zum Erstellen und Unterstützen der Lösung. Begründen Sie diese Schätzungen mit den Informationen, die während der Sitzungen zum Geschäftsentwurf und zum technischen Entwurf gesammelt wurden.
• Festlegen der weiteren Vorgehensweise mit dem Plan: Um den Prozess der Anforderungssammlung abzuschließen, stellen Sie den Projektbeteiligten und Entscheidungsträger*innen den endgültigen Plan vor. Der Zweck dieser Besprechung besteht darin zu bestimmen, ob die Lösungsentwicklung fortgesetzt werden soll.

Schritt 2: Planen der Bereitstellung

Wenn das Projektteam mit dem Sammeln der Anforderungen und dem Erstellen des Lösungsplans fertig ist und die Genehmigung zum Fortfahren erhalten hat, kann es damit beginnen, die Lösungsbereitstellung zu planen.

Die Aufgabe zur Bereitstellungsplanung unterscheiden sich je nach Lösung, Entwicklungsworkflow und Bereitstellungsprozess. Ein Bereitstellungsplan bezieht sich in der Regel auf viele Aktivitäten im Zusammenhang mit der Planung und Einrichtung von Tools und Prozessen für die Lösung.

Planen der Vorgehensweise in wichtigen Bereichen

Das Projektteam sollte die wichtigsten Bereiche der Lösungsbereitstellung planen. In der Regel sollten bei der Planung die folgenden Bereiche berücksichtigt werden.

• Compliance: Stellen Sie sicher, dass alle während der Anforderungssammlung identifizierten Compliancekriterien durch spezifische Aktionen erfüllt werden. Weisen Sie jede dieser Aktionen bestimmten Personen zu, und definieren Sie den Zeitrahmen für die Fertigstellung unmissverständlich.
• Sicherheit: Entscheiden Sie, wie verschiedene Ebenen des Lösungszugriffs verwaltet werden und welche Anforderungen an die Datensicherheit erfüllt werden müssen. Überprüfen Sie, ob die Lösungssicherheit mehr oder weniger streng als bei Standardinhalten im Mandanten ist.
• Datengateways: Bewerten Sie, ob die Lösung ein Datengateway benötigt, um eine Verbindung mit Datenquellen herzustellen. Legen Sie fest, ob bestimmte Gatewayeinstellungen oder Hochverfügbarkeitscluster erforderlich sind. Planen Sie, wer Gatewayverbindungen über die Gatewaysicherheitsrollen verwalten kann und wie die Gateways überwacht werden. Weitere Informationen finden Sie unter Bereitstellen des Gatewayzugriffs.
• Arbeitsbereiche: Entscheiden Sie, wie Arbeitsbereiche eingerichtet und verwendet werden sollen. Legen Sie fest, ob die Lösung Lebenszyklusverwaltungstools wie Git-Integration und Bereitstellungspipelines erfordert und ob eine erweiterte Protokollierung mit Azure Log Analytics benötigt wird.
• Support: Legen Sie fest, wer für Support und Wartung der Lösung nach der Produktionsbereitstellung verantwortlich ist. Wenn die für den Support verantwortlichen Personen nicht dem Projektteam angehören, beziehen Sie diese Personen in die Entwicklung mit ein. Stellen Sie sicher, dass alle, die die Lösung unterstützen werden, den Lösungsentwurf verstehen und wissen, welches Problem behoben werden soll und wer die Lösung wie verwenden soll.
• Benutzerschulung: Planen Sie den Aufwand, der zum Schulen der Benutzercommunity erforderlich ist, damit sie die Lösung effektiv nutzen kann. Überlegen Sie, ob bestimmte Change Management-Aktionen erforderlich sind.
• Governance: Ermitteln Sie potenzielle Governancerisiken für die Lösung. Planen Sie den Aufwand, der erforderlich ist, um Benutzer*innen die effektive Verwendung der Lösung zu ermöglichen und gleichzeitig Governancerisiken zu minimieren (z. B. mithilfe von Vertraulichkeitsbezeichnungen und Richtlinien).

Durchführen der Ersteinrichtung

Das Projektteam sollte die anfängliche Einrichtung durchführen, um mit der Entwicklung zu beginnen. Anfängliche Einrichtungsaktivitäten können Folgendes umfassen:

• Anfängliche Tools und Prozesse: Führen Sie die erstmalige Einrichtung für alle neuen Tools und Prozesse durch, die für Entwicklung, Tests und Bereitstellung erforderlich sind.
• Identitäten und Anmeldeinformationen: Erstellen Sie Sicherheitsgruppen und Dienstprinzipale, die für den Zugriff auf Tools und Systeme verwendet werden. Speichern Sie die Anmeldeinformationen effektiv und sicher.
• Datengateways: Stellen Sie Datengateways für lokale Datenquellen (Gateways im Unternehmensmodus) oder Datenquellen in einem privaten Netzwerk (virtuelles Netzwerk oder VNet, Gateways) bereit.
• Arbeitsbereiche und Repositorys: Erstellen Sie Arbeitsbereiche und Remoterepositorys zum Veröffentlichen und Speichern von Inhalten, und richten Sie sie ein.

Hinweis

Die Bereitstellungsplanung hängt von der Lösung und Ihrem bevorzugten Workflow ab. In diesem Artikel werden nur allgemeine Planungselemente und Aktionen beschrieben.

Weitere Informationen zur Bereitstellungsplanung finden Sie unter Planen der Bereitstellung für die Migration zu Power BI.

Prüfliste: Die Planung der Lösungsbereitstellung umfasst folgende wichtige Entscheidungen und Aktionen:

• Planen wichtiger Bereiche: Planen Sie die Prozesse und Tools, die Sie benötigen, um Ihre Lösung erfolgreich zu entwickeln und bereitzustellen. Kümmern Sie sich sowohl um die technischen Aspekte (z. B. Datengateways oder Arbeitsbereiche) als auch um die Einführung (z. B. Benutzerschulungen und Governance).
• Durchführen der Ersteinrichtung: Richten Sie die Tools, Prozesse und Features ein, die Sie zum Entwickeln und Bereitstellen der Lösung benötigen. Dokumentieren Sie das Setup, um anderen zu helfen, die in Zukunft eine Ersteinrichtung durchführen müssen.
• Testen der Datenquellenverbindungen: Überprüfen Sie, ob die entsprechenden Komponenten und Prozesse vorhanden sind, um eine Verbindung mit den richtigen Daten herzustellen, damit Sie die Machbarkeitsstudie (Proof of Concept, PoC) starten können.

Schritt 3: Durchführen einer Machbarkeitsstudie

Das Projektteam führt eine Machbarkeitsstudie (Proof of Concept, PoC) für die Lösung durch, um ausstehende Annahmen zu überprüfen und frühzeitig Vorteile für Geschäftsbenutzer*innen zu demonstrieren. Ein PoC ist eine anfängliche Entwurfsimplementierung, die in Umfang und Ausgereiftheit Einschränkungen aufweist. Ein gut ausgeführter PoC ist besonders für große oder komplexe Lösungen wichtig, da er Komplexitäten (oder Ausnahmen) identifizieren und behandeln hilft, die im technischen Entwurf nicht erkannt wurden.

Es wird empfohlen, bei der Vorbereitung eines PoC die folgenden Überlegungen zu berücksichtigen.

• Ziele und Umfang: Beschreiben Sie den Zweck des Lösungs-PoC und die Funktionsbereiche, auf die er sich bezieht. Beispielsweise kann das Projektteam entscheiden, den PoC auf einen einzelnen Funktionsbereich oder bestimmte Anforderungen oder Features zu beschränken.
• Quelldaten: Legen Sie fest, welche Daten im PoC verwendet werden sollen. Je nach Lösung kann das Projektteam verschiedene Datentypen verwenden, z. B.:
  • Produktionsdaten (real)
  • Beispieldaten
  • Generierte Pseudodaten, die dem tatsächlichen Datenvolumen und der Komplexität in Produktionsumgebungen ähneln
• Demonstration: Beschreiben Sie, wie und wann das Projektteam den PoC den Projektbeteiligten und Benutzer*innen demonstrieren wird. Demonstrationen können während regelmäßiger Updates durchgeführt werden, oder wenn der PoC bestimmte Funktionskriterien erfüllt.
• Umgebung: Beschreiben Sie, wo das Projektteam den PoC erstellt. Ein guter Ansatz besteht darin, eine eigene Sandboxumgebung für den PoC zu verwenden und ihn in einer Entwicklungsumgebung bereitzustellen, wenn er bereit ist. Eine Sandboxumgebung bietet flexiblere Richtlinien und variable Inhalte und ermöglicht schnelle Ergebnisse. Im Gegensatz dazu umfasst eine Entwicklungsumgebung strukturiertere Prozesse, die die Zusammenarbeit ermöglichen. Der Schwerpunkt liegt hier eher auf der Ausführung bestimmter Aufgaben.
• Erfolgskriterien: Definieren Sie den Schwellenwert, ab dem der PoC als erfolgreich gilt und zur nächsten Iteration – der formalen Entwicklung – wechseln sollte. Vor dem Starten des PoC sollte das Projektteam klare Kriterien für den Erfolg des PoC festlegen. Wenn diese Kriterien im Voraus festgelegt werden, definiert das Projektteam, wann die PoC-Entwicklung endet und wann die nächsten Iterationszyklen für Entwicklung und Validierung beginnen. Abhängig von den Zielen des PoC kann das Projektteam verschiedene Erfolgskriterien festlegen, z. B.:
  • Genehmigung des PoC durch die Projektbeteiligten
  • Überprüfung von Features oder Funktionen
  • Positive Bewertung des PoC durch Peers nach einer festen Entwicklungszeit
• Fehler: Stellen Sie sicher, dass das Projektteam genau feststellen kann, wann der PoC als Misserfolg gilt. Die frühzeitige Identifizierung eines Misserfolgs hilft bei der Untersuchung der Grundursachen. Dies kann auch helfen, weitere Investitionen in eine Lösung zu vermeiden, die bei der Bereitstellung in der Produktion nicht wie erwartet funktionieren würde.

Achtung

Wenn das Projektteam den PoC durchführt, sollte es die Annahmen und Einschränkungen genau im Blick behalten. Beispielsweise kann das Projektteam die Leistung der Lösung und die Datenqualität nicht einfach mithilfe eines kleinen Datensatzes testen. Stellen Sie außerdem sicher, dass der Umfang und Zweck des PoC für die Geschäftsbenutzer*innen klar ist. Teilen Sie allen mit, dass der PoC nur eine erste Iteration ist, und heben Sie hervor, dass es sich nicht um eine Produktionslösung handelt.

Hinweis

Weitere Informationen finden Sie unter Durchführen eines Proof-of-Concept für die Migration zu Power BI.

Prüfliste: Beim Erstellen eines PoC sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Definieren der Ziele: Stellen Sie sicher, dass die Ziele des PoC für alle beteiligten Personen klar sind.
• Definieren des Umfangs des PoC: Stellen Sie sicher, dass das Erstellen des PoC nicht zu viel Entwicklungsaufwand erfordert, aber dennoch den Mehrwert und den Lösungsentwurf veranschaulicht.
• Auswählen der verwendeten Daten: Identifizieren Sie die Quelldaten, die Sie zum Erstellen des PoC verwenden, und begründen Sie Ihre Entscheidung. Weisen Sie auch auf potenzielle Risiken und Einschränkungen hin.
• Festlegen von Zeitpunkt und Vorgehensweise für die Präsentation des PoC: Planen Sie die Präsentation des Fortschritts, indem Sie den PoC Entscheidungsträger*innen und Geschäftsbenutzer*innen vorführen.
• Kommunizieren des Endes des PoC: Stellen Sie sicher, dass das Projektteam ein klares Ende für den PoC festlegt, und beschreiben Sie, wie er zu den formalen Entwicklungszyklen heraufgestuft wird.

Schritt 4: Erstellen und Überprüfen von Inhalten

Wenn der PoC erfolgreich ist, wechselt das Projektteam vom PoC zum Erstellen und Überprüfen von Inhalten. Das Projektteam kann die BI-Lösung in iterativen Entwicklungs- und Validierungszyklen entwickeln. Diese Zyklen bestehen aus iterativen Releases, bei denen das Projektteam Inhalte in einer Entwicklungsumgebung erstellt und in einer Testumgebung freigibt. Während der Entwicklung bindet das Projektteam schrittweise die Benutzercommunity in einem Pilotprozess mit einer frühen (Beta-)Versionen der Lösung in der Testumgebung ein.

Tipp

Die iterative Bereitstellung ermöglicht die frühzeitige Validierung und Feedback, um die Anzahl von späteren Änderungsanforderungen zu reduzieren, die Akzeptanz der Lösung fördern und schon vor dem Produktionsrelease Vorteile nutzbar machen zu können.

Die iterativen Entwicklungs- und Validierungszyklen werden fortgesetzt, bis das Projektteam zu einer vorab festgelegten Schlussfolgerung gelangt. In der Regel endet die Entwicklung, wenn es keine weiteren Features gibt, die implementiert werden müssen, und das Benutzerfeedback behandelt wurde. Wenn die Entwicklungs- und Validierungszyklen abgeschlossen sind, stellt das Projektteam den Inhalt mit dem endgültigen Produktionsrelease in einer Produktionsumgebung bereit.

Das folgende Diagramm zeigt, wie das Projektteam BI-Lösungen über Entwicklungs- und Validierungszyklen iterativ bereitstellen kann.

Das Diagramm zeigt die folgenden Schritte.

Element	Beschreibung
	Das Projektteam benachrichtigt die Benutzercommunity bei jedem Release und beschreibt Änderungen und neue Features. Im Idealfall enthalten die Benachrichtigungen eine Lösungsdemonstration und Q&A, damit die Benutzer erkennen können, was in dieser Version neu ist und Feedback geben können.
	Während der Überprüfung geben die Benutzer*innen Feedback zu einem zentralen Tool oder Formular. Das Projektteam sollte das Feedback regelmäßig überprüfen, um Probleme zu erkennen und Anfragen anzunehmen oder abzulehnen, und in anstehende Entwicklungsphasen einbeziehen.
	Das Projektteam überwacht die Verwendung der Lösung, um sich zu vergewissern, dass die Benutzer*innen sie wirklich testen. Wenn keine Verwendung erfolgt, sollte sich das Projektteam mit der Benutzercommunity in Verbindung setzen, um die Gründe zu verstehen. Eine geringe Nutzung kann darauf hindeuten, dass das Projektteam weitere Schritte zur Verbesserung der Akzeptanz sowie Change Management-Aktionen ausführen muss.
	Das Projektteam antwortet umgehend auf Benutzerfeedback. Wenn das Projektteam für die Beantwortung von Feedback benötigt, verlieren die Benutzer*innen möglicherweise schnell die Motivation für weiteres Feedback.
	Das Projektteam bezieht akzeptiertes Feedback in die weitere Lösungsplanung ein. Bei Bedarf überprüft es die Planungsprioritäten, um Aufgaben klarer zu machen und zu delegieren, bevor die nächste Entwicklungsphase beginnt.
	Das Projektteam setzt die Entwicklung der Lösung für das nächste Release fort.
	Das Projektteam führt alle Schritte aus, bis es zu einem vordefinierten Ergebnis gelangt und die Lösung für die Bereitstellung in der Produktion bereit ist.

In den folgenden Abschnitten werden wichtige Überlegungen zur Verwendung iterativer Entwicklungs- und Validierungszyklen zur Bereitstellung von BI-Lösungen beschrieben.

Inhalt erstellen

Das Projektteam entwickelt die Lösung nach seinem normalen Entwicklungsworkflow. Beim Erstellen von Inhalten sollte es jedoch die folgenden Punkte berücksichtigen.

• Während jedes Entwicklungszyklus muss die Dokumentation aktualisiert werden, um die Lösung zu beschreiben.
• Jeder Entwicklungszyklus wird mit einer Ankündigung an die Benutzercommunity abgeschlossen. Ankündigungen sollten im zentralen Portal veröffentlicht werden, und sie sollten kurze Beschreibungen der Änderungen und neuen Features in jedem Release enthalten.
• Bei jedem Release sollten nach Möglichkeit Sitzungen organisiert werden, um der Benutzercommunity Änderungen und neue Features zu demonstrieren und Fragen zu beantworten.
• Es muss genau definiert sein, wann iterative Entwicklungs- und Validierungszyklen abgeschlossen werden. Es muss einen klaren Prozess geben, mit dem die Lösung in der Produktionsumgebung bereitgestellt wird. Dies schließt auch den Übergang zu Support- und Einführungsaktivitäten ein.

Inhalt prüfen

Jeder iterative Entwicklungszyklus sollte mit einer Inhaltsüberprüfung enden. Für BI-Lösungen gibt es in der Regel zwei Typen von Überprüfungen.

• Entwicklerüberprüfung: Die Lösung wird von Inhaltsersteller*innen und Kolleg*innen getestet. Der Zweck der Entwicklerüberprüfung besteht darin, alle kritischen und sichtbaren Probleme zu ermitteln und zu beheben, bevor die Lösung Geschäftsbenutzern zur Verfügung gestellt wird. Probleme können sich auf die Richtigkeit der Daten, die Funktionalität oder die Benutzererfahrung beziehen. Im Idealfall werden Inhalte von Inhaltsersteller*innen überprüft, die sie nicht entwickelt haben.
• Benutzerüberprüfung: Die Lösung wird von der Benutzercommunity getestet. Das Ziel der Benutzerüberprüfung besteht darin, Feedback für spätere Iterationen zu sammeln und Probleme zu identifizieren, die von den Entwickler*innen nicht gefunden wurden. Formal wird der Zeitraum der Benutzerüberprüfung in der Regel als Benutzerakzeptanztest (User Acceptance Testing, UAT) bezeichnet.

Wichtig

Stellen Sie sicher, dass alle Probleme mit der Datenqualität während der Entwicklerüberprüfung (vor dem UAT) behoben werden. Diese Probleme können schnell das Vertrauen in die Lösung mindern und die langfristige Akzeptanz beeinträchtigen.

Tipp

Sie können während der Benutzerüberprüfung gelegentlich kurz mit wichtigen Benutzer*innen in Kontakt treten. Beobachten Sie sie, während sie die Lösung verwenden. Notieren Sie sich, was sie als schwierig zu verwenden finden oder welche Teile der Lösung nicht wie erwartet funktionieren. Mit diesem Ansatz können Sie sehr effektiv Feedback sammeln.

Berücksichtigen Sie die folgenden Überlegungen zur Überprüfung von Inhalten durch das Projektteam.

• Ermutigen zu Benutzerfeedback: Fordern Sie bei jedem Release Feedback an, und zeigen Sie, wie die Benutzer*innen dies effektiv abgeben können. Erwägen Sie, regelmäßig Beispiele für Feedback und Anfragen zu teilen, die zu aktuellen Änderungen und neuen Features geführt haben. Durch das Teilen solcher Beispiele zeigen Sie, dass Feedback angenommen und geschätzt wird.
• Isolieren größerer Anforderungen: Für einiges Feedback ist mehr Aufwand erforderlich. Stellen Sie sicher, dass das Projektteam dieses Feedback finden und darüber diskutieren kann, ob es implementiert wird. Erwägen Sie, größere Anforderungen zu dokumentieren, um sie in späteren Sitzungen zur taktischen Planung zu besprechen.
• Starten von Change Management-Aktivitäten: Schulen Sie Benutzer*innen in der Verwendung der Lösung. Konzentrieren Sie sich besonders auf neue Prozesse, neue Daten und abweichende Vorgehensweisen. Die Investition in ein Change Management wirkt sich langfristig positiv auf die Lösungsakzeptanz aus.

Wenn die Lösung einen vordefinierten Grad an Vollständigkeit und Ausgereiftheit erreicht, kann das Projektteam sie in der Produktion bereitstellen. Nach der Bereitstellung ändern sich die Aufgaben des Projektteams von der iterativen Bereitstellung zu Support und Überwachung der Lösung in der Produktion.

Hinweis

Entwicklung und Tests (Dev/Test) unterscheiden sich je nach Lösung und bevorzugtem Workflow.

In diesem Artikel werden nur allgemeine Planungselemente und Aktionen beschrieben. Weitere Informationen zu iterativen Entwicklungs- und Testzyklen finden Sie unter Erstellen von Inhalten für die Migration zu Power BI.

Prüfliste: Folgende Entscheidungen und Aktionen sind beim Erstellen und Überprüfen von Inhalten besonders wichtig:

• Iterativer Prozess zum Planen und Zuweisen von Aufgaben: Planen Sie Aufgaben für jedes Release der Lösung, und weisen Sie sie zu. Stellen Sie sicher, dass der Prozess zum Planen und Zuweisen von Aufgaben flexibel ist und Benutzerfeedback einschließt.
• Einrichten einer Lebenszyklusverwaltung für Inhalte: Nutzen Sie Tools und Prozesse, um die Bereitstellung und das Change Management von Lösungen zu optimieren und zu automatisieren.
• Erstellen eines Tools zum Zentralisieren von Feedback: Automatisieren Sie die Feedbacksammlung mithilfe einer Lösung, die für Sie und Ihre Benutzer*innen einfach zu verwenden ist. Erstellen Sie ein einfaches Formular, damit dass Feedback präzise, aber umsetzbar ist.
• Planen einer Besprechung von Feedback: Nutzen Sie Besprechungen, um neues oder ausstehendes Feedback kurz zu diskutieren. Entscheiden Sie dabei, ob das Feedback implementiert werden soll, wer für die Implementierung verantwortlich ist, und welche Maßnahmen zum Abschließen des Feedbacks ergriffen werden müssen.
• Festlegen des Abschlusses der iterativen Bereitstellung: Beschreiben Sie die Bedingungen für den Abschluss der iterativen Bereitstellungszyklen und den Zeitpunkt der Freigabe von Inhalten in der Produktionsumgebung.

Schritt 5: Bereitstellen, Unterstützen und Überwachen

Wenn das Projektteam fertig ist, stellt es die überprüfte Lösung in der Produktionsumgebung bereit. Das Projektteam sollte wichtige Einführungs- und Supportaktionen durchführen, um sicherzustellen, dass die Bereitstellung erfolgreich ist.

Um eine erfolgreiche Bereitstellung sicherzustellen, führen Sie die folgenden Support- und Einführungsaufgaben aus.

• Benachrichtigen über das endgültige Release: Die leitenden Sponsor*innen, Manager*innen oder andere Personen mit ausreichender Autorität und Vertrauenswürdigkeit sollten das Release in der Benutzercommunity ankündigen. Die Kommunikation sollte klar und präzise sein und Links zu den relevanten Lösungen und Supportkanälen enthalten.
• Durchführen von Schulungen für Inhaltsbenutzer*innen: Für Inhaltsbenutzer*innen sollten in den ersten Wochen nach der Veröffentlichung in der Produktion Schulungen verfügbar sein. Die Schulungen sollten sich auf das Erläutern des Lösungszwecks, das Beantworten von Benutzerfragen und das Demonstrieren der Verwendung der Lösung konzentrieren.
• Behandeln von Feedback und Anfragen: Erwägen Sie, Benutzer*innen einen Kanal zur Verfügung zu stellen, über den sie Feedback und Anfragen an das Projektteam übermitteln können. Stellen Sie sicher, dass angemessenes Feedback und angemessene Anforderungen während des Supportzeitraums nach der Bereitstellung besprochen und ggf. implementiert werden. Es ist wichtig, nach dem Produktionsrelease auf Feedback und Anforderungen zu reagieren. Damit zeigen Sie, dass an der Lösung aktiv gearbeitet und auf sich ändernde Geschäftsanforderungen reagiert wird.
• Planen des Austauschs mit der Benutzercommunity: Stellen Sie auch nach Ablauf des Supportzeitraums nach der Bereitstellung sicher, dass sich die Lösungsbesitzer*innen regelmäßig mit der Benutzercommunity austauschen. Diese Besprechungen sind wertvolle Quellen für Feedback und ermöglichen die Überarbeitung Ihrer BI-Strategie. Darüber hinaus fördern sie die Akzeptanz der Lösung, da die Benutzer*innen einbezogen werden.
• Übergabeaktionen: Die Mitglieder des Projektteams sind möglicherweise nicht für die Wartung der Lösung verantwortlich. In diesem Fall sollte das Team festlegen, wer verantwortlich ist, und die Übergabe durchführen. Die Übergabe sollte kurz nach der Veröffentlichung in der Produktion erfolgen und sowohl die Lösung als auch die Benutzercommunity umfassen.

Achtung

Eine ineffiziente Übergabe kann zu vermeidbaren Problemen mit dem Lösungssupport und der Akzeptanz während des Lebenszyklus führen.

Nach der Bereitstellung sollte das Projektteam planen, mit welcher Lösung im priorisierten Lösungsbacklog fortgefahren werden soll. Sammeln Sie ständig neues Feedback und neue Anfragen, und nehmen Sie ggf. Änderungen an der taktischen Planung vor – einschließlich des Lösungsbacklogs.

Prüfliste: Die Auswertung der Lösungsbereitstellung umfasst folgende wichtige Entscheidungen und Aktionen:

• Erstellen eines Kommunikationsplans: Planen Sie, wie Sie das Release, Schulungen und andere Support- oder Einführungsaktionen der Lösung kommunizieren. Stellen Sie sicher, dass alle Ausfälle oder Probleme innerhalb des Supportzeitraums nach der Bereitstellung kommuniziert und umgehend behoben werden.
• Umsetzen des Schulungsplans: Schulen Sie die Benutzer*innen in der Verwendung der Lösung. Stellen Sie sicher, dass die Schulungen auch noch mehrere Wochen nach der Veröffentlichung sowohl Live- als auch aufgezeichnete Schulungssitzungen bieten.
• Durchführen von Übergabeaktivitäten: Bereiten Sie bei Bedarf die Übergabe vom Entwicklungsteam an das Supportteam vor.
• Sprechzeiten für die Lösung: Erwägen Sie nach Ablauf des Supportzeitraums nach der Bereitstellung regelmäßige Sitzungen während der Geschäftszeiten abzuhalten, um Fragen zu beantworten und Feedback von Benutzer*innen zu sammeln.
• Einrichten eines fortlaufenden Verbesserungsprozesses: Planen Sie eine monatliche Überprüfung der Lösung, um potenzielle Änderungen oder Verbesserungen über einen Zeitraum zu überprüfen. Zentralisieren Sie das Benutzerfeedback, und überprüfen Sie es zwischen den Überwachungszeiten.

Zugehöriger Inhalt

Weitere Überlegungen, Aktionen, Entscheidungskriterien und Empfehlungen für Power BI-Implementierungsentscheidungen finden Sie unter Power BI-Implementierungsplanung.