Power BI-Implementierungsplanung: BI-Lösungsplanung

Hinweis

Dieser Artikel ist Teil der Power BI-Implementierungsplanungsreihe von Artikeln. Die Serie konzentriert sich auf die Planung einer Power BI-Erfahrung in Microsoft Fabric. Weitere Informationen finden Sie in der Einführung der Reihe.

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 Analysedirektoren oder Manager: Entscheidungsträger, die für die Überwachung des BI-Programms und strategisch wichtige BI-Lösungen verantwortlich sind.
• Center of Excellence (COE), IT- und BI-Teams: Die Teams, die Enterprise BI-Lösungen für ihre Organisation entwerfen und bereitstellen.
• Fachexperten (SMEs) und Inhaltsbesitzer und Ersteller: Die Teams und Einzelpersonen, die Analysen in einer Abteilung durchführen und Lösungen für Self-Service-, Abteilungs-BI- oder Team BI-Nutzungsszenarien 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: Strategische und taktische Planung wird von einem Arbeitsteam geleitet, 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.

• Benutzereingaben erzeugen nützlichere Designs: Indem Sie Benutzer in fokussierten Diskussionen einbeziehen, um Anforderungen zu sammeln, können Sie Geschäftsdatenanforderungen 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 Sie Annahmen und mindern Sie Änderungsanforderungen: Diskussionen mit Benutzern zeigen häufig Nuancen, Ausnahmen und versteckte Komplexitäten an. Diese Erkenntnisse verringern die Wahrscheinlichkeit von Anforderungen in einer späteren Phase, die aufwendig zu behandeln sein können.
• Das Onboarding von Benutzern erhöht die Einführung von Lösungen: Durch die Einbeziehung von Benutzern in die Entwurfs- und frühe Entwicklung 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.
• Designs legen Erwartungen an Projektbeteiligte und Geschäftsbenutzer fest: Durch die Erstellung von Mockups oder Illustrationen des Lösungsdesigns können Sie den Projektbeteiligten klar zeigen, was die Lösung liefern 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 Sie, wer die Lösungsplanung durchführen wird: Im Rahmen der bi-taktischen Planung hat das Arbeitsteam einen priorisierten 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
• Zentrale 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 sie das Sammeln von Anforderungen: Das Projektteam sollte damit beginnen, die Geschäftsentwurfssitzungen zu planen, um geschäftliche Anforderungen zu erfassen. 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.

Gegenstand	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.

• Entwurf von Lösungsdesigns: Modelle, Prototypen oder Drahtmodelldiagramme veranschaulichen den Lösungsentwurf. Diese Dokumente übersetzen die Anforderungen in eine konkrete Entwurfsblaupause.
• Liste der Geschäftsmetriken: Quantitative Felder, die in der Lösung erwartet werden, einschließlich Geschäftsdefinitionen und erwartete Aggregationen. Wenn möglich, sollten Sie sie den Benutzer*innen nach Wichtigkeit sortiert vorlegen.
• Liste der Geschäftsattribute: 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.
• Ergänzende Dokumentation: Beschreibungen wichtiger funktionaler 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 Sicherheit und Compliance der Daten.
• Funktionale Teams und Data Stewards: Verantwortlich für die Zusammengestellt der Quelldaten.
• Architekten: Besitzer bestimmter Plattformen, Werkzeuge oder Technologie.

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 und Integrieren von Datenquellenverbindungen.
• Netzwerk- und Datengateways: Details zu privaten Netzwerken oder lokalen Datenquellen.
• Feldquellzuordnung: Datenzuordnungen von Geschäftsmetriken und Attributen zu Datenquellenfeldern.
• Berechnungslogik: Eine Übersetzung von Geschäftsdefinitionen in technische Berechnungen.
• Technische Features: Features oder Funktionen, die für die 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.

