Partilhar via


Realizar prova de conceito para migrar para o Power BI

Este artigo descreve o Estágio 3, que se preocupa com a realização de uma prova de conceito (POC) para mitigar riscos e abordar incógnitas o mais cedo possível ao migrar para o Power BI.

Diagram shows the stages of a Power BI migration. Stage 3 is emphasized for this article.

Nota

Para obter uma explicação completa do gráfico acima, consulte Visão geral da migração do Power BI.

O foco da Fase 3 é abordar as incógnitas e mitigar os riscos o mais cedo possível. Um POC técnico é útil para validar suposições. Isso pode ser feito iterativamente junto com o planejamento da implantação da solução (descrito no Estágio 2).

A saída deste estágio é uma solução do Power BI que tem escopo restrito, aborda as perguntas abertas iniciais e está pronta para trabalho adicional no Estágio 4 para torná-lo pronto para produção.

Importante

Não pretendemos que o POC seja um trabalho descartável. Em vez disso, esperamos que seja uma iteração inicial da solução pronta para produção. Em sua organização, você pode se referir a essa atividade como um protótipo, piloto, maquete, início rápido ou produto minimamente viável (MVP). A realização de um POC nem sempre é necessária e pode até acontecer informalmente.

Gorjeta

A maioria dos tópicos discutidos neste artigo também se aplica a um projeto de implementação padrão do Power BI. À medida que sua organização se torna mais experiente com o Power BI, a necessidade de conduzir POCs diminui. No entanto, devido à cadência de lançamento rápido com o Power BI e à introdução contínua de novos recursos, você pode conduzir POCs técnicos regularmente para fins de aprendizagem.

Definir metas e escopo do POC

Ao conduzir um POC, concentre-se nos seguintes objetivos:

  • Verifique suas suposições sobre como um recurso funciona.
  • Informe-se sobre as diferenças no funcionamento do Power BI em comparação com a plataforma de BI herdada.
  • Valide entendimentos iniciais de certos requisitos com especialistas no assunto.
  • Crie um pequeno modelo semântico (anteriormente conhecido como conjunto de dados) com dados reais para entender e detetar quaisquer problemas com a estrutura de dados, relacionamentos, tipos de dados ou valores de dados.
  • Experimente e valide expressões de sintaxe DAX usadas por cálculos de modelo.
  • Teste a conectividade da fonte de dados usando um gateway (se for para ser uma fonte de gateway).
  • Teste a atualização de dados usando um gateway (se for para ser uma fonte de gateway).
  • Verifique as configurações de segurança, incluindo segurança em nível de linha, quando aplicável.
  • Experimente com layout e decisões cosméticas.
  • Verifique se todas as funcionalidades no serviço do Power BI funcionam conforme o esperado.

O escopo do POC depende de quais são as incógnitas, ou quais objetivos precisam ser validados com os colegas. Para reduzir a complexidade, mantenha um POC o mais estreito possível em termos de escopo.

Na maioria das vezes, com uma migração, os requisitos são bem conhecidos porque há uma solução existente para começar. No entanto, dependendo da extensão das melhorias a serem feitas ou das habilidades existentes do Power BI, um POC ainda fornece um valor significativo. Além disso, a prototipagem rápida com feedback do consumidor pode ser apropriada para esclarecer rapidamente os requisitos, especialmente se forem feitas melhorias.

Importante

Mesmo que um POC inclua apenas um subconjunto de dados, ou inclua apenas visuais limitados, geralmente é importante levá-lo do início ao fim. Ou seja, desde o desenvolvimento no Power BI Desktop até a implantação em um espaço de trabalho de desenvolvimento no serviço do Power BI. É a única maneira de alcançar plenamente os objetivos do POC. É particularmente verdadeiro quando o serviço do Power BI deve fornecer funcionalidades críticas que você não usou antes, como um modelo semântico do DirectQuery que usa logon único. Durante o POC, concentre seus esforços em aspetos sobre os quais você não tem certeza ou precisa verificar com outras pessoas.

Lidar com diferenças no Power BI

O Power BI pode ser usado como uma ferramenta baseada em modelo ou como uma ferramenta baseada em relatório. Uma solução baseada em modelo envolve o desenvolvimento de um modelo de dados, enquanto uma solução baseada em relatório se conecta a um modelo de dados já implantado.

Devido à sua extrema flexibilidade, existem alguns aspetos sobre o Power BI que podem ser fundamentalmente diferentes da plataforma de BI herdada da qual você está migrando.

Considere redesenhar a arquitetura de dados

Se você estiver migrando de uma plataforma de BI herdada que tenha sua própria camada semântica, a criação de um modelo semântico de importação provavelmente será uma boa opção. O Power BI funciona melhor com um design de tabela de esquema em estrela. Portanto, se a camada semântica herdada não for um esquema em estrela, é possível que algum redesign seja necessário para se beneficiar totalmente do Power BI. Esforçar-se para definir uma camada semântica aderente aos princípios de design de esquema em estrela (incluindo relacionamentos, medidas comumente usadas e terminologia organizacional amigável) serve como um excelente ponto de partida para os autores de relatórios de autoatendimento.

Se você estiver migrando de uma plataforma de BI herdada onde os relatórios fazem referência a fontes de dados relacionais usando consultas SQL ou procedimentos armazenados, e se estiver planejando usar o Power BI no modo DirectQuery, poderá conseguir uma migração individual do modelo de dados.

Atenção

Se você vir a criação de muitos arquivos do Power BI Desktop compreendendo uma única tabela importada, geralmente é um indicador de que o design não é o ideal. Se você notar essa situação, investigue se o uso de modelos semânticos compartilhados que são criados usando um design de esquema em estrela poderia alcançar um resultado melhor.

Decidir como lidar com conversões de painel

No setor de BI, um painel é uma coleção de elementos visuais que exibe métricas-chave em uma única página. No entanto, no Power BI, um painel representa um recurso de visualização específico que só pode ser criado no serviço do Power BI. Ao migrar um painel de uma plataforma de BI herdada, você tem duas opções:

  1. O painel herdado pode ser recriado como um relatório do Power BI. A maioria dos relatórios é criada com o Power BI Desktop. Relatórios paginados e relatórios do Excel também são opções alternativas.
  2. O painel herdado pode ser recriado como um painel do Power BI. Os painéis são um recurso de visualização do serviço do Power BI. Os visuais do painel geralmente são criados fixando elementos visuais de um ou mais relatórios, perguntas e respostas ou Insights Rápidos.

Gorjeta

Como os painéis são um tipo de conteúdo do Power BI, evite usar a palavra dashboard no nome do relatório ou do painel.

Concentre-se no panorama geral ao recriar elementos visuais

Toda ferramenta de BI tem seus pontos fortes e áreas de foco. Por esse motivo, os visuais de relatório exatos dos quais você dependia em uma plataforma de BI herdada podem não ter um equivalente próximo no Power BI.

Ao recriar visuais de relatório, concentre-se mais nas questões de negócios gerais que estão sendo abordadas pelo relatório. Ele remove a pressão para replicar o design de cada visual exatamente da mesma maneira. Embora os consumidores de conteúdo apreciem a consistência ao usar relatórios migrados, é importante não se envolver em debates demorados sobre pequenos detalhes.

No próximo artigo desta série de migração do Power BI, saiba mais sobre o estágio 4, que se preocupa com a criação e validação de conteúdo ao migrar para o Power BI.

Outros recursos úteis incluem:

Parceiros experientes do Power BI estão disponíveis para ajudar sua organização a ter sucesso com o processo de migração. Para envolver um parceiro do Power BI, visite o portal do parceiro do Power BI.