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

Observação

Este artigo faz parte da série de artigos sobre o Planejamento de implantação do Power BI. Esta série se concentra principalmente na experiência do Power BI no Microsoft Fabric. Para ter uma introdução a essa série, confira Planejamento de implementação do Power BI.

Esse artigo ajuda você a planejar soluções que dão suporte à sua estratégia de business intelligence (BI). Ele é voltado principalmente para:

• Diretores ou gerentes de BI e análise: tomadores de decisão responsáveis por supervisionar o programa de BI e soluções de BI estrategicamente importantes.
• Equipes do Centro de Excelência (COE), TI e BI: as equipes que projetam e implantam soluções corporativas de BI 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 uso de BI departamental ou equipe de BI.

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 um planejamento estratégico de BI. O planejamento estratégico ajuda você a identificar as á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 principais resultados planejando e implantando soluções de BI.

Observação

Na estrutura de objetivos e resultados principais (OKRs), objetivos são descrições claras e de alto nível do que você deseja alcançar. Em contraste, resultados principais 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 principais. As soluções atendem às necessidades específicas de dados dos usuários. Uma solução pode assumir várias formas, como um pipeline de dados, um data lakehouse ou um modelo semântico ou um relatório do Power BI.

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

Existem muitas abordagens para planejar e implementar soluções de BI. Esse artigo descreve uma abordagem que você pode adotar para planejar e implementar soluções de BI que oferecem suporte à sua estratégia de BI.

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

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

Step	Descrição
1	Monte uma equipe de projeto que reúna 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	Conduza uma prova de conceito (POC) de solução 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 liberada para o ambiente de produção.

Observação

O planejamento da solução de BI se aplica a projetos de BI de autoatendimento e BI corporativo.

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

Etapa 1: reunir requisitos

Você inicia o planejamento da solução primeiro reunindo requisitos e definindo o design da solução.

Nota: o planejamento estratégico e tático é liderado por uma equipe de trabalho, que lidera a iniciativa. Por outro lado, 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 opinião do usuário produz designs mais úteis: ao envolver os usuários em discussões focadas para coletar requisitos, você pode obter 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 comentários sobre a eficácia percebida dessas soluções.
• Evite suposições e reduza 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, o que pode ser caro de resolver.
• A integração de usuários aumenta a adoção de soluções: ao envolver os usuários no design e no desenvolvimento inicial, você oferece a eles a oportunidade de influenciar o resultado final. O envolvimento também pode dar aos usuários um senso de propriedade intelectual e responsabilidade para a solução. Usuários altamente envolvidos terão maior probabilidade de promover 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 usuários corporativos: ao produzir modelos ou ilustrações do design da solução, você pode mostrar claramente às partes interessadas o que a solução entregará. Ele também ajuda criando 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 em seções posteriores desse artigo).

O design de negócios é uma abordagem para reunir requisitos de negócios. Ele se concentra em envolver os usuários de negócios em sessões de design de negócios para projetar a solução de forma colaborativa. O resultado 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 atender às suposições de 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 geralmente 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 de negócios usando abordagens colaborativas, como um design de negócios, pode ajudar você a coletar requisitos melhores. Requisitos melhores geralmente levam a um desenvolvimento mais eficiente e a soluções mais robustas.

Observação

Para algumas equipes, adotar um processo estruturado de levantamento de requisitos é uma grande mudança. Certifique-se de gerenciar essa alteração e de 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 da solução

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

• Identifique 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 no backlog, 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:
  • Definir cronogramas e marcos para o planejamento da solução.
  • Identificar e envolver as partes interessadas certas para o levantamento de requisitos.
  • Configurar um local centralizado para comunicação, documentação e planejamento.
  • Envolva as partes interessadas para reunir requisitos.
  • Comunique-se e coordene-se com as partes interessadas e usuários de negócios.
  • Organizar ciclos iterativos de desenvolvimento e teste com usuários corporativos.
  • Documentar a solução.
  • Integre os usuários à solução definindo e implementando um plano de treinamento.
  • Fornecer suporte à solução pós-implantação.
  • Atenda às solicitações razoáveis do usuário para alterar ou atualizar a solução após a implantação.
  • Conduza 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 do 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 requisitos, comunicação com as partes interessadas, cronogramas e 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. Essas sessões assumem a forma de reuniões interativas e podem seguir um formato semelhante aos workshops de planejamento estratégico.