Gegenstand	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 Instrumente, 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 der Geschäftsmetriken: Berechnungen und Feldquellenzuordnungen der Geschäftsmetriken für alle In-Scope-Datenquellen. Für dieses Ergebnis verwendet das Projektteam die Liste der Geschäftsmetriken, die im Geschäftsentwurf erstellt wurde.
• Definierte Liste der Geschäftsattribute: Feldquellzuordnungen der Geschäftsattribute für alle In-Scope-Datenquellen. Für dieses Ergebnis verwendet das Projektteam die Liste der Geschäftsattribute, die im Geschäftsentwurf erstellt wurde.
• Überarbeitete Designs: Überarbeitungen des Lösungsdesigns basierend auf Änderungen oder ungültigen Annahmen über das Geschäftsdesign. Ü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ätzen Sie die ressourcen, die für die Entwicklung, Unterstützung und Wartung 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 Sie, wer die Lösungsplanung besitzt: Stellen Sie für jede Lösung sicher, dass Rollen und Zuständigkeiten für das Projektteam klar sind.
• Klären Sie den Lösungsbereich: Der Lösungsbereich sollte bereits im Rahmen der BI-taktischen 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 von Projektbeteiligten für Geschäftsdesigns und technische Designs. 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äftsbenutzern zu erhalten. Fordern Sie die Benutzer*innen auf zu veranschaulichen, wie sie vorhandene Lösungen verwenden.
• Dokumentieren Sie Geschäftsmetriken und -attribute: Erstellen Sie mithilfe vorhandener Lösungen und Eingaben von Projektbeteiligten eine Liste der Geschäftsmetriken und -attribute. Ordnen Sie in den technischen Entwürfen die Felder der Datenquelle zu, und beschreiben Sie die Berechnungslogik für quantitative Felder.
• Entwurf des Lösungsdesigns: Erstellen Sie iterative Modelle basierend auf Stakeholder-Eingaben, 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 Sie den Lösungsplan: Recherchieren Sie Quelldaten und relevante technische Überlegungen, um sicherzustellen, dass das Geschäftsdesign erreichbar 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 Sie Kostenschätzungen: Im Rahmen des endgültigen Lösungsplans schätzen Sie 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.
• Entscheiden Sie, ob sie mit dem Plan fortfahren möchten: Um den Prozess der Anforderungserfassung abzuschließen, stellen Sie den endgültigen Plan für die Projektbeteiligten und Entscheidungsträger 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 in der Anforderungserfassung identifizierten Compliancekriterien durch bestimmte 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 alle Anforderungen an die Datensicherheitsregel . Ü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. 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: Richten Sie nach der Produktionsbereitstellung ein, wer für die Unterstützung und Wartung der Lösung 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: Antizipieren Sie die erforderlichen Anstrengungen, um die Benutzercommunity zu schulen, damit sie die Lösung effektiv nutzen können. Überlegen Sie, ob bestimmte Change Management-Aktionen erforderlich sind.
• Governance: Identifizieren 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:

• Erste Tools und Prozesse: Führen Sie 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: Bereitstellen von Datengateways für lokale Datenquellen (Unternehmensmodusgateways) oder Datenquellen in einem privaten Netzwerk (virtuelles Netzwerk oder VNet, Gateways).
• Arbeitsbereiche und Repositorys: Erstellen und Einrichten von Arbeitsbereichen und Remoterepositorys zum Veröffentlichen und Speichern von Inhalten.

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 Sie wichtige Bereiche: Planen Sie die Prozesse und Tools, die Sie zum erfolgreichen Entwickeln und Bereitstellen Ihrer Lösung benötigen. 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).
• Erste Einrichtung durchführen: 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 von Datenquellenverbindungen: Überprüfen Sie, ob die entsprechenden Komponenten und Prozesse vorhanden sind, um eine Verbindung mit den richtigen Daten herzustellen, um den Machbarkeitsnachweis zu starten.

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 der Lösung POC und die Funktionalen Bereiche, die er adressieren wird. Beispielsweise kann das Projektteam entscheiden, den PoC auf einen einzelnen Funktionsbereich oder bestimmte Anforderungen oder Features zu beschränken.
• Quelldaten: Identifizieren Sie, 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, wie und wann das Projektteam die POC den Projektbeteiligten und Benutzern vorführen wird. Demonstrationen können während regelmäßiger Updates durchgeführt werden, oder wenn der PoC bestimmte Funktionskriterien erfüllt.
• Umgebung: Beschreiben, 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 wann der POC erfolgreich ist und zur nächsten Iteration übergeht, um in die formale Entwicklung einzutreten. 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 den Fehler des POC erkennen kann. 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 Sie die Ziele: Stellen Sie sicher, dass die Ziele des POC für alle Beteiligten klar sind.
• Definieren Sie den Umfang des POC: Stellen Sie sicher, dass das Erstellen des POC nicht zu viel Entwicklungsaufwand erfordert, während sie weiterhin Wert liefern und das Lösungsdesign demonstrieren.
• Entscheiden Sie, welche Daten verwendet werden sollen: Identifizieren Sie, welche Quelldaten Sie verwenden werden, um den PoC zu erstellen, ihre Entscheidung zu rechtfertigen und die potenziellen Risiken und Einschränkungen zu erklären.
• Entscheiden Sie, wann und wie sie die POC demonstrieren: Planen Sie den Fortschritt, indem Sie den POC entscheidungsträgern und Geschäftlichen Benutzern präsentieren.
• Klären Sie, wann der POC endet: Stellen Sie sicher, dass das Projektteam eine klare Schlussfolgerung für den POC zieht, und beschreiben Sie, wie es in formale Entwicklungszyklen überführt 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.

