Planejamento de implementação do Power BI: planejamento de solução de BI

Este artigo ajuda-o a planear soluções que suportam a sua estratégia de business intelligence (BI). Destina-se principalmente a:

• Diretores ou gerentes de BI e analytics: tomadores de decisão que são responsáveis por supervisionar o programa de BI e soluções de BI estrategicamente importantes.
• Equipes de Centro de Excelência (COE), TI e BI: as equipes que projetam e implantam soluções de BI empresarial para sua organização.
• Especialistas no assunto (PMEs) e proprietários e criadores de conteúdo: as equipes e indivíduos que defendem a análise em um departamento e projetam e implantam soluções para cenários de autoatendimento, BI departamental ou uso de BI de equipe.

Uma estratégia de BI é um plano para implementar, usar e gerenciar dados e análises. Você define sua estratégia de BI começando com o planejamento estratégico de BI. O planeamento estratégico ajuda-o a identificar as suas áreas de foco e objetivos de BI. Para determinar o caminho para progredir em direção aos seus objetivos de BI, você descreve os principais resultados específicos usando o planejamento tático. Em seguida, você alcança o progresso em direção a esses resultados-chave planejando e implantando soluções de BI.

Existem muitas abordagens para planear e implementar soluções de BI. Este artigo descreve uma abordagem que você pode adotar para planejar e implementar soluções de BI que suportem sua estratégia de BI.

O diagrama de alto nível a seguir descreve como conduzir o planejamento de soluções de BI.

Você executa as etapas a seguir para realizar o planejamento da solução de BI.

Para obter mais informações, consulte a série de migração do Power BI. Embora a série se preocupe com a migração, as principais ações e considerações são relevantes para o planejamento de soluções.

Etapa 1: reunir requisitos

Você começa o planejamento da solução primeiro reunindo os requisitos e definindo o design da solução.

Nota: O planeamento estratégico e tático é liderado por uma equipa de trabalho, que lidera a iniciativa. Em contraste, o planejamento da solução é liderado por uma equipe de projeto, que consiste em proprietários e criadores de conteúdo.

Reunir os requisitos certos é fundamental para alcançar a implantação e a adoção bem-sucedidas da solução. Uma maneira eficaz de reunir requisitos é identificar e envolver as partes interessadas certas, definir colaborativamente o problema a ser resolvido e usar essa compreensão compartilhada do problema para criar um design de solução.

Aqui estão alguns benefícios de usar uma abordagem colaborativa para reunir requisitos.

• A entrada do usuário produz designs mais úteis: ao envolver os usuários em discussões focadas para coletar requisitos, você pode capturar com mais eficiência as necessidades de dados corporativos. Por exemplo, os usuários podem demonstrar aos criadores de conteúdo como eles usam as soluções existentes e fornecer feedback sobre a eficácia percebida dessas soluções.
• Evite suposições e atenue solicitações de alteração: as discussões com os usuários geralmente revelam nuances, exceções e complexidades ocultas. Esses insights reduzem a probabilidade de solicitações em estágio avançado, que podem ser dispendiosas de resolver.
• A integração de usuários aumenta a adoção da solução: ao envolver os usuários no design e no desenvolvimento inicial, você oferece a eles uma oportunidade de influenciar o resultado final. O envolvimento também pode dar aos utilizadores um sentimento de propriedade intelectual e de responsabilidade pela solução. Usuários altamente envolvidos serão mais propensos a endossar a solução e liderar sua comunidade de prática em usá-la de forma eficaz.
• Os designs definem expectativas para as partes interessadas e os utilizadores empresariais: Ao produzir modelos ou ilustrações do design da solução, pode mostrar claramente às partes interessadas o que a solução irá proporcionar. Também ajuda ao criar uma compreensão mútua do resultado esperado do projeto. Esse processo também é conhecido como design thinking e pode ser uma maneira eficaz de abordar e entender problemas complexos.

Você pode adotar diferentes abordagens para envolver os usuários e reunir requisitos. Por exemplo, você pode reunir requisitos com design de negócios e design técnico (descritos em detalhes nas seções posteriores deste artigo).

O design de negócios é uma abordagem para reunir os requisitos de negócios. Ele se concentra em envolver usuários corporativos em sessões de design de negócios para projetar a solução de forma colaborativa. A saída de um design de negócios consiste em modelos de solução e documentação de design descritivo.

