Planowanie implementacji usługi Power BI: planowanie rozwiązań analizy biznesowej

Uwaga

Ten artykuł stanowi część serii artykułów dotyczących planowania implementacji usługi Power BI. Ta seria koncentruje się głównie na środowisku usługi Power BI w usłudze Microsoft Fabric. Aby zapoznać się z wprowadzeniem do serii, zobacz Planowanie implementacji usługi Power BI.

Ten artykuł ułatwia planowanie rozwiązań, które obsługują strategię analizy biznesowej (BI). Jest ona przeznaczona przede wszystkim na:

• Dyrektorzy analizy biznesowej i analitycy lub menedżerowie: osoby podejmujące decyzje odpowiedzialne za nadzorowanie programu analizy biznesowej i strategicznie ważnych rozwiązań analizy biznesowej.
• Centrum doskonałości (COE), dział IT i zespoły ds. analizy biznesowej: zespoły, które projektują i wdrażają rozwiązania analizy biznesowej dla przedsiębiorstw dla swojej organizacji.
• Eksperci z dziedziny (MŚP) i właściciele zawartości i twórcy: zespoły i osoby, które opowiadają się za analizą w dziale oraz projektują i wdrażają rozwiązania dla samoobsługowych, działów analizy biznesowej lub scenariuszy użycia analizy biznesowej zespołu.

Strategia analizy biznesowej to plan wdrożenia, używania i zarządzania danymi i analizami. Strategię analizy biznesowej można zdefiniować, zaczynając od planowania strategicznego analizy biznesowej. Planowanie strategiczne pomaga zidentyfikować obszary i cele analizy biznesowej. Aby określić ścieżkę postępu w kierunku celów analizy biznesowej, opisz konkretne kluczowe wyniki przy użyciu planowania taktycznego. Następnie uzyskasz postęp w kierunku tych kluczowych wyników, planując i wdrażając rozwiązania analizy biznesowej.

Uwaga

W ramach celów i kluczowych wyników (OKR) cele są jasne, ogólne opisy tego, co chcesz osiągnąć. Natomiast kluczowe wyniki są specyficzne, osiągalne wyniki w celu mierzenia postępu w kierunku jednego z celów.

Ponadto inicjatywy lub rozwiązania są procesami lub narzędziami utworzonymi w celu uzyskania co najmniej jednego kluczowego wyniku. Rozwiązania zaspokajają określone potrzeby użytkowników dotyczące danych. Rozwiązanie może przyjmować wiele form, takich jak potok danych, magazyn typu data lakehouse lub semantyczny model lub raport usługi Power BI.

Aby uzyskać więcej informacji na temat okr, zobacz Get to know OKRs (Microsoft Viva Goals).

Istnieje wiele podejść do planowania i implementowania rozwiązań analizy biznesowej. W tym artykule opisano jedno podejście, które można zastosować do planowania i implementowania rozwiązań analizy biznesowej, które obsługują strategię analizy biznesowej.

Poniższy diagram wysokiego poziomu przedstawia sposób przeprowadzania planowania rozwiązań analizy biznesowej.

Wykonaj następujące kroki, aby przeprowadzić planowanie rozwiązania analizy biznesowej.

Step	Opis
1	Zmontuj zespół projektu, który zbiera wymagania i definiuje projekt rozwiązania.
2	Zaplanuj wdrożenie rozwiązania, wykonując początkową konfigurację narzędzi i procesów.
3	Przeprowadź weryfikację koncepcji rozwiązania, aby zweryfikować założenia dotyczące projektu.
4	Tworzenie i weryfikowanie zawartości przy użyciu iteracyjnych cykli programowania i walidacji.
5	Wdrażanie, obsługa i monitorowanie rozwiązania po wydaniu go w środowisku produkcyjnym.

Uwaga

Planowanie rozwiązania analizy biznesowej dotyczy zarówno samoobsługowych projektów analizy biznesowej , jak i analizy biznesowej w przedsiębiorstwie.

Aby uzyskać więcej informacji, zobacz serię migracji usługi Power BI. Podczas gdy seria dotyczy migracji, kluczowe działania i zagadnienia są istotne dla planowania rozwiązania.

Krok 1. Zbieranie wymagań

Należy rozpocząć planowanie rozwiązań, najpierw zbierając wymagania i definiując projekt rozwiązania.

Uwaga: Planowanie strategiczne i taktyczne jest prowadzone przez zespół roboczy, który prowadzi inicjatywę. Z kolei planowanie rozwiązań jest prowadzone przez zespół projektu, który składa się z właścicieli zawartości i twórców.

Zebranie odpowiednich wymagań ma kluczowe znaczenie dla osiągnięcia pomyślnego wdrożenia i wdrożenia rozwiązania. Skutecznym sposobem zbierania wymagań jest zidentyfikowanie odpowiednich uczestników projektu, wspólne zdefiniowanie problemu i wykorzystanie tego wspólnego zrozumienia problemu w celu utworzenia projektu rozwiązania.

Poniżej przedstawiono niektóre korzyści wynikające z używania podejścia do współpracy w celu zebrania wymagań.

• Dane wejściowe użytkownika generują bardziej przydatne projekty: angażując użytkowników w ukierunkowane dyskusje w celu zbierania wymagań, można efektywniej przechwytywać potrzeby dotyczące danych biznesowych. Na przykład użytkownicy mogą pokazać twórcom zawartości, w jaki sposób korzystają z istniejących rozwiązań i przekazać opinię na temat postrzeganej skuteczności tych rozwiązań.
• Unikaj założeń i ograniczaj żądania zmian: dyskusje z użytkownikami często ujawniają niuanse, wyjątki i ukryte złożoności. Te szczegółowe informacje zmniejszają prawdopodobieństwo późnego etapu żądań, które mogą być kosztowne.
• Dołączanie użytkowników zwiększa wdrażanie rozwiązań: dzięki zaangażowaniu użytkowników w projektowanie i wczesne programowanie zapewniasz im możliwość wywierania wpływu na końcowy wynik. Zaangażowanie może również dać użytkownikom poczucie własności intelektualnej i odpowiedzialności za rozwiązanie. Bardzo zaangażowani użytkownicy będą bardziej skłonni do popularyzowania rozwiązania i prowadzić swoją społeczność praktyk w efektywnym używaniu tego rozwiązania.
• Projekty ustawiają oczekiwania dla uczestników projektu i użytkowników biznesowych: tworząc makiety lub ilustracje projektu rozwiązania, możesz wyraźnie pokazać uczestnikom projektu rozwiązania, jakie rozwiązanie będzie dostarczane. Pomaga to również poprzez wzajemne zrozumienie oczekiwanego wyniku projektu. Ten proces jest również znany jako myślenie projektowe i może być skutecznym sposobem podejścia i zrozumienia złożonych problemów.

