Como tal, seu uso principal é realizado pelas equipes de negócios das organizações, a fim de realizar relatórios financeiros e operacionais de informações reais (jurídicas e administrativas) e coletar, construir e relatar previsões e orçamentos financeiros.
O nível em que esses dados são relatados geralmente está em um nível resumido e não no nível totalmente granular encontrado nos principais sistemas transacionais / ERP da empresa.
Mas até que ponto o uso do BPC pode ser ampliado e pode ser usado como uma ferramenta de BI de pleno direito?
Normalmente, as ferramentas de BI são usadas pelas organizações para relatar todos os tipos de itens que uma organização pode querer relatar. Os dados de origem podem ser extremamente granulares e as ferramentas de BI são projetadas para lidar com volumes extremamente grandes de dados.
O BPC é uma ferramenta? Ele pode ser configurado e usado para suportar relatórios em nível granular?
Existem vários aspectos do BPC que precisam ser considerados antes de se chegar a uma conclusão sobre essa idéia, e as organizações que estão pensando nesse sentido devem ponderar cuidadosamente os prós e os contras de adotar ou tentar usar o BPC como uma ferramenta de BI.
Organizações gostam do BPC, porque oferece todos os benefícios de um ambiente de dados controlado, ou seja, um banco de dados com segurança do usuário e regras de operação, com os relatórios flexíveis e amplamente utilizados oferecidos pelo pacote Microsoft (MS) Office, especificamente o Microsoft Excel. Os usuários finais estão extremamente familiarizados com esses produtos de EMP e esse fator por si só pode levar uma organização a escolher o BPC como sua ferramenta de relatório financeiro.
Mas o que acontece depois? O BPC pode ser usado mais extensivamente?
As pistas para a resposta talvez estejam na maneira como o BPC armazena os dados que ele contém. Cada ponto de dados é definido por uma interseção das dimensões que definem o modelo e sua finalidade. Para manter um dado (por exemplo, unidades ou valor monetário), os membros das dimensões que definem esse ponto de dados já devem existir no banco de dados (por exemplo, entidade, categoria, período, conta). Em termos financeiros, esses itens tendem a ser relativamente estáticos: os gráficos de contas não alteram muito nem as estruturas das entidades.
Depois de começar a considerar outros itens de dados, por exemplo, faturas (AR e AP), itens de inventário, registro de ativos e assim por diante, você se depara com cenários diferentes, pois esses itens, dependendo do seu negócio, podem ter volumes significativos e alterações frequentes. Estes seriam descritos como dimensões que mudam rapidamente. O desafio do BPC é manter os dados mestre nas dimensões suficientemente atualizados (por exemplo, atualizações noturnas por meio de interfaces automatizadas) para que o ponto de dados real possa ser mantido contra esses elementos de dados mestre. A dimensão do tipo “contas” pode explodir de tamanho para conter os vários índices que sua organização deseja relatar. Por exemplo, se o BPC deve ser usado para relatar mercadorias recebidas não faturadas, o BPC precisaria de detalhes do fornecedor em uma dimensão, detalhes do pedido de compra em outra e a dimensão das contas precisaria de linhas adicionais, por exemplo, quantidade do pedido (PO), valor do pedido (líquido e bruto de imposto?), Quantidade recebida, Valor recebido, Quantidade faturada e Valor faturado. Em que nível você mantém esses dados? Puramente no nível do pedido ou você precisa ir para o nível do item de linha (SKU)? Alguém em sua organização sempre desejará o próximo nível de detalhe, independentemente do nível que você decidir manter, e você já terá esse detalhe granular de baixo nível no (s) sistema (s) de origem. Deseja mesmo duplicar tudo no BPC?
Criar e manter as dimensões e interfaces necessárias para usar o BPC como uma ferramenta de BI exigiria, sem dúvida, recursos extras com um conhecimento mais amplo. Os resultados comerciais desejados precisam ser totalmente compreendidos e traduzidos em requisitos funcionais e técnicos para a equipe do ERP / DW / BPC. Pode-se dizer “esse é o caso de qualquer maneira”, mas é provável que essas habilidades sejam necessárias além do escopo “normal” do BPC da equipe de finanças da organização, das tabelas GL do ERP e de um processo ETL amplamente simples. E então você se depara com perguntas como a frequência com que os processos de atualização e carregamento são executados. Como os dados mestre precisam ser atualizados antes do carregamento principal dos dados, é provável que esses processos tenham que ser agendados fora do horário comercial normal, para que as atividades comerciais como usuais não sejam afetadas negativamente. Esse agendamento de atualização e atualização seria aceitável para os usuários comerciais que necessitam das informações? No mínimo, eles precisarão estar totalmente cientes de quando poderão usar os dados necessários e ter suas expectativas gerenciadas de acordo.
Então, qual é a resposta?
Na minha opinião, para versões do BPC até 11 inclusive na configuração CLASSIC, a resposta provavelmente é sim, pode ser usada como uma ferramenta de BI, mas você precisa ter muito cuidado e realmente pensar no que deseja reportar e como deseja antes de se comprometer totalmente a seguir esse caminho. Para o que sua organização exige, pode ser melhor usar o BPC para seus objetivos principais e considerar uma solução de BI sob medida para seus outros relatórios (claramente, também há implicações de custo nessa abordagem).
Quanto às versões do BPC na configuração incorporada, isso pode ser realmente muito diferente, pois a duplicação de dados não é um problema e as estruturas de dados são completamente diferentes. No entanto, as habilidades necessárias para configurar e, em seguida, gerenciar e manter uma solução incorporada podem muito bem ser um problema, pois a ênfase parece estar de volta à TI, e não à empresa.