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

Nota

Este artigo faz parte da série de artigos de planejamento de implementação do Power BI. Esta série se concentra principalmente na experiência do Power BI no Microsoft Fabric. Para obter uma introdução à série, consulte Planejamento de implementação do Power 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.

Nota

Na estrutura de objetivos e resultados-chave (OKRs), os objetivos são descrições claras e de alto nível do que você deseja alcançar. Em contraste, os principais resultados são resultados específicos e alcançáveis para medir o progresso em direção a um de seus objetivos.

Além disso, iniciativas ou soluções são processos ou ferramentas criados para ajudá-lo a alcançar um ou mais resultados-chave. As soluções atendem às necessidades específicas de dados para os usuários. Uma solução pode assumir muitas formas, como um pipeline de dados, uma data lakehouse ou um modelo semântico ou relatório do Power BI.

Para obter mais informações sobre OKRs, consulte Conheça os OKRs (Microsoft Viva Goals).

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.

Passo	Descrição
1	Monte uma equipe de projeto que reúna os requisitos e defina o design da solução.
2	Planeje a implantação da solução executando a configuração inicial de ferramentas e processos.
3	Conduzir uma prova de conceito de solução (POC) para validar suposições sobre o projeto.
4	Crie e valide conteúdo usando ciclos iterativos de desenvolvimento e validação.
5	Implante, ofereça suporte e monitore a solução depois que ela for lançada no ambiente de produção.

Nota

O planejamento de soluções de BI aplica-se a projetos de BI de autoatendimento e de BI corporativo.

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.

Importante

Coletar os requisitos errados é uma razão comum pela qual as implementações falham. Muitas vezes, as equipes coletam os requisitos errados porque se envolveram com as partes interessadas erradas, como tomadores de decisão que fornecem solicitações de cima para baixo para que as soluções sejam construídas.

Envolver os usuários corporativos usando abordagens colaborativas, como um design de negócios, pode ajudá-lo a coletar melhores requisitos. Melhores requisitos conduzem frequentemente a um desenvolvimento mais eficiente e a soluções mais robustas.

Nota

Para algumas equipes, adotar um processo estruturado de levantamento de requisitos é uma grande mudança. Certifique-se de gerenciar essa alteração e que ela não interrompa o planejamento da solução. Recomendamos que você encontre maneiras de adaptar essas abordagens para se adequar à maneira como sua equipe trabalha.

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.

Gorjeta

Considere identificar e envolver as equipes de suporte responsáveis pela solução no início do processo de levantamento de requisitos. Para oferecer suporte eficaz à solução, as equipes de suporte precisarão de uma compreensão abrangente da solução, sua finalidade e os usuários. Isso é particularmente importante quando a equipe do projeto é composta apenas por consultores externos.

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.

Gorjeta

Maquetes de soluções, protótipos ou diagramas de wireframe podem criar uma compreensão clara do resultado esperado, tanto para desenvolvedores quanto para usuários finais. Criar maquetes eficazes não requer habilidade artística ou talento. Você pode usar ferramentas simples como Microsoft Whiteboard, PowerPoint ou até mesmo apenas uma caneta e papel para ilustrar o design.

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.

Nota

Ao contrário do design de negócios, o design técnico é em grande parte uma investigação independente sobre dados de origem e sistemas conduzidos por criadores e proprietários de conteúdo.

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.

Gorjeta

A equipe de projeto que conduziu o projeto de negócios também deve conduzir o projeto técnico. No entanto, por razões práticas, diferentes indivíduos podem liderar o projeto técnico. Neste caso, comece o projeto técnico revisando os resultados do projeto de negócios.

Idealmente, os indivíduos que lideram o projeto técnico devem ter uma compreensão completa dos resultados e dos usuários 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.

Nota

O projeto técnico pode revelar uma complexidade inesperada que pode inviabilizar o planejamento da solução, dada a disponibilidade atual de recursos ou a prontidão organizacional. Neste caso, a solução deve ser reavaliada no período de planeamento tático subsequente. Dependendo da urgência das necessidades de dados de negócios, um tomador de decisão, como o patrocinador executivo, ainda pode querer prosseguir com uma prova de conceito, ou apenas uma parte da solução planejada.

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.