Możesz podjąć różne podejścia, aby zaangażować użytkowników i zebrać wymagania. Można na przykład zebrać wymagania dotyczące projektowania biznesowego i projektu technicznego (opisane szczegółowo w kolejnych sekcjach tego artykułu).

Projektowanie biznesowe to podejście do zbierania wymagań biznesowych. Koncentruje się na angażowaniu użytkowników biznesowych w sesje projektowania biznesowego w celu wspólnego projektowania rozwiązania. Dane wyjściowe projektu biznesowego składają się z makiety rozwiązań i opisowej dokumentacji projektowej.

Projekt techniczny to podejście do tłumaczenia wymagań biznesowych na wymagania techniczne i reagowanie na założenia projektowe. Projekt techniczny koncentruje się na weryfikacji projektu biznesowego i zdefiniowaniu podejścia technicznego do użycia. Aby zweryfikować projekt, twórcy zawartości zazwyczaj angażują się z ekspertami technicznymi w ukierunkowanych dyskusjach nazywanych sesjami projektowania technicznego, w razie potrzeby.

Ważne

Zbieranie nieprawidłowych wymagań jest częstą przyczyną niepowodzenia implementacji. Często zespoły zbierają nieprawidłowe wymagania, ponieważ angażują się w niewłaściwe osoby biorące udział w projekcie, takich jak osoby podejmujące decyzje, które udostępniają żądania od góry do budowy rozwiązań.

Angażowanie użytkowników biznesowych przy użyciu metod współpracy, takich jak projekt biznesowy, może pomóc w zebraniu lepszych wymagań. Lepsze wymagania często prowadzą do bardziej wydajnego programowania i bardziej niezawodnych rozwiązań.

Uwaga

W przypadku niektórych zespołów przyjęcie ustrukturyzowanego procesu zbierania wymagań jest dużą zmianą. Upewnij się, że zarządzasz tą zmianą i że nie zakłóca ona planowania rozwiązania. Zalecamy znalezienie sposobów dostosowania tych podejść do dopasowania do sposobu działania zespołu.

Przygotowanie do planowania rozwiązania

Najpierw należy przygotować się do planowania rozwiązania, biorąc pod uwagę czynniki opisane w poniższych sekcjach.

• Zidentyfikuj, kto będzie prowadzić planowanie rozwiązań: w ramach planowania taktycznego analizy biznesowej zespół roboczy utworzył priorytetową listę prac rozwiązań. W planowaniu rozwiązań zespół projektu jest odpowiedzialny za projektowanie, opracowywanie i wdrażanie co najmniej jednego rozwiązania z listy prac. Dla każdego rozwiązania na liście prac należy utworzyć zespół projektu, który będzie odpowiedzialny za rozwiązanie. Oprócz planowania rozwiązania analizy biznesowej zespół projektu powinien:
  • Zdefiniuj osie czasu i punkty kontrolne na potrzeby planowania rozwiązania.
  • Zidentyfikuj odpowiednich uczestników projektu i zaangażuj odpowiednie osoby biorące udział w zbieraniu wymagań.
  • Skonfiguruj scentralizowaną lokalizację komunikacji, dokumentacji i planowania.
  • Angażowanie uczestników projektu w celu zebrania wymagań.
  • Komunikowanie się i koordynowanie z uczestnikami projektu i użytkownikami biznesowymi.
  • Organizowanie cykli iteracyjnych i testowych przy użyciu użytkowników biznesowych.
  • Dokumentowanie rozwiązania.
  • Dołączanie użytkowników do rozwiązania przez zdefiniowanie i wprowadzenie planu szkolenia.
  • Zapewnianie obsługi rozwiązań po wdrożeniu.
  • Rozwiąż uzasadnione żądania użytkowników dotyczące zmiany lub zaktualizowania rozwiązania po wdrożeniu.
  • W razie potrzeby przeprowadź przekazanie rozwiązania po wdrożeniu.
• Scentralizowana komunikacja i dokumentacja: ważne jest, aby zespół projektu centralizował komunikację i dokumentację dotyczącą planowania rozwiązań analizy biznesowej. Na przykład zespół projektu powinien scentralizować wymagania, komunikację uczestników projektu, osie czasu i elementy dostarczane. Rozważ przechowywanie całej dokumentacji w scentralizowanym portalu.
• Planowanie zbierania wymagań: zespół projektu powinien rozpocząć od zaplanowania sesji projektowania biznesowego w celu zebrania wymagań biznesowych. Te sesje mają formę interaktywnych spotkań i mogą być zgodne z podobnym formatem do strategicznych warsztatów planowania.

Napiwek

Rozważ zidentyfikowanie i zaangażowanie zespołów pomocy technicznej odpowiedzialnych za rozwiązanie na wczesnym etapie procesu zbierania wymagań. Aby efektywnie obsługiwać rozwiązanie, zespoły pomocy technicznej będą potrzebować kompleksowego zrozumienia rozwiązania, jego celu i użytkowników. Jest to szczególnie ważne, gdy zespół projektu składa się tylko z zewnętrznych konsultantów.

Zbieranie wymagań biznesowych

Zebranie odpowiednich wymagań biznesowych ma kluczowe znaczenie dla projektowania odpowiedniego rozwiązania. Aby zebrać odpowiednie wymagania i zdefiniować skuteczny projekt rozwiązania, zespół projektu może przeprowadzać sesje projektowe biznesowe razem z użytkownikami biznesowymi.

Celem sesji projektowania biznesowego jest:

• Potwierdź początkowy zakres rozwiązania.
• Zdefiniuj i zrozumiej problem, który powinien rozwiązać rozwiązanie.
• Zidentyfikuj odpowiednie kluczowe osoby biorące udział w rozwiązaniu.
• Zbierz odpowiednie wymagania biznesowe.
• Przygotuj projekt rozwiązania spełniający wymagania biznesowe.
• Przygotowanie pomocniczej dokumentacji projektowej.

Na poniższym diagramie przedstawiono sposób zbierania wymagań biznesowych i definiowania projektu rozwiązania przy użyciu podejścia do projektowania biznesowego.

Diagram przedstawia następujące kroki.