Dica

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 efetivo à solução, as equipes de suporte precisarão de uma compreensão abrangente da solução, de sua finalidade e dos usuários. Isso é particularmente importante quando a equipe do projeto é composta apenas por consultores externos.

Reunir 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 é:

• Confirmar o escopo inicial da solução.
• Definir e entender o problema que a solução deve abordar.
• Identificar as principais partes interessadas certas para a solução.
• Reunir os requisitos de negócios corretos.
• Preparar um design de solução que atenda aos requisitos de negócios.
• Preparar a documentação de design de suporte.

O diagrama a seguir descreve 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 seguintes etapas.

Item	Descrição
	A equipe do projeto inicia o design do negócio confirmando o escopo da solução que foi documentado pela primeira vez no planejamento tático. Ele devem esclarecer as áreas de negócios, sistemas e dados cobertos pela solução.
	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 usuários com conhecimento 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 os usuários de negócios.
	A equipe do projeto reúne e pesquisa 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 foram documentadas no hub de comunicação.
	A equipe do projeto realiza sessões de design de negócios com as partes interessadas. Essas sessões são pequenas reuniões interativas, nas quais a equipe do projeto orienta as partes interessadas a entender as necessidades e os requisitos de dados corporativos.
	A equipe do projeto conclui o design de negócios apresentando um projeto de solução preliminar para as partes interessadas e outros usuários para comentários e aprovação. O design de negócios é bem-sucedido quando as partes interessadas concordam que o design as ajudará a atingir seus objetivos de negócios.

O design do negócio é concluído com as seguintes entregas.

• Rascunho de designs de solução: maquetes, protótipos ou diagramas de wireframe ilustram o design da solução. Esses 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. Essa documentação deve ser muito precisa, mas muito concisa na medida do possível.

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

Dica

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 corporativos, o design técnico se concentra nos aspectos 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.

Observação

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 conduzida por criadores e proprietários de conteúdo.

O objetivo de um projeto técnico é:

• Validar os resultados do design do negócio.
• Abordar premissas técnicas no projeto atual.
• Identifique as fontes de dados relevantes no escopo e defina os cálculos de campo e os mapeamentos de fonte de campo para cada fonte de dados.
• Traduzir os requisitos de negócios em requisitos técnicos.
• Produzir estimativas do esforço necessário para a implementação.

A equipe do projeto envolve as partes interessadas técnicas ou funcionais em sessões de design técnico limitadas e focadas. Essas 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 rede: 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 do projeto envolve as partes interessadas em sessões de design técnico para abordar aspectos técnicos da solução. Os aspectos técnicos podem incluir:

• Conexões de fonte de dados: detalhes sobre como se conectar com e integrar fontes de dados.
• Rede e gateways de dados: detalhes sobre redes privadas ou fontes de dados locais.
• Mapeamento da 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: uma tradução de definições de negócios para cálculos técnicos.
• Recursos técnicos: recursos ou funcionalidades necessários para dar suporte aos requisitos de negócios.

Dica

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 design técnico. Nesse caso, inicie o projeto técnico revisando os resultados do design 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 descreve como converter requisitos de negócios em requisitos técnicos usando um design técnico.

O diagrama descreve as seguintes etapas.

Item	Descrição
	A equipe do projeto inicia o design 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 certas, a equipe do projeto consulta as PMEs empresariais e funcionais.
	A equipe do projeto identifica partes interessadas técnicas ou funcionais para envolver posteriormente nas sessões de design técnico.
	A equipe do projeto planeja sessões limitadas e focadas com partes interessadas funcionais para abordar aspectos técnicos da solução. O planejamento envolve informar as partes interessadas, organizar reuniões e preparar entregas.
	A equipe do projeto pesquisa requisitos técnicos. A pesquisa inclui a definição de cálculos de campo e mapeamentos de fontes de dados, além de abordar as premissas do projeto de negócios com análise técnica e documentação.
	Se necessário, a equipe do projeto envolve as partes interessadas em sessões de design técnico. As sessões se concentram em um aspecto técnico específico da solução, como segurança ou conexões de fonte de dados. Nessas sessões, a equipa do projeto recolhe comentários qualitativos das partes interessadas e das SMEs.
	A equipe do projeto prepara suas descobertas usando um plano de solução, que apresenta às partes interessadas e tomadores de decisão. 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 ser concluído com uma reunião final com as partes interessadas e tomadores de decisão para decidir se deve ou não prosseguir. Essa reunião fornece uma oportunidade final para avaliar o planejamento da solução antes que os recursos sejam comprometidos com o desenvolvimento da solução.