O design técnico é uma abordagem para traduzir os requisitos de negócios em requisitos técnicos e para abordar as suposições do projeto. Um projeto técnico se concentra em validar o design de negócios e definir uma abordagem técnica para uso. Para validar o design, os criadores de conteúdo normalmente se envolvem com especialistas técnicos em discussões focadas chamadas sessões de design técnico, quando necessário.

Prepare-se para o planejamento de soluções

Você deve primeiro se preparar para o planejamento da solução considerando os fatores descritos nas seções a seguir.

• Identificar quem conduzirá o planejamento da solução: Como parte do planejamento tático de BI, a equipe de trabalho criou um backlog priorizado de soluções. No planejamento de soluções, uma equipe de projeto é responsável por projetar, desenvolver e implantar uma ou mais soluções da lista de pendências. Para cada solução na lista de pendências, você deve montar uma equipe de projeto que será responsável pela solução. Além de executar o planejamento da solução de BI, a equipe do projeto deve:
  • Defina cronogramas e marcos para o planejamento de soluções.
  • Identificar e envolver as partes interessadas certas para a recolha de requisitos.
  • Configure um local centralizado para comunicação, documentação e planejamento.
  • Envolva as partes interessadas para reunir requisitos.
  • Comunicar e coordenar com as partes interessadas e utilizadores empresariais.
  • Orquestre ciclos iterativos de desenvolvimento e teste com usuários corporativos.
  • Documente a solução.
  • Integrar os utilizadores à solução, definindo e implementando um plano de formação.
  • Forneça suporte à solução pós-implantação.
  • Atenda a solicitações razoáveis do usuário para alterar ou atualizar a solução após a implantação.
  • Realize a entrega da solução após a implantação, se necessário.
• Centralize a comunicação e a documentação: É importante que a equipe de projeto centralize a comunicação e a documentação para o planejamento da solução de BI. Por exemplo, a equipe do projeto deve centralizar os requisitos, a comunicação com as partes interessadas, os cronogramas e as entregas. Considere armazenar toda a documentação em um portal centralizado.
• Planejar a coleta de requisitos: A equipe do projeto deve começar planejando as sessões de design de negócios para reunir os requisitos de negócios. Estas sessões assumem a forma de reuniões interativas e podem seguir um formato semelhante aos workshops de planeamento estratégico.

Reúna os requisitos de negócios

Reunir os requisitos de negócios certos é fundamental para projetar a solução certa. Para reunir os requisitos certos e definir um design de solução eficaz, a equipe de projeto pode conduzir sessões de design de negócios junto com os usuários corporativos.

O objetivo das sessões de design de negócios é:

• Confirme o escopo inicial da solução.
• Definir e compreender o problema que a solução deve abordar.
• Identifique as principais partes interessadas certas para a solução.
• Reúna os requisitos de negócios certos.
• Prepare um design de solução que atenda aos requisitos de negócios.
• Preparar documentação de projeto de suporte.

O diagrama a seguir mostra como reunir requisitos de negócios e definir o design da solução usando uma abordagem de design de negócios.

O diagrama descreve as etapas a seguir.

Item	Descrição
	A equipe de projeto começa o design de negócios confirmando o escopo da solução que foi documentado pela primeira vez no planejamento tático. Eles devem esclarecer as áreas de negócios, sistemas e dados que a solução abrangerá.
	A equipe do projeto identifica as principais partes interessadas da comunidade de usuários que estarão envolvidas nas sessões de design de negócios. As principais partes interessadas são utilizadores com conhecimentos e credibilidade suficientes para representar as áreas temáticas da solução.
	A equipe do projeto planeja sessões de design de negócios. O planejamento envolve informar as partes interessadas, organizar reuniões, preparar entregas e interagir com usuários corporativos.
	A equipe do projeto reúne e pesquisa as soluções existentes que os usuários corporativos usam atualmente para atender às necessidades de dados corporativos existentes. Para acelerar esse processo, a equipe do projeto pode usar pesquisas relevantes do planejamento estratégico de BI, que foi documentado no hub de comunicação.
	A equipa do projeto realiza sessões de design de negócios com as partes interessadas. Essas sessões são pequenas reuniões interativas, onde a equipe do projeto orienta as partes interessadas a entender as necessidades e os requisitos dos dados de negócios.
	A equipe do projeto conclui o design de negócios apresentando um projeto de solução preliminar às partes interessadas e outros usuários para feedback e aprovação. O design de negócios é bem-sucedido quando as partes interessadas concordam que o design irá ajudá-los a alcançar seus objetivos de negócios.