Importante

Certifique-se de que a equipe do projeto notifique as partes interessadas sobre quaisquer alterações ou descobertas inesperadas do projeto técnico. Estas sessões de conceção técnica devem ainda envolver utilizadores empresariais relevantes. No entanto, certifique-se de que as partes interessadas não sejam desnecessariamente expostas a informações técnicas complexas.

Gorjeta

Como os objetivos de negócios invariavelmente evoluem, espera-se que os requisitos mudem. Não assuma que os requisitos para projetos de BI são fixos. Se você tiver dificuldades com a mudança de requisitos, isso pode ser uma indicação de que seu processo de coleta de requisitos não é eficaz ou que seus fluxos de trabalho de desenvolvimento não incorporam suficientemente feedback regular.

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

• Esclarecer quem é o proprietário do planejamento da solução: Para cada solução, certifique-se de que as funções e responsabilidades estejam claras para a equipe do projeto.
• Esclarecer o escopo da solução: O escopo da solução já deve ser documentado como parte do planejamento tático de BI. Talvez seja necessário gastar tempo e esforço adicionais para esclarecer o escopo antes de iniciar o planejamento da solução.
• Identificar e informar as partes interessadas: Identificar as partes interessadas para projetos de negócios e projetos técnicos. Informe-os com antecedência sobre o projeto e explique o escopo, os objetivos, o investimento de tempo necessário e as entregas do design do negócio.
• Planeje e conduza sessões de design de negócios: modere as sessões de design de negócios para obter informações das partes interessadas e usuários corporativos. Solicite que os usuários demonstrem como usam as soluções existentes.
• Documente métricas e atributos de negócios: usando soluções existentes e informações de partes interessadas, crie uma lista de métricas e atributos de negócios. Nos projetos técnicos, mapeie os campos para a fonte de dados e descreva a lógica de cálculo para campos quantitativos.
• Redigir o design da solução: crie modelos iterativos com base nas informações das partes interessadas que reflitam visualmente o resultado esperado da solução. Certifique-se de que os modelos representem e atendam com precisão aos requisitos de negócios. Comunicar aos utilizadores empresariais que as maquetas ainda têm de ser validadas (e possivelmente revistas) durante a conceção técnica.
• Crie o plano de solução: pesquise os dados de origem e as considerações técnicas relevantes para garantir que o design de negócios seja realizável. Se for caso disso, descrever os principais riscos e ameaças à conceção, bem como quaisquer abordagens alternativas. Se necessário, prepare uma revisão do design da solução e discuta-a com as partes interessadas.
• Criar estimativas de esforço: como parte do plano de solução final, estime o esforço para criar e dar suporte à solução. Justifique essas estimativas com as informações coletadas durante as sessões de design de negócios e design técnico.
• Decida se prossegue com o plano: Para concluir o processo de levantamento de requisitos, apresente o plano final às partes interessadas e aos decisores. O objetivo desta reunião é determinar se se deve prosseguir com o desenvolvimento da solução.

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.

Nota

O planejamento da implantação difere dependendo da solução e do seu fluxo de trabalho preferido. Este artigo descreve apenas o planejamento de alto nível e itens acionáveis.

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:

• Planeje as principais áreas: planeje abordar os processos e as ferramentas de que você precisa para desenvolver e implantar sua solução com sucesso. Aborde áreas técnicas (como gateways de dados ou espaços de trabalho) e também adoção (como treinamento de usuários e governança).
• Realizar a configuração inicial: estabeleça as ferramentas, os processos e os recursos necessários para desenvolver e implantar a solução. Documente a configuração para ajudar outras pessoas que precisarão fazer uma primeira configuração no futuro.
• Testar conexões de fonte de dados: valide se os componentes e processos apropriados estão em vigor para se conectar aos dados certos para iniciar a prova de conceito.

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.

Atenção

Quando a equipe do projeto conduz o POC, eles devem permanecer atentos a suposições e limitações. Por exemplo, a equipe do projeto não pode testar facilmente o desempenho da solução e a qualidade dos dados usando um pequeno conjunto de dados. Além disso, certifique-se de que o âmbito e a finalidade do POC são claros para os utilizadores empresariais. Certifique-se de comunicar que o POC é uma primeira iteração e ressalte que não é uma solução de produção.