Observação

O design técnico pode revelar complexidade inesperada que pode tornar o planejamento da solução inviável, dada a disponibilidade de recursos atual ou a preparação organizacional. Nesse caso, a solução deve ser reavaliada no período de planejamento tático subsequente. Dependendo da urgência das necessidades de dados corporativos, um tomador de decisões, 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 é concluído 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 normalmente 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 produto final, a equipe do projeto usa a lista de métricas de negócios criada no design de negócios.
• 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, a equipe do projeto usa a lista de atributos de negócios criados no design de negócios.
• Designs revisados: revisões no 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 dos modelos ou protótipos de wireframe produzidos no design de negócios. Se nenhuma revisão for necessária, comunique que o projeto técnico valida o design comercial.
• Estimativa de esforço: estimativa dos recursos necessários para desenvolver, dar suporte e manter a solução. A estimativa informa a decisão final sobre prosseguir ou não 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. Essas sessões de design técnico ainda devem envolver usuários de negócios relevantes. No entanto, certifique-se de que as partes interessadas não sejam desnecessariamente expostas a informações técnicas complexas.

Dica

Como os objetivos de negócios invariavelmente evoluem, espera-se que os requisitos mudem. Não suponha que os requisitos para projetos de BI sejam corrigidos. Se você tiver dificuldades com a alteração dos requisitos, pode ser uma indicação de que o processo de coleta de requisitos não é eficaz ou que seus fluxos de trabalho de desenvolvimento não incorporam comentários regulares suficientemente.

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 estar documentado como parte do planejamento tático de BI. Talvez seja necessário gastar mais tempo e esforço 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, as metas, o investimento de tempo necessário e os resultados finais do design do negócio.
• Planejar e conduzir sessões de design de negócios: modere as sessões de design de negócios para obter informações das partes interessadas e dos 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 das partes interessadas, crie uma lista de métricas e atributos de negócios. Nos desenhos técnicos, mapeie os campos para a fonte de dados e descreva a lógica de cálculo para campos quantitativos.
• Rascunhe o design da solução: crie modelos iterativos com base na entrada das partes interessadas que reflitam visualmente o resultado esperado da solução. Certifique-se de que os modelos representem e atendam com precisão os requisitos de negócios. Comunique aos usuários corporativos que os modelos ainda devem ser validados (e possivelmente revisados) durante o design técnico.
• Crie o plano de solução: pesquise dados de origem e considerações técnicas relevantes para garantir que o design de negócios seja realizável. Quando relevante, descreva os principais riscos e ameaças ao projeto e 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 final da solução, 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 deseja prosseguir com o plano: para concluir o processo de levantamento de requisitos, apresente o plano final às partes interessadas e tomadores de decisão. O objetivo desta reunião é determinar se deve prosseguir com o desenvolvimento da solução.

Etapa 2: planejar a implantação

Quando a equipe do 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.

Planeje abordar áreas principais

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 no levantamento 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 regra 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 específicas de gateway ou clusters de alta disponibilidade são necessárias. Planeje quem poderá gerenciar conexões de gateway por meio das funções de segurança do 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 integração do Git e pipelines de implantação, e se requer log avançado com 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 suporte forem diferentes da equipe do projeto, envolva esses indivíduos no desenvolvimento. Certifique-se de que quem dará suporte à solução entenda 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 a solução com eficiência. Considere se alguma ação específica de gerenciamento de alterações é necessária.
• Governança: identifique eventuais riscos de governança para a solução. Antecipe o esforço necessário para permitir que os usuários usem efetivamente a solução e, ao mesmo tempo, reduza qualquer risco de governança (por exemplo, usando rótulos de confidencialidade e políticas).

Realizar a configuração inicial

A equipe do projeto deve executar a configuração inicial para iniciar o desenvolvimento. As atividades de configuração inicial 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.

Observação

O planejamento de implantação difere dependendo da solução e do fluxo de trabalho de sua preferência. Esse artigo descreve apenas o planejamento de alto nível e itens acionáveis.

Para obter mais informações sobre o planejamento de implantação, consulte Planeje 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 êxito. Abordar áreas técnicas (como gateways de dados ou espaços de trabalho) e também adoção (como treinamento e governança de usuários).
• Realize 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 configuração pela primeira vez.
• Teste conexões de fonte de dados: valide se os componentes e processos apropriados estão em vigor para se conectar aos dados corretos para iniciar a prova de conceito.

Passo 3: realize uma prova de conceito

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