O design de negócios termina com os seguintes resultados.

• Projetos de solução de rascunho: maquetes, protótipos ou diagramas de wireframe ilustram o design da solução. Estes documentos traduzem os requisitos para um projeto concreto.
• Lista de métricas de negócios: campos quantitativos esperados na solução, incluindo definições de negócios e agregações esperadas. Se possível, classifique-os por importância para os usuários.
• Lista de atributos de negócios: atributos relevantes e estruturas de dados esperados na solução, incluindo definições de negócios e nomes de atributos. Se possível, inclua hierarquias e classifique os atributos por importância para os usuários.
• Documentação suplementar: Descrições dos principais requisitos funcionais ou de conformidade. Esta documentação deve ser tão precisa quanto necessário, mas tão concisa quanto possível.

Os produtos de design de negócios são usados e validados pelo projeto técnico.

Reunir requisitos técnicos

Depois de concluir o design do negócio, a equipe do projeto valida seus resultados usando um design técnico. O design técnico é uma abordagem semelhante ao design de negócios. Enquanto o design de negócios se concentra nas necessidades de dados de negócios, o design técnico se concentra nos aspetos técnicos de uma solução. Um resultado-chave do projeto técnico é o plano de solução, que descreve o projeto final da solução e estimativas informadas do esforço para implementá-lo.

O objetivo de um projeto técnico é:

• Validar os resultados do desenho do negócio.
• Aborde os pressupostos técnicos na conceção atual.
• Identifique as fontes de dados relevantes no escopo e defina os cálculos de campo e mapeamentos de fonte de campo para cada fonte de dados.
• Traduza os requisitos de negócios em requisitos técnicos.
• Produzir estimativas do esforço necessário para a implementação.

A equipa de projeto envolve as partes interessadas técnicas ou funcionais em sessões de projeto técnico limitadas e focadas. Estas sessões são reuniões interativas com as partes interessadas funcionais para reunir requisitos técnicos. As partes interessadas são responsáveis por áreas funcionais específicas necessárias para que a solução funcione de forma eficaz.

Exemplos de partes interessadas em um projeto técnico podem ser:

• Equipes de segurança e networking: Responsável por garantir a segurança e conformidade dos dados.
• Equipes funcionais e administradores de dados: Responsável pela curadoria dos dados de origem.
• Arquitetos: proprietários de plataformas, ferramentas ou tecnologias específicas.

A equipe de projeto envolve as partes interessadas em sessões de projeto técnico para abordar os aspetos técnicos da solução. Os aspetos técnicos podem incluir:

• Conexões de fonte de dados: detalhes sobre como se conectar e integrar fontes de dados.
• Rede e gateways de dados: detalhes sobre redes privadas ou fontes de dados locais.
• Mapeamento de fonte de campo: mapeamentos de dados de métricas de negócios e atributos para campos de fonte de dados.
• Lógica de cálculo: Tradução de definições de negócio para cálculos técnicos.
• Características técnicas: recursos ou funcionalidades necessárias para dar suporte aos requisitos de negócios.

O diagrama a seguir mostra como traduzir requisitos de negócios em requisitos técnicos usando um design técnico.

O diagrama descreve as etapas a seguir.