Gegenstand	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: Lösungstests werden von Inhaltserstellern und Peers durchgeführt. 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: Lösungstests werden von der Benutzercommunity durchgeführt. 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 Sie Benutzerfeedback: Fordern Sie mit jeder Version Benutzer feedback an, und zeigen Sie, wie sie dies effektiv tun 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 sie größere Anforderungen: Einige Feedbackelemente erfordern mehr Aufwand, um dies zu beheben. 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.
• Beginnen Sie mit Änderungsverwaltungsaktivitäten: Schulen Sie Benutzer, wie Sie die Lösung verwenden. 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:

• Verwenden Sie einen iterativen Prozess, um Aufgaben zu planen und zuzuweisen: Planen und Zuweisen von Aufgaben für jede Version der Lösung. Stellen Sie sicher, dass der Prozess zum Planen und Zuweisen von Aufgaben flexibel ist und Benutzerfeedback einschließt.
• Einrichten der Verwaltung des Inhaltslebenszyklus: Verwenden Sie Tools und Prozesse, um die Lösungsbereitstellung und Änderungsverwaltung zu optimieren und zu automatisieren.
• Erstellen Sie ein Tool, um Feedback zu zentralisieren: Automatisieren Sie die Feedbacksammlung mithilfe einer lösung, die für Sie und Ihre Benutzer einfach ist. Erstellen Sie ein einfaches Formular, damit dass Feedback präzise, aber umsetzbar ist.
• Planen Sie eine Besprechung, um Feedback zu überprüfen: Treffen Sie sich, um die einzelnen neuen oder ausstehenden Feedbackelemente kurz zu überprüfen. 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.
• Entscheiden Sie, wann die iterative Zustellung endet: Beschreiben Sie die Bedingungen für den Abschluss der iterativen Übermittlungszyklen, und wenn Sie Inhalte in die Produktionsumgebung freigeben.

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.

• Kommunizieren Sie die endgültige Version: Der Leitende Sponsor, ein Manager oder eine andere Person mit ausreichender Autorität und Glaubwürdigkeit sollte die Freigabe an die Benutzercommunity mitteilen. Die Kommunikation sollte klar und präzise sein und Links zu den relevanten Lösungen und Supportkanälen enthalten.
• Führen Sie Schulungen für Inhaltskonsumenten durch: Schulungen sollten während der ersten Wochen nach der Veröffentlichung in der Produktion für Inhaltskonsumenten 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.
• Adressieren sie Feedback und Anfragen: Stellen Sie Benutzern einen Kanal zur Verfügung, um Feedback und Anfragen an das Projektteam zu senden. 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 Sie die Verbindung mit der Benutzercommunity: Auch nach Ablauf des Supportzeitraums nach der Bereitstellung stellen Sie sicher, dass Lösungsbesitzer regelmäßig mit der Benutzercommunity zusammentreffen. 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: Mitglieder des Projektteams sind möglicherweise nicht für die Aufrechterhaltung 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 die Freigabe, Schulungen und andere Lösungsunterstützungs- oder Einführungsaktionen kommunizieren. Stellen Sie sicher, dass alle Ausfälle oder Probleme innerhalb des Supportzeitraums nach der Bereitstellung kommuniziert und umgehend behoben werden.
• Befolgen Sie einen Schulungsplan: Schulen Sie Benutzer für die 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 eine Übergabe vom Entwicklungsteam an das Supportteam vor.
• Durchführung von Lösungs-Office-Stunden: Nach dem Supportzeitraum nach der Bereitstellung sollten Sie regelmäßige Office-Stundensitzungen abhalten, um Fragen zu beantworten und Feedback von Benutzern zu sammeln.
• Richten Sie einen kontinuierlichen Verbesserungsprozess ein: Planen Sie eine monatliche Prüfung der Lösung, um potenzielle Änderungen oder Verbesserungen im Laufe der Zeit 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.