Recomendamos levar em consideração as considerações a seguir ao preparar uma POC.

• Metas e escopo: descreva o propósito da POC da solução e as áreas funcionais que ele abordará. Por exemplo, a equipe de projeto pode decidir limitar a POC a uma única área funcional ou a um conjunto específico de requisitos ou recursos.
• Dados da fonte: Identifique quais dados serão usados na POC. Dependendo da solução, a equipe de projeto pode decidir usar diferentes tipos de dados, como:
  • Dados de produção (reais)
  • 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á a POC para as partes interessadas e usuários. Demonstrações podem ser fornecidas durante atualizações regulares ou quando a POC atende a critérios funcionais específicos.
• Ambiente: descreva onde a equipe do projeto criará a POC. Uma boa abordagem é usar um ambiente de área restrita distinta para a POC e implantá-la em um ambiente de desenvolvimento quando estiver pronta. Um ambiente de área restritatem políticas mais flexíveis e conteúdo fluido, e é focado em produzir resultados rápidos. Por outro lado, 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 a POC for bem-sucedida e dever passar para a próxima iteração e entrar em desenvolvimento formal. Antes de iniciar a POC, a equipe do projeto deve identificar critérios claros para quando a POC é bem-sucedida. Ao definir esses critérios com antecedência, a equipe do projeto define quando o desenvolvimento da POC termina e quando os ciclos iterativos de desenvolvimento e validação começam. Dependendo das metas da POC, a equipe de projeto pode definir critérios de sucesso diferentes, como:
  • Aprovação da POC pelas partes interessadas
  • Validação de recursos ou funcionalidades
  • Revisão favorável da POC por pares após um tempo fixo de desenvolvimento
• Falha: certifique-se de que a equipe do projeto possa identificar a falha da POC. Identificar a falha logo no início ajudará a investigar as causas principais. Também pode ajudar a evitar mais investimentos em uma solução que não funcionará como esperado quando for implantada na produção.

Cuidado

Quando a equipe do projeto conduz a POC, eles devem permanecer alertas para 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 escopo e a finalidade da POC estejam claros para os usuários corporativos. Certifique-se de comunicar que a POC é uma primeira iteração e enfatize que não é uma solução de produção.

Observação

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

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

• Definir as metas: garantir que as metas da POC sejam claros para todas as pessoas envolvidas.
• Defina o escopo da POC: certifique-se de que a criação da POC não exigirá muito esforço de desenvolvimento, ao mesmo tempo em que agrega valor e demonstra o design da solução.
• Decida quais dados serão usados: identifique quais dados de origem você usará para fazer a POC, justificando sua decisão e delineando os riscos e limitações potenciais.
• Decida quando e como demonstrar a POC: planeje para mostrar o progresso apresentando a POC aos tomadores de decisão e usuários corporativos.
• Esclareça quando a POC termina: certifique-se de que a equipe do projeto decida sobre uma conclusão clara para a POC e descreva como ela será promovido a ciclos formais de desenvolvimento.

Etapa 4: criar e validar conteúdo

Quando a POC é bem-sucedida, a equipe do projeto muda da POC para a criação e validação de conteúdo. A equipe do projeto pode desenvolver a solução de BI com ciclos iterativos de desenvolvimento e validação. Esses ciclos consistem em versões iterativas, em que 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.

Dica

A entrega iterativa incentiva a validação antecipada e os comentários que podem mitigar solicitações de alteração, promover a adoção de soluções e obter benefícios antes do lançamento da 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 comentários do usuário para abordar. Quando os ciclos de desenvolvimento e validação são concluídos, 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 descreve como a equipe do projeto pode fornecer iterativamente soluções de BI com ciclos de desenvolvimento e validação.

O diagrama descreve as seguintes etapas.

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 P e R, para que os usuários entendam o que há de novo na versão e possam fornecer comentários verbais.
	Durante a validação, os usuários fornecem comentários por meio de uma ferramenta ou formulário central. A equipe do projeto deve revisar os comentários regularmente para resolver problemas, aceitar ou rejeitar solicitações 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 nenhum 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 de projeto precisa executar ações de habilitação e gerenciamento de alterações adicionais.
	A equipe do projeto responde prontamente aos comentários dos usuários. Se a equipe de projeto demorar muito para lidar com comentários, os usuários poderão perder rapidamente a motivação para fornecê-lo.
	A equipe do projeto incorpora os comentários aceitos 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 por todas as etapas até chegar a uma conclusão predefinida e a solução está pronta para implantação em produção.

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