Item	Descrição
	A equipe de projeto inicia o projeto técnico definindo o escopo da fonte de dados com base nos resultados do design de negócios. O escopo da fonte de dados declara quais dados são necessários para criar a solução. Para identificar as fontes de dados corretas, a equipa do projeto consulta as empresas e as PME funcionais.
	A equipa do projeto identifica as partes interessadas técnicas ou funcionais para envolver mais tarde nas sessões de projeto técnico.
	A equipe do projeto planeja sessões limitadas e focadas com as partes interessadas funcionais para abordar os aspetos técnicos da solução. O planejamento envolve informar as partes interessadas, organizar reuniões e preparar resultados.
	A equipa do projeto pesquisa os requisitos técnicos. A pesquisa inclui a definição de cálculos de campo e mapeamentos de fontes de dados, e também abordar as suposições de projeto de negócios com análise técnica e documentação.
	Se necessário, a equipa de projeto envolve as partes interessadas em sessões de design técnico. As sessões se concentram em um aspeto técnico específico da solução, como segurança ou conexões de fonte de dados. Nestas sessões, a equipa do projeto recolhe feedback qualitativo das partes interessadas e das PME.
	A equipa do projeto prepara as suas conclusões utilizando um plano de solução, que apresenta às partes interessadas e aos decisores. O plano é uma iteração e extensão dos resultados do design de negócios que inclui o design final, estimativas e outros resultados.
	O projeto técnico deve terminar com uma reunião final com as partes interessadas e os tomadores de decisão para decidir se deve ou não prosseguir. Esta reunião oferece uma oportunidade final para avaliar o planejamento da solução antes que os recursos sejam comprometidos com o desenvolvimento da solução.

O projeto técnico termina com um plano de solução, que consiste nos seguintes resultados.

• Ferramentas e tecnologias: Lista dos instrumentos técnicos relevantes necessários para implementar a solução. A lista geralmente inclui novas opções de licença relevantes (como capacidade de malha ou Premium por usuário), recursos e ferramentas.
• Lista definida de métricas de negócios: cálculos e mapeamentos de origem de campo das métricas de negócios para todas as fontes de dados no escopo. Para produzir esse resultado final, a equipe do projeto usa a lista de métricas de negócios criadas no design do negócio.
• Lista definida de atributos de negócios: mapeamentos de origem de campo dos atributos de negócios para todas as fontes de dados no escopo. Para produzir esse resultado final, a equipe do projeto usa a lista de atributos de negócios criados no design de negócios.
• Projetos revisados: revisões do design da solução com base em alterações ou suposições inválidas sobre o design de negócios. Os designs revisados são versões atualizadas das maquetes, protótipos ou diagramas de wireframe produzidos no design de negócios. Se não forem necessárias revisões, comunique que o projeto técnico valida o projeto comercial.
• Estimativa de esforço: estimativa dos recursos necessários para desenvolver, apoiar e manter a solução. A estimativa informa a decisão final sobre se deve ou não prosseguir com a implementação da solução.

Lista de verificação - Ao reunir requisitos, as principais decisões e ações incluem:

Etapa 2: Planejar a implantação

Quando a equipe de projeto terminar de reunir requisitos, criar o plano de solução e receber aprovação para prosseguir, estará pronta para planejar a implantação da solução.

As tarefas de planejamento de implantação diferem dependendo da solução, do fluxo de trabalho de desenvolvimento e do processo de implantação. Um plano de implantação normalmente pertence a muitas atividades que envolvem o planejamento e a configuração de ferramentas e processos para a solução.

Planejar a abordagem de áreas-chave

A equipe do projeto deve planejar as principais áreas de implantação da solução. Normalmente, o planejamento deve abordar as seguintes áreas.

• Conformidade: Garantir que todos os critérios de conformidade identificados na coleta de requisitos serão abordados por ações específicas. Atribua cada uma dessas ações a pessoas específicas e defina claramente o prazo de entrega.
• Segurança: decida como as diferentes camadas de acesso à solução serão gerenciadas e quaisquer requisitos de regras de segurança de dados. Analise se a segurança da solução será mais ou menos rigorosa do que o conteúdo padrão no locatário.
• Gateways de dados: avalie se a solução precisa de um gateway de dados para se conectar a fontes de dados. Determine se configurações de gateway específicas ou clusters de alta disponibilidade são necessários. Planeje quem poderá gerenciar conexões de gateway por meio das funções de segurança de gateway e como monitorar os gateways. Para obter mais informações, consulte Provisionar acesso ao gateway.
• Espaços de trabalho: decida como configurar e usar espaços de trabalho. Determine se a solução requer ferramentas de gerenciamento de ciclo de vida, como pipelines de integração e implantação do Git, e se requer registro em log avançado com o Azure Log Analytics.
• Suporte: Estabeleça quem é responsável pelo suporte e manutenção da solução após a implantação da produção. Se os indivíduos responsáveis pelo apoio forem diferentes da equipa do projeto, envolva-os no desenvolvimento. Certifique-se de que quem vai apoiar a solução entende o design da solução, o problema que ela deve abordar, quem deve usá-la e como.
• Treinamento de usuários: antecipe os esforços necessários para treinar a comunidade de usuários para que eles possam usar efetivamente a solução. Considere se são necessárias ações específicas de gestão de alterações.
• Governança: Identifique quaisquer riscos potenciais de governança para a solução. Antecipe o esforço necessário para permitir que os usuários usem a solução de forma eficaz, ao mesmo tempo em que reduz qualquer risco de governança (por exemplo, usando rótulos e políticas de sensibilidade).