Produkt	Opis
	Zespół projektu rozpoczyna projektowanie biznesowe, potwierdzając zakres rozwiązania, który został po raz pierwszy udokumentowany w planowaniu taktycznym. Powinny one wyjaśnić obszary biznesowe, systemy i dane, które obejmie rozwiązanie.
	Zespół projektu identyfikuje kluczowych uczestników projektu ze społeczności użytkowników, którzy będą zaangażowani w sesje projektowania biznesowego. Najważniejsze osoby biorące udział w projekcie to użytkownicy mający wystarczającą wiedzę i wiarygodność do reprezentowania obszarów tematycznych rozwiązania.
	Zespół projektu planuje sesje projektowania biznesowego. Planowanie obejmuje informowanie uczestników projektu, organizowanie spotkań, przygotowywanie elementów dostarczanych i angażowanie się w użytkowników biznesowych.
	Zespół projektu zbiera i bada istniejące rozwiązania, których obecnie używają użytkownicy biznesowi w celu zaspokojenia istniejących potrzeb związanych z danymi biznesowymi. Aby przyspieszyć ten proces, zespół projektu może użyć odpowiednich badań z zakresu planowania strategicznego analizy biznesowej, który został udokumentowany w centrum komunikacji.
	Zespół projektu prowadzi sesje projektowe biznesowe z uczestnikami projektu. Te sesje to małe, interaktywne spotkania, w których zespół projektu poprowadzi uczestników projektu w celu zrozumienia potrzeb i wymagań dotyczących danych biznesowych.
	Zespół projektu podsumowuje projekt biznesowy, przedstawiając projekt rozwiązania projektowego uczestnikom projektu i innym użytkownikom w celu uzyskania opinii i zatwierdzenia. Projekt biznesowy jest pomyślny, gdy uczestnicy projektu zgadzają się, że projekt pomoże im osiągnąć cele biznesowe.

Projekt biznesowy kończy się następującymi elementami dostarczanymi.

• Projekty rozwiązań roboczych: Makiety, prototypy lub diagramy szkieletowe ilustrują projekt rozwiązania. Te dokumenty tłumaczą wymagania na konkretną strategię projektową.
• Lista metryk biznesowych: Pola ilościowe oczekiwane w rozwiązaniu, w tym definicje biznesowe i oczekiwane agregacje. Jeśli to możliwe, należy je sklasyfikować według ważności dla użytkowników.
• Lista atrybutów biznesowych: odpowiednie atrybuty i struktury danych oczekiwane w rozwiązaniu, w tym definicje biznesowe i nazwy atrybutów. Jeśli to możliwe, uwzględnij hierarchie i klasyfikuj atrybuty według ważności dla użytkowników.
• Dodatkowa dokumentacja: Opisy kluczowych wymagań funkcjonalnych lub wymagań dotyczących zgodności. Ta dokumentacja powinna być tak precyzyjna, jak to konieczne, ale tak zwięzła, jak to możliwe.

Elementy dostarczane projektu biznesowego są używane i weryfikowane przez projekt techniczny.

Napiwek

Makiety rozwiązań, prototypy lub diagramy szkieletowe mogą stworzyć jasne zrozumienie oczekiwanego wyniku, zarówno dla deweloperów, jak i użytkowników końcowych. Tworzenie skutecznych makiety nie wymaga umiejętności artystycznych ani talentów. Aby zilustrować projekt, możesz użyć prostych narzędzi, takich jak Microsoft Whiteboard, PowerPoint, a nawet tylko pióro i papier.

Zbieranie wymagań technicznych

Po zakończeniu projektowania biznesowego zespół projektu weryfikuje swoje wyniki przy użyciu projektu technicznego. Projekt techniczny jest podejściem podobnym do projektu biznesowego. Chociaż projekt biznesowy koncentruje się na potrzebach danych biznesowych, projekt techniczny koncentruje się na aspektach technicznych rozwiązania. Kluczowym wynikiem projektu technicznego jest plan rozwiązania, który opisuje ostateczny projekt rozwiązania i świadome oszacowania nakładu pracy na jego wdrożenie.

Uwaga

W przeciwieństwie do projektu biznesowego projekt techniczny jest w dużej mierze niezależnym badaniem danych źródłowych i systemów przeprowadzonych przez twórców zawartości i właścicieli.

Celem projektu technicznego jest:

• Zweryfikuj wyniki projektu biznesowego.
• Zająć się założeniami technicznymi w bieżącym projekcie.
• Zidentyfikuj odpowiednie źródła danych w zakresie i zdefiniuj obliczenia pól i mapowania źródła pól dla każdego źródła danych.
• Przetłumacz wymagania biznesowe na wymagania techniczne.
• Generowanie oszacowań nakładu pracy wymaganego do wdrożenia.

Zespół projektu angażuje uczestników projektu technicznych lub funkcjonalnych w ograniczonych, ukierunkowanych sesjach projektowych technicznych. Te sesje to interaktywne spotkania z osobami biorącymi udział w projekcie funkcjonalnym w celu zebrania wymagań technicznych. Osoby biorące udział w projekcie są odpowiedzialne za konkretne obszary funkcjonalne wymagane do efektywnego działania rozwiązania.

Przykłady uczestników projektu technicznego mogą być następujące:

• Zespoły ds. zabezpieczeń i sieci: Odpowiedzialne za zapewnienie bezpieczeństwa i zgodności danych.
• Zespoły funkcjonalne i stewardzy danych: odpowiedzialny za curowanie danych źródłowych.
• Architekci: właściciele określonych platform, narzędzi lub technologii.

Zespół projektu angażuje uczestników projektu w sesje projektowania technicznego, aby sprostać aspektom technicznym rozwiązania. Aspekty techniczne mogą obejmować:

• Połączenia ze źródłem danych: szczegółowe informacje o sposobie nawiązywania połączenia z źródłami danych i ich integrowania.
• Sieci i bramy danych: szczegółowe informacje o sieciach prywatnych lub lokalnych źródłach danych.
• Mapowanie źródła pól: mapowania danych metryk biznesowych i atrybutów na pola źródła danych.
• Logika obliczeń: tłumaczenie definicji biznesowych na obliczenia techniczne.
• Funkcje techniczne: funkcje lub funkcje potrzebne do obsługi wymagań biznesowych.

Napiwek

Zespół projektu, który przeprowadził projekt biznesowy, powinien również prowadzić projekt techniczny. Jednak ze względów praktycznych różne osoby mogą prowadzić projekt techniczny. W takim przypadku rozpocznij projekt techniczny, przeglądając wyniki projektu biznesowego.

W idealnym przypadku osoby prowadzące projekt techniczny powinny mieć dokładne zrozumienie wyników i użytkowników biznesowych.

Na poniższym diagramie przedstawiono sposób tłumaczenia wymagań biznesowych na wymagania techniczne przy użyciu projektu technicznego.

Diagram przedstawia następujące kroki.