Criar conteúdo

A equipe do projeto desenvolve a solução seguindo seu fluxo de trabalho de desenvolvimento normal. 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 de alterações e novos recursos em cada versão.
• A cada versão, considere organizar sessões para demonstrar mudanças e novos recursos à 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 o conteúdo

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

• Validação do desenvolvedor: o teste da solução é feito por criadores de conteúdo e pares. 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 os 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 comentários 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 teste 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). Esses problemas podem corroer rapidamente a confiança na solução e prejudicar a adoção a longo prazo.

Dica

Ao realizar a validação do usuário, considere chamadas ocasionais e curtas com usuários-chave. Observe-os quando usarem 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. Essa abordagem pode ser uma maneira eficaz de coletar comentários.

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

• Incentive os comentários do usuário: a cada versão, solicite que os usuários forneçam comentários e demonstrem como eles podem efetivamente fazer isso. Considere compartilhar regularmente exemplos de comentários e solicitações que levaram a alterações recentes e novos recursos. Ao compartilhar exemplos, você está demonstrando que os comentários são reconhecidos e valorizados.
• Isolar solicitações maiores: alguns itens de comentários 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 posteriores de planejamento tático.
• Iniciar atividades de gerenciamento de alterações: treine os usuários como usar a solução. Certifique-se de investir um esforço extra em novos processos, novos dados e diferentes formas de trabalhar. Investir em gestão de mudanças tem um retorno positivo na adoção de soluções a longo prazo.

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

Observação

O desenvolvimento e o teste diferem dependendo da solução e do fluxo de trabalho de sua preferência.

Esse 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 os comentários 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 os comentários: automatize a coleta de comentários usando uma solução simples para você e seus usuários. Crie um formulário simples para garantir que os comentários sejam concisos, mas acionáveis.
• Agende uma reunião para revisar comentários: reúna-se para revisar brevemente cada item de comentários novos ou pendentes. Decida se você implementará os comentários não, quem será responsável pela implementação e quais ações tomar para fechar o item de comentários.
• Decida quando a entrega iterativa é concluída: descreva as condições para quando os ciclos de entrega iterativa serão concluídos e quando você liberará conteúdo para o ambiente de produção.

Etapa 5: implantar, oferecer suporte e monitorar

Quando estiver pronta, a equipe do projeto implantará 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.

• Comunique a versão final: o patrocinador executivo, um gerente ou outra pessoa com autoridade e credibilidade suficientes devem anunciar a liberação para a comunidade de usuários. A comunicação deve ser clara, concisa e incluir links para as soluções relevantes e canais de suporte.
• Realize um treinamento para consumidores de conteúdo: o treinamento deve estar disponível para os consumidores de conteúdo durante as primeiras semanas após a liberação para produção. O treinamento deve se concentrar em esclarecer o escopo da solução, responder às perguntas do usuário 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. Certifique-se de que comentários e solicitações razoáveis sejam discutidos e, quando apropriado, implementados durante o período de suporte pós-implantação. Agir com base nos comentários e nas solicitações após o lançamento da produção é importante. Isso indica uma solução ágil que responde às mudanças nas necessidades dos negócios.
• Planeje conectar-se 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 da solução se reúnam regularmente com a comunidade de usuários. Essas reuniões são fontes valiosas de comentários para revisar sua estratégia de BI. Além disso, eles ajudam a apoiar a adoção de soluções, habilitando os usuários.
• Ações de transferência: membros da equipe de projeto podem não ser responsáveis por manter a solução. Nesse caso, a equipe deve identificar quem é o responsável e realizar uma transferência. 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.

Cuidado

A falha na realização de uma entrega efetiva pode levar a problemas evitáveis com o suporte e a adoção da solução 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:

• Criar 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 transferência: se necessário, prepare uma transferência da equipe de desenvolvimento para a equipe de suporte.
• Conduzir o horário de atendimento da solução: após o período de suporte pós-implantação, considere realizar sessões regulares de horário comercial para responder perguntas e coletar comentários dos usuários.
• Configurar um processo de melhoria contínua: agende uma auditoria mensal da solução para revisar possíveis alterações ou melhorias ao longo do tempo. Centralize os comentários do usuário e revise os periodicamente entre as auditorias.

Conteúdo relacionado

Para obter mais considerações, ações, critérios de tomada de decisão e recomendações para ajudar você com decisões de implementação do Power BI, veja o planejamento de implementação do Power BI.