Conduzir a configuração inicial

A equipe do projeto deve realizar a configuração inicial para iniciar o desenvolvimento. As atividades iniciais de configuração podem incluir:

• Ferramentas e processos iniciais: execute a configuração inicial para quaisquer novas ferramentas e processos necessários para desenvolvimento, teste e implantação.
• Identidades e credenciais: crie grupos de segurança e entidades de serviço que serão usados para acessar ferramentas e sistemas. Armazene as credenciais de forma eficaz e segura.
• Gateways de dados:implante gateways de dados para fontes de dados locais (gateways de modo empresarial) ou fontes de dados em uma rede privada (gateways de rede virtual ou VNet).
• Espaços de trabalho e repositórios: crie e configure espaços de trabalho e repositórios remotos para publicação e armazenamento de conteúdo.

Para obter mais informações sobre planejamento de implantação, consulte Planejar a implantação para migrar para o Power BI.

Lista de verificação - Ao planejar a implantação da solução, as principais decisões e ações incluem:

Passo 3: Realizar uma prova de conceito

A equipe do projeto conduz uma prova de conceito de solução (POC) para validar suposições pendentes e demonstrar os primeiros benefícios para os usuários corporativos. Um POC é uma implementação de projeto inicial que é limitada em escopo e maturidade. Um POC bem executado é particularmente importante para soluções grandes ou complexas porque pode identificar e resolver complexidades (ou exceções) que não foram detetadas no projeto técnico.

Recomendamos considerar as seguintes considerações ao preparar um POC.

• Objetivos e escopo: Descreva o propósito do POC da solução e as áreas funcionais que ele abordará. Por exemplo, a equipe do projeto pode decidir limitar o POC a uma única área funcional ou a um conjunto específico de requisitos ou recursos.
• Dados de origem: Identificar quais dados serão usados no POC. Dependendo da solução, a equipe do projeto pode decidir usar diferentes tipos de dados, como:
  • Dados (reais) de produção
  • Dados de exemplo
  • Dados sintéticos gerados que se assemelham aos volumes de dados reais e à complexidade observada em ambientes de produção
• Demonstração: Descreva como e quando a equipe do projeto demonstrará o POC para as partes interessadas e usuários. As demonstrações podem ser dadas durante atualizações regulares ou quando o POC cumpre critérios funcionais específicos.
• Ambiente: Descreva onde a equipe do projeto construirá o POC. Uma boa abordagem é usar um ambiente de sandbox distinto para o POC e implantá-lo em um ambiente de desenvolvimento quando estiver pronto. Um ambiente de sandbox tem políticas mais flexíveis e conteúdo fluido, e é focado em produzir resultados rápidos. Em contraste, um ambiente de desenvolvimento segue processos mais estruturados que permitem a colaboração e se concentra na conclusão de tarefas específicas.
• Critérios de sucesso: Defina o limite para quando o POC é bem-sucedido e deve passar para a próxima iteração e entrar no desenvolvimento formal. Antes de iniciar o POC, a equipe do projeto deve identificar critérios claros para quando o POC é bem-sucedido. Ao definir esses critérios com antecedência, a equipe do projeto define quando o desenvolvimento do POC termina e quando os ciclos iterativos de desenvolvimento e validação começam. Dependendo dos objetivos do POC, a equipa do projeto pode definir diferentes critérios de sucesso, tais como:
  • Aprovação do POC pelas partes interessadas
  • Validação de características ou funcionalidades
  • Revisão favorável do POC pelos pares após um tempo de desenvolvimento fixo
• Falha: Garantir que a equipe do projeto possa identificar a falha do POC. A identificação precoce de falhas ajudará a investigar as causas profundas. Também pode ajudar a evitar mais investimentos em uma solução que não funcionará como esperado quando for implantada na produção.

Lista de verificação - Ao criar um POC, as principais decisões e ações incluem:

Etapa 4: Criar e validar conteúdo

Quando o POC é bem-sucedido, a equipe do projeto muda do POC para a criação e validação de conteúdo. A equipa de projeto pode desenvolver a solução de BI com ciclos iterativos de desenvolvimento e validação. Esses ciclos consistem em versões iterativas, onde a equipe do projeto cria conteúdo em um ambiente de desenvolvimento e o libera para um ambiente de teste. Durante o desenvolvimento, a equipe do projeto integra gradualmente a comunidade de usuários em um processo piloto para versões iniciais (beta) da solução no ambiente de teste.

Os ciclos iterativos de desenvolvimento e validação prosseguem até que a equipe do projeto chegue a uma conclusão predefinida. Normalmente, o desenvolvimento é concluído quando não há mais recursos para implementar ou feedback do usuário para abordar. Quando os ciclos de desenvolvimento e validação terminam, a equipe do projeto implanta o conteúdo em um ambiente de produção com a versão final de produção.

O diagrama a seguir mostra como a equipe de projeto pode entregar iterativamente soluções de BI com ciclos de desenvolvimento e validação.

O diagrama descreve as etapas a seguir.

Item	Descrição
	A equipe do projeto comunica cada versão à comunidade de usuários, descrevendo alterações e novos recursos. Idealmente, a comunicação inclui uma demonstração da solução e perguntas e respostas, para que os usuários entendam o que há de novo na versão e possam fornecer feedback verbal.
	Durante a validação, os utilizadores fornecem feedback através de uma ferramenta ou formulário central. A equipa do projeto deve rever os comentários regularmente para resolver problemas, aceitar ou rejeitar pedidos e informar as próximas fases de desenvolvimento.
	A equipe do projeto monitora o uso da solução para confirmar se os usuários estão testando-a. Se não houver qualquer uso, a equipe do projeto deve se envolver com a comunidade de usuários para entender os motivos. O baixo uso pode indicar que a equipe do projeto precisa tomar mais ações de capacitação e gerenciamento de alterações.
	A equipe do projeto responde prontamente ao feedback dos usuários. Se a equipe do projeto demorar muito para lidar com o feedback, os usuários podem perder rapidamente a motivação para fornecê-lo.
	A equipe do projeto incorpora o feedback aceito no planejamento da solução. Se necessário, eles revisam as prioridades de planejamento para esclarecer e delegar tarefas antes do início da próxima fase de desenvolvimento.
	A equipe do projeto continua o desenvolvimento da solução para a próxima versão.
	A equipe do projeto itera todas as etapas até chegar a uma conclusão predefinida e a solução estar pronta para implantação em produção.

As seções a seguir descrevem as principais considerações para usar ciclos iterativos de desenvolvimento e validação para fornecer soluções de BI.

Criar conteúdo

A equipa de projeto desenvolve a solução seguindo o seu fluxo de trabalho normal de desenvolvimento. No entanto, eles devem considerar os seguintes pontos ao criar conteúdo.

• Durante cada ciclo de desenvolvimento, atualize a documentação para descrever a solução.
• Conclua cada ciclo de desenvolvimento com um anúncio para a comunidade de usuários. Os anúncios devem ser postados no portal centralizado e devem fornecer breves descrições das alterações e novos recursos em cada versão.
• Com cada versão, considere organizar sessões para demonstrar mudanças e novos recursos para a comunidade de usuários e para responder a quaisquer perguntas verbais.
• Defina quando os ciclos iterativos de desenvolvimento e validação serão concluídos. Certifique-se de que haja um processo claro para implantar a solução no ambiente de produção, incluindo uma transição para atividades de suporte e adoção.

Validar conteúdo

Cada ciclo de desenvolvimento iterativo deve ser concluído com a validação de conteúdo. Para soluções de BI, normalmente existem dois tipos de validação.

• Validação do desenvolvedor: o teste da solução é feito por criadores de conteúdo e colegas. O objetivo da validação do desenvolvedor é identificar e resolver todos os problemas críticos e visíveis antes que a solução seja disponibilizada para usuários corporativos. Os problemas podem estar relacionados à correção de dados, à funcionalidade ou à experiência do usuário. O ideal é que o conteúdo seja validado por um criador de conteúdo que não o desenvolveu.
• Validação do usuário: o teste da solução é feito pela comunidade de usuários. O objetivo da validação do usuário é fornecer feedback para iterações posteriores e identificar problemas que não foram encontrados pelos desenvolvedores. Os períodos formais de validação do usuário são normalmente chamados de testes de aceitação do usuário (UAT).