Produkt	Opis
	Zespół projektu rozpoczyna projekt techniczny, definiując zakres źródła danych na podstawie wyników projektu biznesowego. Zakres źródła danych deklaruje, które dane są wymagane do utworzenia rozwiązania. Aby zidentyfikować odpowiednie źródła danych, zespół projektu skonsultuje się z firmowymi i funkcjonalnymi MŚP.
	Zespół projektu identyfikuje uczestników projektu technicznych lub funkcjonalnych w celu zaangażowania się w dalszej części sesji projektowych technicznych.
	Zespół projektu planuje ograniczone, ukierunkowane sesje z funkcjonalnymi uczestnikami projektu, aby rozwiązać aspekty techniczne rozwiązania. Planowanie obejmuje informowanie uczestników projektu, organizowanie spotkań i przygotowywanie elementów dostarczanych.
	Zespół projektu bada wymagania techniczne. Badania obejmują definiowanie obliczeń pól i mapowań źródeł danych, a także rozwiązywanie założeń dotyczących projektowania biznesowego przy użyciu analizy technicznej i dokumentacji.
	W razie potrzeby zespół projektu obejmuje uczestników sesji projektowania technicznego. Sesje koncentrują się na konkretnym, technicznym aspekcie rozwiązania, na przykład na połączeniach z zabezpieczeniami lub źródłami danych. W tych sesjach zespół projektu zbiera jakościowe opinie zainteresowanych stron i MŚP.
	Zespół projektu przygotowuje swoje ustalenia przy użyciu planu rozwiązania, który prezentuje uczestnikom projektu i osobom podejmującym decyzje. Plan jest iteracją i rozszerzeniem wyników projektowania biznesowego, które obejmują ostateczny projekt, szacowanie i inne elementy dostarczane.
	Projekt techniczny powinien zakończyć się ostatnim spotkaniem z uczestnikami projektu i decydentami, aby zdecydować, czy kontynuować. To spotkanie stanowi ostateczną okazję do oceny planowania rozwiązania, zanim zasoby zostaną zatwierdzone do opracowania rozwiązania.

Uwaga

Projekt techniczny może ujawnić nieoczekiwaną złożoność, która może sprawić, że planowanie rozwiązania będzie niewykonalne, biorąc pod uwagę bieżącą dostępność zasobów lub gotowość organizacji. W takim przypadku rozwiązanie powinno zostać ponownie zwalczone w kolejnym okresie planowania taktycznego. W zależności od pilności potrzeb związanych z danymi biznesowymi osoba podejmująca decyzje, na przykład sponsor wykonawczy, może nadal chcieć kontynuować weryfikację koncepcji lub tylko jedną część planowanego rozwiązania.

Projekt techniczny kończy się planem rozwiązania, który składa się z następujących elementów dostarczanych.

• Narzędzia i technologie: lista odpowiednich instrumentów technicznych potrzebnych do wdrożenia rozwiązania. Lista zawiera zazwyczaj odpowiednie nowe opcje licencji (takie jak pojemność sieci szkieletowej lub Premium na użytkownika), funkcje i narzędzia.
• Zdefiniowana lista metryk biznesowych: obliczenia i mapowania źródła pól metryk biznesowych dla wszystkich źródeł danych w zakresie. Aby utworzyć ten element dostarczany, zespół projektu używa listy metryk biznesowych utworzonych w projekcie biznesowym.
• Zdefiniowana lista atrybutów biznesowych: mapowania źródła pól atrybutów biznesowych dla wszystkich źródeł danych w zakresie. Aby utworzyć ten element dostarczany, zespół projektu używa listy atrybutów biznesowych utworzonych w projekcie biznesowym.
• Poprawione projekty: poprawki do projektu rozwiązania na podstawie zmian lub nieprawidłowych założeń dotyczących projektu biznesowego. Poprawione projekty są aktualizowane wersje makiety, prototypów lub diagramów szkieletowych opracowanych w projekcie biznesowym. Jeśli żadne poprawki nie są niezbędne, przekaż, że projekt techniczny weryfikuje projekt biznesowy.
• Szacowanie nakładu pracy: oszacowanie zasobów potrzebnych do opracowania, obsługi i utrzymania rozwiązania. Oszacowanie informuje ostateczną decyzję o tym, czy kontynuować wdrażanie rozwiązania, czy nie.

Ważne

Upewnij się, że zespół projektu powiadamia uczestników projektu o wszelkich zmianach lub nieoczekiwanych odkryciach z projektu technicznego. Te sesje projektowania technicznego powinny nadal obejmować odpowiednich użytkowników biznesowych. Upewnij się jednak, że zainteresowane strony nie są niepotrzebnie narażone na złożone informacje techniczne.

Napiwek

Ponieważ cele biznesowe niezmiennie ewoluują, oczekuje się, że wymagania się zmienią. Nie zakładaj, że wymagania dotyczące projektów analizy biznesowej są stałe. Jeśli masz problemy ze zmieniającymi się wymaganiami, może to oznaczać, że proces zbierania wymagań nie jest skuteczny lub że przepływy pracy deweloperów nie będą wystarczająco uwzględniać regularnych opinii.

Lista kontrolna — podczas zbierania wymagań kluczowe decyzje i akcje obejmują:

• Wyjaśnienie, kto jest właścicielem planowania rozwiązań: Dla każdego rozwiązania upewnij się, że role i obowiązki są jasne dla zespołu projektu.
• Wyjaśnienie zakresu rozwiązania: zakres rozwiązania powinien być już udokumentowany w ramach planowania taktycznego analizy biznesowej. Może być konieczne poświęcanie dodatkowego czasu i nakładu pracy, aby wyjaśnić zakres przed rozpoczęciem planowania rozwiązania.
• Identyfikowanie i informowanie uczestników projektu: Identyfikowanie uczestników projektu biznesowego i projektów technicznych. Poinformuj ich z wyprzedzeniem o projekcie i wyjaśnij zakres, cele, wymagane inwestycje czasowe i elementy dostarczane z projektu biznesowego.
• Planowanie i przeprowadzanie sesji projektowania biznesowego: Moderowanie sesji projektowania biznesowego w celu uzyskiwania informacji od uczestników projektu i użytkowników biznesowych. Poproś użytkowników o pokazanie sposobu korzystania z istniejących rozwiązań.
• Dokumentowanie metryk biznesowych i atrybutów: przy użyciu istniejących rozwiązań i danych wejściowych od uczestników projektu utwórz listę metryk biznesowych i atrybutów. W projektach technicznych zamapuj pola na źródło danych i opisz logikę obliczeń dla pól ilościowych.
• Projekt rozwiązania: utwórz iteracyjne makiety na podstawie danych wejściowych uczestników projektu, które wizualnie odzwierciedlają oczekiwany wynik rozwiązania. Upewnij się, że makiety dokładnie reprezentują i spełniają wymagania biznesowe. Poinformuj użytkowników biznesowych, że makiety muszą być nadal weryfikowane (i ewentualnie poprawione) podczas projektowania technicznego.
• Utwórz plan rozwiązania: Dane źródła badań i istotne zagadnienia techniczne, aby upewnić się, że projekt biznesowy jest osiągalny. W stosownych przypadkach opisz kluczowe zagrożenia i zagrożenia dla projektu oraz wszelkie alternatywne podejścia. W razie potrzeby przygotuj poprawkę projektu rozwiązania i porozmawiaj z uczestnikami projektu.
• Tworzenie oszacowań nakładu pracy: w ramach ostatecznego planu rozwiązania szacuj nakład pracy na tworzenie i obsługę rozwiązania. Wyjustuj te oszacowania przy użyciu informacji zebranych podczas sesji projektowania biznesowego i projektu technicznego.
• Zdecyduj, czy kontynuować planowanie: aby zakończyć proces zbierania wymagań, przedstawić ostateczny plan uczestnikom projektu i osobom podejmującym decyzje. Celem tego spotkania jest określenie, czy kontynuować opracowywanie rozwiązań.