Nota

Para obter mais informações, consulte Realizar prova de conceito para migrar para o Power BI.

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

• Definir os objetivos: Garantir que os objetivos do POC são claros para todas as pessoas que estão envolvidas.
• Defina o escopo do POC: Certifique-se de que a criação do POC não exigirá muito esforço de desenvolvimento, ao mesmo tempo em que entrega valor e demonstra o design da solução.
• Decida quais dados serão usados: identifique quais dados de origem você usará para fazer o POC, justificando sua decisão e descrevendo os potenciais riscos e limitações.
• Decida quando e como demonstrar o POC: Planeje mostrar o progresso apresentando o POC aos tomadores de decisão e usuários empresariais.
• Esclarecer quando o POC termina: Certifique-se de que a equipe do projeto decide sobre uma conclusão clara para o POC e descreva como ele será promovido para ciclos de desenvolvimento formais.

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.

Gorjeta

A entrega iterativa incentiva a validação antecipada e o feedback que podem mitigar solicitações de alteração, promover a adoção de soluções e obter benefícios antes do lançamento de produção.

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

Importante

Certifique-se de que quaisquer problemas de qualidade de dados sejam resolvidos durante a validação do desenvolvedor (antes do UAT). Estes problemas podem rapidamente minar a confiança na solução e podem prejudicar a adoção a longo prazo.

Gorjeta

Ao realizar a validação do usuário, considere chamadas curtas ocasionais com usuários-chave. Observe-os quando utilizarem a solução. Faça anotações sobre o que eles acham difícil de usar ou quais partes da solução não estão funcionando conforme o esperado. Esta abordagem pode ser uma forma eficaz de recolher feedback.

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.

Nota

O desenvolvimento e os testes diferem dependendo da solução e do seu fluxo de trabalho preferido.

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:

• Use um processo iterativo para planejar e atribuir tarefas: planeje e atribua tarefas para cada versão da solução. Certifique-se de que o processo para planejar e atribuir tarefas seja flexível e incorpore o feedback do usuário.
• Configurar o gerenciamento do ciclo de vida do conteúdo: use ferramentas e processos para simplificar e automatizar a implantação de soluções e o gerenciamento de alterações.
• Crie uma ferramenta para centralizar o feedback: automatize a coleta de feedback usando uma solução simples para você e seus usuários. Crie um formulário simples para garantir que o feedback seja conciso, mas acionável.
• Agende uma reunião para analisar comentários: reúna-se para analisar brevemente cada item de feedback novo ou pendente. Decida se você implementará o feedback ou não, quem será responsável pela implementação e quais ações tomar para fechar o item de feedback.
• Decida quando a entrega iterativa será concluída: descreva as condições para quando os ciclos de entrega iterativos serão concluídos e quando você liberará conteúdo para o ambiente de produção.

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.

Atenção

Não realizar uma transferência eficaz pode levar a problemas evitáveis com suporte e adoção de soluções durante seu ciclo de vida.

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:

• Crie um plano de comunicação: planeje como comunicar a versão, o treinamento e outras ações de suporte ou adoção da solução. Certifique-se de que quaisquer interrupções ou problemas sejam comunicados e prontamente resolvidos no período de suporte pós-implantação.
• Siga com um plano de treinamento: treine os usuários para usar a solução. Certifique-se de que o treinamento inclua sessões de treinamento ao vivo e gravadas por várias semanas após o lançamento.
• Realizar atividades de entrega: Se necessário, prepare uma transferência da equipe de desenvolvimento para a equipe de suporte.
• Conduza o horário de expediente da solução: após o período de suporte pós-implantação, considere a realização de sessões regulares de horário de expediente para responder a perguntas e coletar feedback dos usuários.
• Configure um processo de melhoria contínua: agende uma auditoria mensal da solução para analisar possíveis alterações ou melhorias ao longo do tempo. Centralize o feedback dos usuários e revise os comentários periodicamente entre as auditorias.

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.