Considere as seguintes considerações quando a equipe do projeto validar o conteúdo.

• Incentive o feedback dos usuários: a cada versão, solicite que os usuários forneçam feedback e demonstre como eles podem fazer isso de forma eficaz. Considere compartilhar regularmente exemplos de feedback e solicitações que levaram a alterações recentes e novos recursos. Ao partilhar exemplos, está a demonstrar que o feedback é reconhecido e valorizado.
• Isolar solicitações maiores: alguns itens de feedback exigem mais esforço para serem resolvidos. Certifique-se de que a equipe do projeto possa identificar esses itens e discutir se eles serão implementados ou não. Considere documentar solicitações maiores para discutir em sessões de planejamento tático posteriores.
• Comece as atividades de gerenciamento de mudanças: treine os usuários sobre como usar a solução. Certifique-se de gastar esforço extra em novos processos, novos dados e diferentes formas de trabalhar. Investir na gestão da mudança tem um retorno positivo na adoção de soluções a longo prazo.

Quando a solução atinge um nível predefinido de completude e maturidade, a equipe do projeto está pronta para implantá-la na produção. Após a implantação, a equipe de projeto faz a transição da entrega iterativa para o suporte e monitoramento da solução de produção.

Este artigo descreve apenas planejamento de alto nível e itens acionáveis. Para obter mais informações sobre ciclos iterativos de desenvolvimento e teste, consulte Criar conteúdo para migrar para o Power BI.

Lista de verificação - Ao criar e validar conteúdo, as principais decisões e ações incluem:

Etapa 5: Implantar, dar suporte e monitorar

Quando estiver pronta, a equipe de projeto implanta a solução validada no ambiente de produção. A equipe do projeto deve tomar as principais ações de adoção e suporte para garantir que a implantação seja bem-sucedida.

Para garantir uma implantação bem-sucedida, execute as seguintes tarefas de suporte e adoção.

• Comunicar a liberação final: O patrocinador executivo, um gerente ou outra pessoa com autoridade e credibilidade suficientes deve anunciar a liberação para a comunidade de usuários. A comunicação deve ser clara, concisa e incluir ligações para as soluções e canais de apoio relevantes.
• Realizar treinamentos para consumidores de conteúdo: o treinamento deve estar disponível para consumidores de conteúdo durante as primeiras semanas após o lançamento para produção. O treinamento deve se concentrar em esclarecer o escopo da solução, responder às perguntas dos usuários e explicar como usar a solução.
• Endereçar comentários e solicitações: considere fornecer aos usuários um canal para enviar comentários e solicitações à equipe do projeto. Assegurar que os comentários e pedidos razoáveis sejam discutidos e, quando adequado, implementados durante o período de apoio pós-implantação. Agir de acordo com feedback e solicitações após o lançamento da produção é importante. Indica uma solução ágil que responde às necessidades de negócio em mudança.
• Planeje se conectar com a comunidade de usuários: mesmo após o término do período de suporte pós-implantação, certifique-se de que os proprietários de soluções se reúnam regularmente com a comunidade de usuários. Estas reuniões são fontes valiosas de feedback para rever a sua estratégia de BI. Além disso, eles ajudam a dar suporte à adoção de soluções, permitindo que os usuários.
• Ações de transferência: os membros da equipe do projeto podem não ser responsáveis pela manutenção da solução. Neste caso, a equipe deve identificar quem é o responsável e realizar uma entrega. A entrega deve ocorrer logo após o lançamento para a produção, e deve abordar tanto a solução quanto a comunidade de usuários.

Após a implantação, a equipe do projeto deve planejar prosseguir para a próxima solução na lista de pendências da solução priorizada. Certifique-se de coletar novos comentários e solicitações e fazer revisões no planejamento tático, incluindo a lista de pendências da solução, se necessário.

Lista de verificação – Ao considerar a implantação da solução, as principais decisões e ações incluem:

Conteúdos relacionados

Para obter mais considerações, ações, critérios de tomada de decisão e recomendações para ajudá-lo com decisões de implementação do Power BI, consulte Planejamento de implementação do Power BI.