Krok 2. Planowanie wdrożenia

Gdy zespół projektu zakończy zbieranie wymagań, utworzenie planu rozwiązania i otrzymanie zatwierdzenia, aby kontynuować, będzie gotowy do zaplanowana wdrożenia rozwiązania.

Zadania planowania wdrożenia różnią się w zależności od rozwiązania, przepływu pracy programowania i procesu wdrażania. Plan wdrożenia zazwyczaj dotyczy wielu działań związanych z planowaniem i konfigurowaniem narzędzi i procesów rozwiązania.

Planowanie rozwiązywania kluczowych obszarów

Zespół projektu powinien zaplanować kluczowe obszary wdrażania rozwiązań. Zazwyczaj planowanie powinno dotyczyć następujących obszarów.

• Zgodność: Upewnij się, że wszystkie kryteria zgodności zidentyfikowane w zbieraniu wymagań zostaną uwzględnione przez określone akcje. Przypisz każdą z tych akcji do określonych osób i jasno zdefiniuj przedział czasu dostarczania.
• Zabezpieczenia: zdecyduj, w jaki sposób będą zarządzane różne warstwy dostępu do rozwiązań oraz jakie są wymagania dotyczące reguł zabezpieczeń danych. Sprawdź, czy zabezpieczenia rozwiązania będą bardziej lub mniej rygorystyczne niż standardowa zawartość w dzierżawie.
• Bramy danych: oceń, czy rozwiązanie wymaga bramy danych w celu nawiązania połączenia ze źródłami danych. Określ, czy są wymagane określone ustawienia bramy czy klastry wysokiej dostępności. Zaplanuj, kto będzie mógł zarządzać połączeniami bramy za pośrednictwem ról zabezpieczeń bramy i jak monitorować bramy. Aby uzyskać więcej informacji, zobacz Provision gateway access (Aprowizuj dostęp do bramy).
• Obszary robocze: zdecyduj, jak skonfigurować obszary robocze i korzystać z nich. Ustal, czy rozwiązanie wymaga narzędzi do zarządzania cyklem życia, takich jak potoki integracji i wdrażania usługi Git, oraz czy wymaga zaawansowanego rejestrowania za pomocą usługi Azure Log Analytics.
• Pomoc techniczna: ustanów, kto jest odpowiedzialny za obsługę i konserwowanie rozwiązania po wdrożeniu produkcyjnym. Jeśli osoby odpowiedzialne za pomoc techniczną różnią się od zespołu projektu, zaangażuj te osoby w programowanie. Upewnij się, że kto będzie obsługiwał rozwiązanie, rozumie projekt rozwiązania, problem, który powinien rozwiązać, kto powinien go używać i jak.
• Szkolenie użytkowników: przewidywanie wysiłków potrzebnych do szkolenia społeczności użytkowników w celu efektywnego korzystania z rozwiązania. Zastanów się, czy są niezbędne jakiekolwiek konkretne akcje zarządzania zmianami.
• Ład: zidentyfikuj potencjalne zagrożenia związane z ładem dla rozwiązania. Przewidywanie nakładu pracy potrzebnego do umożliwienia użytkownikom efektywnego korzystania z rozwiązania przy jednoczesnym ograniczaniu ryzyka ładu (na przykład przy użyciu etykiet poufności i zasad).

Przeprowadzanie początkowej konfiguracji

Zespół projektu powinien wykonać wstępną konfigurację w celu rozpoczęcia opracowywania. Początkowe działania konfiguracji mogą obejmować:

• Początkowe narzędzia i procesy: wykonaj konfigurację po raz pierwszy dla nowych narzędzi i procesów potrzebnych do programowania, testowania i wdrażania.
• Tożsamości i poświadczenia: utwórz grupy zabezpieczeń i jednostki usługi, które będą używane do uzyskiwania dostępu do narzędzi i systemów. Efektywne i bezpieczne przechowywanie poświadczeń.
• Bramy danych:Wdróż bramy danych dla lokalnych źródeł danych (bram trybu przedsiębiorstwa) lub źródeł danych w sieci prywatnej (sieć wirtualna lub sieć wirtualna, bramy).
• Obszary robocze i repozytoria: tworzenie i konfigurowanie obszarów roboczych oraz repozytoriów zdalnych na potrzeby publikowania i przechowywania zawartości.

Uwaga

Planowanie wdrożenia różni się w zależności od rozwiązania i preferowanego przepływu pracy. W tym artykule opisano tylko ogólne elementy planowania i akcji.

Aby uzyskać więcej informacji na temat planowania wdrożenia, zobacz Planowanie wdrożenia w celu przeprowadzenia migracji do usługi Power BI.

Lista kontrolna — podczas planowania wdrożenia rozwiązania kluczowe decyzje i akcje obejmują:

• Planowanie kluczowych obszarów: Zaplanuj obsługę procesów i narzędzi, które należy pomyślnie opracować i wdrożyć rozwiązanie. Uwzględnij oba obszary techniczne (takie jak bramy danych lub obszary robocze), a także wdrożenie (takie jak szkolenie użytkowników i ład).
• Przeprowadzanie konfiguracji początkowej: ustanów narzędzia, procesy i funkcje, które należy opracować i wdrożyć rozwiązanie. Udokumentowanie konfiguracji w celu ułatwienia innym osobom, które będą musiały wykonać konfigurację po raz pierwszy w przyszłości.
• Przetestuj połączenia ze źródłem danych: sprawdź, czy odpowiednie składniki i procesy są na miejscu, aby nawiązać połączenie z odpowiednimi danymi, aby rozpocząć weryfikację koncepcji.

Krok 3. Przeprowadzanie weryfikacji koncepcji

Zespół projektu przeprowadza weryfikację koncepcji rozwiązania w celu zweryfikowania wybitnych założeń i wykazania wczesnych korzyści dla użytkowników biznesowych. Weryfikacja koncepcji to początkowa implementacja projektu, która jest ograniczona w zakresie i dojrzałości. Dobrze uruchomiona weryfikacja koncepcji jest szczególnie ważna w przypadku dużych lub złożonych rozwiązań, ponieważ może identyfikować i rozwiązywać problemy ze złożonością (lub wyjątkami), które nie zostały wykryte w projekcie technicznym.

Zalecamy uwzględnienie następujących zagadnień podczas przygotowywania weryfikacji koncepcji.

• Cele i zakres: Opisz przeznaczenie weryfikacji koncepcji rozwiązania i obszary funkcjonalne, które zajmie się. Na przykład zespół projektu może zdecydować się na ograniczenie weryfikacji koncepcji do jednego obszaru funkcjonalnego lub określonego zestawu wymagań lub funkcji.
• Dane źródłowe: zidentyfikuj, jakie dane będą używane w weryfikacji koncepcji. W zależności od rozwiązania zespół projektu może zdecydować się na użycie różnych typów danych, takich jak:
  • Dane produkcyjne (rzeczywiste)
  • Przykładowe dane
  • Wygenerowane syntetyczne dane przypominające rzeczywiste woluminy danych i złożoność obserwowane w środowiskach produkcyjnych
• Demonstracja: opisz, jak i kiedy zespół projektu przedstawi weryfikację koncepcji uczestnikom projektu i użytkownikom. Pokazy mogą być podane podczas regularnych aktualizacji lub gdy weryfikacja koncepcji spełnia określone kryteria funkcjonalne.
• Środowisko: opisz, gdzie zespół projektu utworzy weryfikację koncepcji. Dobrym rozwiązaniem jest użycie odrębnego środowiska piaskownicy dla weryfikacji koncepcji i wdrożenie go w środowisku projektowym, gdy będzie gotowe. Środowisko piaskownicy ma bardziej elastyczne zasady i płynną zawartość i koncentruje się na tworzeniu szybkich wyników. Natomiast środowisko deweloperskie jest zgodne z bardziej ustrukturyzowanymi procesami, które umożliwiają współpracę, i koncentruje się na wykonywaniu określonych zadań.
• Kryteria powodzenia: zdefiniuj próg dla momentu pomyślnego wykonania weryfikacji koncepcji i powinien przejść do następnej iteracji i wprowadzić formalny rozwój. Przed rozpoczęciem weryfikacji koncepcji zespół projektu powinien zidentyfikować jasne kryteria dotyczące pomyślnego wykonania weryfikacji koncepcji. Ustawiając te kryteria z wyprzedzeniem, zespół projektu definiuje, kiedy kończy się opracowywanie weryfikacji koncepcji i kiedy rozpoczyna się iteracyjne cykle programowania i walidacji. W zależności od celów weryfikacji koncepcji zespół projektu może ustawić różne kryteria sukcesu, takie jak:
  • Zatwierdzenie weryfikacji koncepcji przez uczestników projektu
  • Walidacja funkcji lub funkcjonalności
  • Korzystny przegląd weryfikacji koncepcji przez elementów równorzędnych po ustalonym czasie programowania
• Niepowodzenie: Upewnij się, że zespół projektu może zidentyfikować błąd weryfikacji koncepcji. Wczesne identyfikowanie awarii pomoże zbadać główne przyczyny. Może również pomóc uniknąć dalszych inwestycji w rozwiązanie, które nie będzie działać zgodnie z oczekiwaniami podczas wdrażania w środowisku produkcyjnym.

Uwaga

Gdy zespół projektu przeprowadzi weryfikację koncepcji, powinien zachować alert dotyczący założeń i ograniczeń. Na przykład zespół projektu nie może łatwo przetestować wydajności rozwiązania i jakości danych przy użyciu małego zestawu danych. Ponadto upewnij się, że zakres i cel weryfikacji koncepcji są jasne dla użytkowników biznesowych. Pamiętaj, aby poinformować, że weryfikacja koncepcji jest pierwszą iterację i podkreślić, że nie jest to rozwiązanie produkcyjne.

Uwaga

Aby uzyskać więcej informacji, zobacz Przeprowadzanie weryfikacji koncepcji migracji do usługi Power BI.

Lista kontrolna — podczas tworzenia weryfikacji koncepcji kluczowe decyzje i akcje obejmują:

• Zdefiniuj cele: Upewnij się, że cele weryfikacji koncepcji są jasne dla wszystkich zaangażowanych osób.
• Zdefiniuj zakres weryfikacji koncepcji: upewnij się, że utworzenie weryfikacji koncepcji nie wymaga zbyt dużego nakładu pracy programistycznej, a jednocześnie dostarcza wartość i demonstruje projekt rozwiązania.
• Zdecyduj, jakie dane będą używane: zidentyfikuj, jakie dane źródłowe będą używane do wykonania weryfikacji koncepcji, uzasadniając decyzję i przedstawiając potencjalne zagrożenia i ograniczenia.
• Zdecyduj, kiedy i jak przedstawić weryfikację koncepcji: Zaplanuj postęp, przedstawiając weryfikację koncepcji osobom podejmującym decyzje i użytkownikom biznesowym.
• Wyjaśnij, kiedy kończy się weryfikacja koncepcji: Upewnij się, że zespół projektu decyduje o wyraźnym zakończeniu weryfikacji koncepcji i opisz, jak będzie promowany do formalnych cykli rozwoju.

Krok 4. Tworzenie i weryfikowanie zawartości

Po pomyślnym zakończeniu weryfikacji koncepcji zespół projektu przechodzi z weryfikacji koncepcji do tworzenia i weryfikowania zawartości. Zespół projektu może opracować rozwiązanie analizy biznesowej przy użyciu iteracyjnych cykli programowania i walidacji. Te cykle składają się z wydań iteracyjnych, w których zespół projektu tworzy zawartość w środowisku projektowym i publikuje ją w środowisku testowym. Podczas opracowywania zespół projektu stopniowo dołącza społeczność użytkowników w procesie pilotażowym do wczesnych (beta) wersji rozwiązania w środowisku testowym.

Napiwek

Dostarczanie iteracyjne zachęca do wczesnej weryfikacji i opinii, które mogą ograniczać żądania zmian, promować wdrażanie rozwiązań i realizować korzyści przed wydaniem produkcyjnym.

Cykle iteracyjne i cykle weryfikacji będą kontynuowane do momentu, aż zespół projektu dotrze do wstępnie zdefiniowanego wniosku. Zazwyczaj programowanie kończy się, gdy nie ma więcej funkcji do zaimplementowania lub przesyłania opinii użytkowników w celu rozwiązania problemu. Po zakończeniu cyklu programowania i walidacji zespół projektu wdraża zawartość w środowisku produkcyjnym z ostateczną wersją produkcyjną.

Na poniższym diagramie przedstawiono, w jaki sposób zespół projektu może iteracyjnie dostarczać rozwiązania analizy biznesowej przy użyciu cykli programowania i walidacji.

Diagram przedstawia następujące kroki.

Produkt	Opis
	Zespół projektu komunikuje każdą wersję społeczności użytkowników, opisując zmiany i nowe funkcje. W idealnym przypadku komunikacja obejmuje pokaz rozwiązań i Q&A, dzięki czemu użytkownicy rozumieją, co nowego w wydaniu, i mogą przekazać słowne opinie.
	Podczas walidacji użytkownicy przekazują opinię za pośrednictwem centralnego narzędzia lub formularza. Zespół projektu powinien regularnie przeglądać opinie w celu rozwiązywania problemów, akceptowania lub odrzucania żądań oraz informowania o nadchodzących fazach programowania.
	Zespół projektu monitoruje użycie rozwiązania, aby potwierdzić, że użytkownicy ją testują. Jeśli nie ma żadnego użycia, zespół projektu powinien współpracować ze społecznością użytkowników, aby zrozumieć przyczyny tego problemu. Niskie użycie może wskazywać, że zespół projektu musi podjąć dalsze działania związane z włączaniem i zarządzaniem zmianami.
	Zespół projektu szybko odpowiada na opinie użytkowników. Jeśli zespół projektu zajmuje zbyt dużo czasu, aby zwrócić się do opinii, użytkownicy mogą szybko stracić motywację do jego udostępnienia.
	Zespół projektu uwzględnia zaakceptowane opinie dotyczące planowania rozwiązania. W razie potrzeby przejrzyją priorytety planowania, aby wyjaśnić i delegować zadania przed rozpoczęciem następnej fazy opracowywania.
	Zespół projektu kontynuuje opracowywanie rozwiązania dla następnej wersji.
	Zespół projektu iteruje wszystkie kroki do momentu osiągnięcia wstępnie zdefiniowanego wniosku, a rozwiązanie jest gotowe do wdrożenia produkcyjnego.

W poniższych sekcjach opisano kluczowe zagadnienia dotyczące używania iteracyjnych cykli programowania i walidacji w celu dostarczania rozwiązań analizy biznesowej.

Tworzenie zawartości

Zespół projektu opracowuje rozwiązanie, postępując zgodnie z normalnym przepływem pracy programowania. Należy jednak wziąć pod uwagę następujące kwestie podczas tworzenia zawartości.

• Podczas każdego cyklu programowania zaktualizuj dokumentację, aby opisać rozwiązanie.
• Zakończenie każdego cyklu programowania z ogłoszeniem dla społeczności użytkowników. Ogłoszenia powinny być publikowane w scentralizowanym portalu i powinny zawierać krótkie opisy zmian i nowych funkcji w każdej wersji.
• W każdej wersji rozważ zorganizowanie sesji, aby zademonstrować zmiany i nowe funkcje społeczności użytkowników oraz odpowiedzieć na wszelkie pytania słowne.
• Zdefiniuj, kiedy cykle iteracyjne i cykle weryfikacji zostaną zakończone. Upewnij się, że istnieje jasny proces wdrażania rozwiązania w środowisku produkcyjnym, w tym przejścia do działań związanych z obsługą i wdrażaniem.

Weryfikowanie zawartości

Każdy cykl programowania iteracyjnego powinien zakończyć się weryfikacją zawartości. W przypadku rozwiązań analizy biznesowej zwykle istnieją dwa rodzaje weryfikacji.

• Weryfikacja dla deweloperów: Testowanie rozwiązań odbywa się przez twórców zawartości i elementów równorzędnych. Celem weryfikacji dewelopera jest zidentyfikowanie i rozwiązanie wszystkich krytycznych i widocznych problemów przed udostępnieniem rozwiązania użytkownikom biznesowym. Problemy mogą dotyczyć poprawności danych, funkcjonalności lub środowiska użytkownika. W idealnym przypadku zawartość jest weryfikowana przez twórcę zawartości, który go nie opracował.
• Weryfikacja użytkownika: Testowanie rozwiązań odbywa się przez społeczność użytkowników. Celem weryfikacji użytkownika jest przekazanie opinii na potrzeby późniejszych iteracji oraz zidentyfikowanie problemów, które nie zostały znalezione przez deweloperów. Formalne okresy weryfikacji użytkownika są zwykle określane jako testy akceptacyjne użytkowników (UAT).

Ważne

Upewnij się, że wszystkie problemy z jakością danych zostały rozwiązane podczas walidacji dewelopera (przed UAT). Te problemy mogą szybko naruszyć zaufanie do rozwiązania i mogą zaszkodzić długoterminowemu wdrożeniu.

Napiwek

Podczas przeprowadzania weryfikacji użytkownika rozważ okazjonalne krótkie wywołania z kluczowymi użytkownikami. Obserwuj je podczas korzystania z rozwiązania. Zanotuj, czego trudno użyć, lub jakie części rozwiązania nie działają zgodnie z oczekiwaniami. Takie podejście może być skutecznym sposobem zbierania opinii.

Należy wziąć pod uwagę następujące kwestie, gdy zespół projektu weryfikuje zawartość.

• Zachęcaj użytkowników do przesyłania opinii: w każdej wersji poproś użytkowników o przekazanie opinii i pokaż, jak mogą to skutecznie zrobić. Rozważ regularne udostępnianie przykładów opinii i żądań, które doprowadziły do ostatnich zmian i nowych funkcji. Udostępniając przykłady, pokazujesz, że opinie są potwierdzane i doceniane.
• Izolowanie większych żądań: niektóre elementy opinii wymagają większego nakładu pracy w celu rozwiązania problemu. Upewnij się, że zespół projektu może zidentyfikować te elementy i omówić, czy zostaną one zaimplementowane, czy nie. Rozważ udokumentowanie większych żądań w celu omówienia w kolejnych taktycznych sesjach planowania .
• Rozpocznij działania związane z zarządzaniem zmianami: szkolenie użytkowników, jak korzystać z rozwiązania. Pamiętaj, aby poświęcić dodatkowy wysiłek na nowe procesy, nowe dane i różne sposoby pracy. Inwestowanie w zarządzanie zmianami ma pozytywny zwrot z długoterminowego wdrożenia rozwiązań.

Gdy rozwiązanie osiągnie wstępnie zdefiniowany poziom kompletności i dojrzałości, zespół projektu jest gotowy do wdrożenia go w środowisku produkcyjnym. Po wdrożeniu zespół projektu przechodzi od iteracyjnego dostarczania do obsługi i monitorowania rozwiązania produkcyjnego.

Uwaga

Programowanie i testowanie różni się w zależności od rozwiązania i preferowanego przepływu pracy.

W tym artykule opisano tylko ogólne elementy planowania i akcji. Aby uzyskać więcej informacji na temat iteracyjnych cykli tworzenia i testowania, zobacz Tworzenie zawartości do migracji do usługi Power BI.

Lista kontrolna — podczas tworzenia i weryfikowania zawartości kluczowe decyzje i akcje obejmują:

• Użyj iteracyjnego procesu, aby zaplanować i przypisać zadania: Planowanie i przypisywanie zadań dla każdej wersji rozwiązania. Upewnij się, że proces planowania i przypisywania zadań jest elastyczny i uwzględnia opinie użytkowników.
• Konfigurowanie zarządzania cyklem życia zawartości: użyj narzędzi i procesów, aby usprawnić i zautomatyzować wdrażanie rozwiązań oraz zarządzanie zmianami.
• Tworzenie narzędzia do scentralizowanego zbierania opinii: automatyzowanie zbierania opinii przy użyciu rozwiązania, które jest proste dla Ciebie i Twoich użytkowników. Utwórz prosty formularz, aby upewnić się, że opinie są zwięzłe, ale możliwe do wykonania.
• Zaplanuj spotkanie, aby przejrzeć opinię: Poznaj, aby krótko przejrzeć każdy nowy lub wybitny element opinii. Zdecyduj, czy zaimplementujesz opinię, czy nie, kto będzie odpowiedzialny za implementację, oraz jakie działania należy podjąć, aby zamknąć element opinii.
• Zdecyduj, kiedy kończy się iteracyjne dostarczanie: opisz warunki zakończenia iteracyjnych cykli dostarczania, a kiedy udostępnisz zawartość w środowisku produkcyjnym.

Krok 5. Wdrażanie, obsługa i monitorowanie

Gdy wszystko będzie gotowe, zespół projektu wdroży zweryfikowane rozwiązanie w środowisku produkcyjnym. Zespół projektu powinien podjąć kluczowe działania w zakresie wdrażania i pomocy technicznej, aby upewnić się, że wdrożenie zakończy się pomyślnie.

Aby zapewnić pomyślne wdrożenie, należy wykonać następujące zadania pomocy technicznej i wdrażania.

• Przekaż ostateczną wersję: Sponsor wykonawczy, menedżer lub inna osoba z wystarczającą władzą i wiarygodnością powinna ogłosić wydanie społeczności użytkowników. Komunikacja powinna być jasna, zwięzła i zawierać linki do odpowiednich rozwiązań i kanałów pomocy technicznej.
• Przeprowadzanie szkoleń dla użytkowników zawartości: szkolenie powinno być dostępne dla użytkowników zawartości w pierwszych tygodniach po wydaniu do środowiska produkcyjnego. Szkolenie powinno skupić się na wyjaśnieniu zakresu rozwiązania, odpowiadaniu na pytania użytkowników i wyjaśnianiu sposobu korzystania z rozwiązania.
• Wysyłanie opinii i żądań: rozważ udostępnienie użytkownikom kanału w celu przesłania opinii i żądań do zespołu projektu. Upewnij się, że omawiane są uzasadnione opinie i żądania oraz, w razie potrzeby, zaimplementowane w okresie wsparcia po wdrożeniu. Podejmowanie działań dotyczących opinii i żądań po wydaniu produkcyjnym jest ważne. Wskazuje to elastyczne rozwiązanie, które odpowiada na zmieniające się potrzeby biznesowe.
• Zaplanuj nawiązanie połączenia ze społecznością użytkowników: nawet po zakończeniu okresu wsparcia po wdrożeniu upewnij się, że właściciele rozwiązań regularnie spotykają się ze społecznością użytkowników. Te spotkania są cennymi źródłami opinii na temat zmiany strategii analizy biznesowej. Ponadto ułatwiają one obsługę wdrażania rozwiązań przez umożliwienie użytkownikom.
• Akcje przekazywania: członkowie zespołu projektu mogą nie być odpowiedzialni za utrzymanie rozwiązania. W takim przypadku zespół powinien określić, kto jest odpowiedzialny i wykonać przekazanie. Przekazanie powinno nastąpić wkrótce po wydaniu do środowiska produkcyjnego i powinno dotyczyć zarówno rozwiązania, jak i społeczności użytkowników.

Uwaga

Brak skutecznego przekazania może prowadzić do zapobiegania problemom z obsługą i wdrażaniem rozwiązań w trakcie jego cyklu życia.

Po wdrożeniu zespół projektu powinien zaplanować przejście do następnego rozwiązania na liście prac rozwiązania z priorytetem. Upewnij się, że zbierasz wszelkie nowe opinie i żądania oraz wprowadzasz poprawki do planowania taktycznego — w tym listy prac rozwiązania — w razie potrzeby.

Lista kontrolna — podczas rozważania wdrożenia rozwiązania kluczowe decyzje i akcje obejmują:

• Tworzenie planu komunikacji: Planowanie sposobu komunikowania się z wydaniem, szkoleniem i innymi akcjami pomocy technicznej lub wdrażania rozwiązań. Upewnij się, że wszelkie awarie lub problemy zostały przekazane i szybko rozwiązane w okresie wsparcia po wdrożeniu.
• Postępuj zgodnie z planem trenowania: szkolenie użytkowników w celu korzystania z rozwiązania. Upewnij się, że szkolenie obejmuje zarówno sesje szkoleniowe na żywo, jak i nagrane przez kilka tygodni po wydaniu.
• Przeprowadzanie działań przekazujących: w razie potrzeby przygotuj przekazanie od zespołu deweloperów zespołowi pomocy technicznej.
• Przeprowadzanie godzin pracy rozwiązania: po okresie wsparcia po wdrożeniu rozważ przeprowadzenie regularnych sesji godzin pracy, aby odpowiedzieć na pytania i zebrać opinie od użytkowników.
• Konfigurowanie procesu ciągłego ulepszania: zaplanuj miesięczny audyt rozwiązania, aby przejrzeć potencjalne zmiany lub ulepszenia w czasie. Scentralizowanie opinii użytkowników i okresowe przeglądanie opinii między inspekcjami.

Powiązana zawartość

Aby uzyskać więcej zagadnień, akcji, kryteriów podejmowania decyzji i zaleceń, które pomogą Ci w podejmowaniu decyzji dotyczących implementacji usługi Power BI, zobacz Planowanie implementacji usługi Power BI.