Sobre o que é o artigo?

Este é um artigo generalizado sobre o que é "automação orçamentária", quais são os problemas dessa área e quais ferramentas de TI são utilizadas nela.



Se você deseja entender como BI, data warehouses (DWH), sistemas de automação orçamentária (Cognos, Anaplan, 1C: Holding Management, Bit.Finance) estão interligados e como eles diferem de outros sistemas de informação corporativos, clique aqui.



Se você é um arquiteto técnico que nunca trabalhou com a área temática de planejamento de negócios, este artigo também é para você.





Aviso desde já que procurei escrever o artigo na linguagem mais simples possível para que fosse compreensível para todos.

Por que decidi escrever?

Hoje em dia, praticamente não existe uma breve descrição sistemática desta área, o que daria respostas claras às questões:

1. ? ?
2. (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, ., 1: ) ?
3. BI – ?

A diferença arquitetônica entre contabilidade e planejamento é que os dados contábeis fluem de baixo para cima. Para obter relatórios de qualidade, você precisa organizar o registro de fatos tão detalhados quanto possível. Então, qualquer informação resumida (importante para gerentes) pode ser obtida por simples agregação.



Portanto, em contabilidade, o esquema Documento -> Tabela (Registro) -> Relatório funciona perfeitamente (que era usado muito antes da automação, na contabilidade medieval).





Figura: 1. Esquema de contabilidade "Documento -> Registro -> Relatório"





Os planos foram inicialmente ampliados. Portanto, é conveniente inseri-los exatamente "de cima" (ou seja, nos mesmos formulários em que os relatórios são gerados).



Portanto, ao tentar construir uma automação orçamentária por analogia com a contabilidade convencional (Fig. 3), as empresas imediatamente enfrentam três problemas principais.





Figura: 3



Problema 1: Administrando regras . É muito inconveniente e trabalhoso administrar as regras de transformação de dados (desde os níveis mais baixos de contabilidade até o formato de orçamento), escritas no código do relatório.



Problema 2: A velocidade de "coleta de fatos" . Os planos são exibidos em relatórios muito rapidamente (uma vez que já estão armazenados de forma ampliada) e os dados reais são calculados muito lentamente.



Problema 3: Planeje os formulários de inscrição... A forma mais conveniente para inserir planos é um relatório de fatos do plano. Mas relatórios em sistemas de informação geralmente não permitem a entrada de dados.



As duas primeiras questões não estão apenas relacionadas ao orçamento e, em geral, representam a base de toda a área de armazenamento de dados, integração de dados e ETL.



O terceiro problema é um problema de planejamento específico. Que, aliás, é um dos problemas importantes dos sistemas ERP como ferramentas de tempo real (destinadas não só à contabilização "póstuma" dos eventos ocorridos, mas também ao planeamento e controlo operacional do negócio).

Problema 1: administrar regras de transformação

Na fig. 1-3, todas as regras para transformar dados reais (do nível de contabilidade mais baixo para os níveis de relatório superiores) são explicitadas diretamente no código de relatório.



Isto é mau:

• As regras não podem ser administradas sem alterar o código;
• Eles só podem ser usados ​​neste relatório.
  que significa:

  – , , ,
  
  – - ,
  
  

Complexidade das regras de transformação

É muito importante considerar aqui que as regras de transformação podem ser bastante complexas. A transformação nem sempre é uma simples agregação de dados (do dia ao mês; do departamento à organização; do depósito à região; da linha de produtos ao artigo, etc.). Isso é especialmente evidente no CIS, onde a contabilidade gerencial costuma ser baseada na contabilidade. Então, a partir de uma variedade de combinações de diferentes detalhes contábeis, diferentes valores para a contabilidade gerencial podem ser determinados.





Você pode imaginar o quão significativo é o problema de manter esse código para os programadores. Se houver várias centenas desses artigos, eles serão usados ​​em uma dúzia de relatórios diferentes e as regras para determiná-los na contabilidade gerencial podem ser ajustadas a cada 3-4 meses.

Solução para o problema 1: mapeamento

Para resolver este problema, o mapeamento - correspondência entre campos de diferentes níveis e / ou tipos de contabilidade e relatórios - pode ser retirado dos relatórios, criado como um objeto separado, configurado e armazenado separadamente e, em seguida, consultá-los se necessário.





Figura: 4



Isso tem duas vantagens ao mesmo tempo:

• As regras são mais fáceis de administrar. Eles podem ser interativos e configurados sem código, o que significa que até mesmo usuários comuns podem fazer isso;
• Uma regra pode ser usada em diferentes relatórios e / ou outros algoritmos

Essa abordagem não tem desvantagens significativas.



Mas desenvolver uma ferramenta para mapeamento conveniente de grandes volumes de diretórios não é fácil.

Problema 2: Velocidade de transformação dos dados reais

Solução para o problema 2: armazenamento de dados transformados

Para não calcular os dados do relatório "em tempo real", eles podem ser armazenados de forma ampliada e transformada.



Para fazer isso, além das tabelas de origem (que ainda serão necessárias na empresa), você precisa criar tabelas para armazenar os dados reais agregados. Estas podem ser tabelas separadas e uma tabela geral para o "plano" e o "fato" agregado.



Claro, essas tabelas devem primeiro ser preenchidas de alguma forma: para isso, vamos realizar o mesmo procedimento de transformação que foi executado antes ao gerar o relatório, mas agora vamos movê-lo para um processo de segundo plano separado.





Figura: cinco

DWH

Relacionado a esse problema está o domínio do Data Warehouse (DWH).



Grosso modo, DWH é um local (uma tabela ou, na prática, um conjunto de tabelas relacionadas) para armazenar dados intermediários calculados (agregados ou de alguma forma transformados).



Quais são os prós:

• Velocidade de leitura de dados. Se os relatórios "lêem" dados já transformados da tabela, eles o fazem muito rapidamente.
• Verificabilidade. Quando os dados são pré-armazenados no warehouse, é mais fácil verificá-los.

Desvantagens:

• Precisão. Na verdade, esse menos é bastante teórico (a precisão máxima é garantida precisamente quando pegamos dados da fonte primária de informação).
  Na prática

  , ; , . , , , .
• Carregando memória. Conseqüentemente, para armazenar dados agregados, desperdiçamos espaço extra em discos rígidos. Além disso, na verdade, uma desvantagem bastante teórica.
• Descriptografia. Se conectarmos relatórios a tabelas agregadas (nas quais os dados não são detalhados de acordo com os documentos fonte), surgem problemas com as possibilidades de sua descriptografia (drill down).

Processos ETL

ETL pode ser chamado de qualquer processo no qual os dados são retirados de algum lugar, modificados e carregados em algum lugar. Esta é uma abreviatura comum para Extrair, Transformar, Carregar.



Mas geralmente esse termo é usado precisamente nos casos em que os dados após a transformação são gravados em algum lugar para armazenamento.



Essa abordagem tem vantagens:

• Distribuição da carga no sistema. O processo de transformação se estende ao longo do tempo. Podemos preencher a tabela agregada gradualmente (conforme alteramos / adicionamos dados nos sistemas contábeis originais) ou em um cronograma. Por exemplo, cálculos complexos podem ser adiados durante a noite ou outro horário não comercial quando o servidor está "livre". Isso permite que você gerencie a carga no sistema.
• Transformação única. Depois de gravar as informações de resumo em uma tabela agregada, podemos acessá-la a partir de muitos relatórios diferentes. Portanto, as mesmas transformações não precisam ser executadas muitas vezes.

Só há um menos:

• A complexidade de controlar a integridade dos dados carregados. Construir um processo ETL que não perca dados, que seja suficientemente transparente e controlável - é possível, mas isso requer uma equipe altamente qualificada, envolvimento do usuário e custos trabalhistas perceptíveis.

Problema 3: formulário para inserir orçamentos

O fato é que, na forma clássica, os relatórios em produtos de software são um meio de saída de dados. Mas você não pode inserir dados neles.





Mas para o orçamento, o esquema clássico "Formulário de entrada" (documento) -> tabelas internas -> Formulário de saída (relatório) "não é adequado.



Por exemplo, certa vez desenvolvemos um relatório mensal de aquisições (como na Fig. 2), e agora começamos o planejamento e o CFO deseja inserir o orçamento de aquisições da mesma forma.



O que resta fazer? Você pode criar um formulário de entrada de plano que se parece muito, muito semelhante a este relatório (conforme mostrado na Figura 3).

Solução para o problema 3: formulários de E / S interativos

A solução também é óbvia: em vez dos habituais "documentos" e relatórios ", você deve criar um objeto que irá simultaneamente e para ler e inserir dados.



Melhor ainda se neste objeto também for possível realizar cálculos entre os dados inseridos e / ou lidos - ou seja, trabalhar como o Excel permite que você trabalhe.



Nesse caso, os planos depois de inseridos podem ser "adicionados" ao mesmo data warehouse onde os dados reais estão localizados (veja a figura).





Figura: 6



Mas esses formulários são muito mais difíceis de implementar do que relatórios ou documentos comuns em sistemas de contabilidade.



O grau de interatividade pode ser diferente: é mais fácil implementar formulários pré-configurados, mais difícil - dinâmico (onde o número de colunas / linhas não é conhecido de antemão, mas seus tipos são predefinidos). É ainda mais difícil permitir ao usuário “girar” os dados, construir novos formulários e definir fórmulas de cálculo arbitrárias, alterando a estrutura dos relatórios.

Solução para o problema 4: cubos

Existe outra ferramenta que resolve um problema não indicado acima.

O fato é que com grandes quantidades de dados, com alta interatividade e com fórmulas complexas, tabelas SQL relacionais comuns, nas quais é costume armazenar dados de sistemas ERP, não proporcionam a velocidade máxima de processamento de dados em tempo real.



Para resolver este problema, você pode usar o armazenamento de dados não na forma de tabelas, mas imediatamente na forma de cubos.





É verdade que, se para tarefas de orçamento, organizar imediatamente o armazenamento na forma de um cubo é uma opção boa e adequada, então, para outras tarefas de negócios, um modelo de armazenamento multidimensional pode não ser adequado, e o armazenamento é organizado usando uma tecnologia diferente. Nesse caso, o cubo pode ser adicionado ao armazenamento "principal" como outro link na arquitetura.

TIPOS DE PRODUTOS DE SOFTWARE NO ORÇAMENTO

Agora vamos considerar os tipos de tecnologias de informação que resolvem problemas que são importantes na automação orçamentária:

• Sistemas de dados iniciais (sistemas de contabilidade, sistemas ERP)
• Ferramentas ETL
• Armazéns de dados (cubos regulares e OLAP)
• Sistemas de BI
• Sistemas EPM
• Excel claro

Cada tipo de sistema tem uma função teoricamente básica (veja a tabela):







Mas, na realidade, as fronteiras são ligeiramente confusas e, muitas vezes, os produtos "sabem" fazer coisas relacionadas. A sobreposição de funções é mais ou menos assim:







Importante: deve-se observar que a sobreposição de funções geralmente não é 100%.



Ou seja, geralmente uma ferramenta que oferece funções adicionais não as executa tão bem como uma ferramenta especializada separada!

Mapa de tipos de software no orçamento

Em geral, a cobertura visual de diferentes tarefas de automação orçamentária por diferentes tipos de sistemas de informação pode ser mostrada aproximadamente assim:





Fig. 7



Agora vamos ver que tipo de arquitetura de orçamento alguns produtos de software populares oferecem.

ORÇAMENTO EM SISTEMAS ERP

O conceito de ERP muda com o tempo e novos recursos estão sendo incorporados aos sistemas ERP.



Na minha opinião, a funcionalidade "clássica" do ERP inclui um sistema de contabilidade; designers de relatórios; funções de controle operacional de planos e, claro, as capacidades básicas de sua entrada.



Exclui: capacidade de coletar dados de fontes múltiplas; construindo cubos e análises interativas



Há razões para acreditar que o EPM (como o BI) foi concebido como algo que ia além do ERP. Mas agora as fronteiras estão se confundindo e as funções de EPM ou mesmo produtos inteiros podem ser incluídos como módulos em sistemas ERP.

1C: SCP

O UPP implementa o seguinte esquema, mas dentro de uma base.





Figura: 8. Arquitetura de orçamentação em 1C: UPP



Vantagens de orçamentação em UPP:

• O SCP é muito transparente e fácil de modificar. É fácil verificar os dados nele e é bastante barato desenvolver novas funcionalidades.

Mapeamento - no SCP em um nível médio. Este não é um ponto positivo ou negativo. Definir a intensidade média de trabalho.



Desvantagens do orçamento em SCP:

• Falta de formas interativas de entrada-saída. A criação de quaisquer dados é efectuada através de documentos (introdução de planos; obtenção de dados reais agregados; realização de cálculos), onde não existe e não pode haver interactividade e possibilidade de ver o panorama geral.
• Falta de interface ETL. Há mapeamento, mas os dados reais são carregados diretamente do formulário do documento, o que é inconveniente.
• Plataforma antiga. Você não pode usar a tecnologia 1C Managed Forms, que oferece ao usuário possibilidades modernas de filtragem / classificação universal de listas e relatórios. Isso degrada as capacidades analíticas do usuário.

Em geral, no SCP, a automação do orçamento é mais claramente implementada de acordo com o princípio da contabilidade comum: o usuário não trabalha a partir do quadro geral, mas a partir de documentos primários (inserindo um plano; carregando um fato; estimativas), e o quadro geral só pode ser visto em relatórios nos quais nada pode ser inserido.

1C: ERP

Pelo que me lembro, inicialmente o ERP fornecia apenas um modelo de relatório "online". E hoje, em muitas empresas, o cenário principal é exatamente esse. No entanto, agora o programa permite o armazenamento intermediário dos valores calculados.





Figura: 9. Arquitetura de orçamentação em 1C: ERP



Vantagens de orçamentação em 1C: ERP:

• Formas suficientemente funcionais de entrada-saída

Desvantagens do orçamento em 1C: ERP:

• A rigidez do modelo. Em princípio, como na maioria dos sistemas ERP, o modelo de orçamento não tolera mudanças frequentes e é bastante exigente quanto à pré-configuração
• Mapeamento fraco. Por algum motivo, a funcionalidade de mapeamento é pior do que no UPP
• Dureza do produto. Ao contrário do SCP, é extremamente difícil e caro retrabalhar a estrutura da metodologia. Você precisa estudar bem o existente e construir um orçamento em 1C: ERP, se realmente for adequado para a empresa
• Atuação. Os formulários interativos são bastante funcionais, mas o dispositivo técnico os torna extremamente lentos em grandes quantidades de dados

Também em 1C: ERP não há nenhuma funcionalidade séria em termos de configuração do processo de orçamento organizacional (fluxo de trabalho) e trabalho multiusuário. Por exemplo, os processos de aprovação são incluídos em um produto separado 1C: Workflow, que geralmente é implementado no topo do ERP.

1C: CA

A Automação Integrada é uma versão simplificada de 1C: ERP, portanto, seu desenvolvimento segue o mesmo caminho e não existe uma metodologia própria de orçamentação.

MS Axapta / MS Dynamics AX

Existe apenas um modelo "online" para visualizar os dados orçamentários reais - eles são lidos diretamente de seus próprios módulos de contabilidade, enquanto as possibilidades de uma transformação séria não são fornecidas.





Figura: 10. Arquitetura de orçamento no MS Dynamics



Tanto o ponto positivo quanto o negativo do sistema é o seu "aprimoramento" para seus próprios módulos de contabilidade do Dynamics e sua estrutura pronta.



Prós:

• Integração com módulos de contabilidade. Configurar a obtenção de dados reais de vários módulos do sistema ERP é bastante simples.
• Integração. Existem muitas possibilidades para carregar planos prontos de sistemas externos. Assim, a Microsoft segue claramente a lógica de separação do EPM do ERP, como resultado do qual os sistemas EPM são muito bem "pendurados" no Dynamics
• Fluxo de trabalho. Modelo organizacional personalizável, suficientemente funcional e transparente do processo de orçamento

Desvantagens:

• ETL. Em geral, o produto não fornece recursos de transformação de dados significativos
• Dureza do produto. Uma metodologia pronta, mas bastante limitada, é definida aqui. E (como no caso de 1C: ERP) não só é difícil reciclá-lo, mas também praticamente inútil.

SAP S4 HANA

O principal produto SAP que substituiu o sistema ERP SAP R / 3.



Para o orçamento, um produto EPM separado agora é usado, que na versão desktop (SAP BPC) ainda pode ser considerado um sistema EPM separado "no topo" do ERP, mas na versão em nuvem (SAP Analytics Cloud) já está finalmente integrado ao sistema ERP (no SAP S4 HANA Cloud). Mais detalhes sobre SAP BPC estarão abaixo.



É importante dizer algo mais sobre o próprio S / 4 HANA: SAP transfere todo o trabalho de um sistema ERP de um banco de dados relacional para um combinado (uma mistura de relacional, colunar e multidimensional). Tal banco de dados combinado é sua própria tecnologia SAP HANA (não confundir com S / 4 HANA), que, dependendo das ações do usuário, funciona tanto como transacional (sistema contábil), depois como sistema analítico (cubo).



Assim, a SAP está mudando para uma arquitetura que é o oposto do que agora é bem conhecido na prática "normal". Nele, o banco de dados analítico não é construído "acima" do armazenamento (SAP BW), mas é implementado "sob" o sistema ERP. Neste caso, o data warehouse (SAP BW), quando o usuário trabalha com seus dados do sistema EPM, transfere os dados para cálculos de volta para este banco de dados combinado original.



Na verdade, o SAP atinge o mesmo efeito para o qual o OLAP IN-Memory foi concebido de forma oposta: maximizando os cálculos fora da RAM.

Oracle Cloud ERP

A Oracle também escolheu o caminho de incorporar um sistema EPM dentro de um ERP.



A empresa está movendo ativamente seus produtos para a versão em nuvem (talvez até mais ativamente do que a SAP). Portanto, para sua principal solução de EPM, o Oracle Hyperion (da qual também falaremos a seguir), a empresa está promovendo uma alternativa na forma de nuvem Oracle EPM Cloud, que está incluída no Oracle Cloud ERP baseado em nuvem.

BI-SYSTEMS

Os sistemas BI (Business Intellegence) em sua forma "pura" são um meio de saída de dados. Ou seja, BI são designers de relatórios e painéis, que geralmente também contêm funções básicas para reestruturação e análise de dados (por exemplo, eles permitem que você junte tabelas, encontre tendências médias, etc.).



Sistemas populares de BI:

• Power BI
• Quadro
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

Normalmente, o BI se conecta a armazenamentos de dados (relacionais e multidimensionais) ou a tabelas SQL brutas. Assim, você pode consultar dados de origem suficientemente detalhados (para agregá-los já no BI). No entanto, transformações condicionais complexas (com condições “se”) não são sobre a funcionalidade de BI “clássica”. Se você se depara com a tarefa de construir um sistema de visualização de painel, é melhor construir uma transformação antes de implementar o BI.

SISTEMAS EPM

EPM significa Enterprise Performance Management. Além disso, os termos gerenciamento de desempenho corporativo (CPM) e, menos comumente, gerenciamento de desempenho empresarial (BPM) são encontrados.



Um termo bastante amplo que pode implicar funções relacionadas, mas na maioria das vezes esses sistemas podem ser considerados construtores de formas interativas de "fatos planejados". O conceito de EPM ainda não se tornou conhecido, mas soluções como IBM Planning analytics, Oracle Hyperion, Anaplan, que às vezes são consideradas no contexto de Business Intellegence, são mais corretamente chamadas de sistemas EPM.



Às vezes, os sistemas EPM são criados para propósitos mais amplos (por exemplo, SAP EPM ou 1C: Holding Management), mas vamos considerá-los precisamente em termos de sistemas para automação orçamentária. Portanto, chamaremos SAP Business Planning & Consolidation (SAP BPC) - um sistema EPM, embora a própria SAP o chame de produto SAP EPM maior, que inclui SAP BPC.



Como dissemos, o BI não permite a entrada de dados. Os EPMs geralmente incluem funções de BI padrão e, além disso, fornecem a capacidade de inserir e gravar dados.



Sistemas EPM notáveis:

• Oracle Hyperion
• IBM Planning Analytics
• Anaplan
• SAP BPC
• Bit.Finance
• 1C: Gestão de Holding

Vamos começar com os mais pequenos.

Bit.Finance

Bit. Finance é baseado na metodologia de orçamento de UPP, no entanto, ao contrário dela, em primeiro lugar, é suportado e desenvolvido e, em segundo lugar, é implementado como um sistema EPM em cima do ERP (assim, permite consolidar dados factuais de várias fontes externas).





Figura: 11. Arquitetura de orçamento em Bit.Finance



Vantagens da automação de orçamento em Bit.Finance:

• Construtores de formulários para entrada ou leitura de dados. Ao contrário da UPP, os formulários dos documentos contábeis não são fixos aqui, eles podem ser personalizados, trazendo-os para uma forma bastante conveniente.
• Interface para gerenciamento de estimativas de custos. Você pode recalcular modelos de orçamento aqui centralmente, em vez de criar manualmente um documento de cálculo de custos.

O mapeamento é mais desenvolvido do que no SCP.



A obtenção de dados reais funciona de três maneiras:

• Por meio de um documento de aquisição de evidências (como no SCP),
• Contabilidade paralela. Nesta opção, os documentos contábeis, à medida que são mantidos, criam lançamentos simultâneos nos registros contábeis e orçamentários.
• Método de transmissão. Nesta opção, as entradas do razão contábil são convertidas no razão de orçamento.

Desvantagens da automação do orçamento no Bit.Finance:

• Trabalhe com as formas dos documentos. Apesar de as formas dos documentos terem se tornado flexíveis (ver o primeiro plus) e, em geral, neste aspecto, muito progresso foi feito em comparação com SCP, o produto ainda não se afastou do modelo de trabalho baseado em documentos tanto quanto gostaríamos. O que, como dissemos, é inconveniente para o orçamento.
• Falta de formas interativas de entrada-saída. Ao contrário de 1C: ERP, não há nenhum aqui.

Anaplan

Um produto carro-chefe que recentemente ganhou grande popularidade no mercado global. Oferecido apenas na versão em nuvem.



Ao contrário de outras soluções populares (incluindo Hyperion e Planning Analytics), ele tem uma especialização ligeiramente específica: funciona melhor como um serviço de custeio que permite recalcular de forma rápida e automática modelos de orçamento volumétrico com um grande número de dependências.





Figura: 12. Arquitetura de orçamento Anaplan (cenário de automação popular)



Prós:

• Custeio. O produto é focado em cálculos e armazena todos os dados em In-Memory OLAP, o que permite que todos os modelos sejam recalculados online
• Trabalho em equipe (na preparação de dados de planejamento)
• UX e modelagem de forma livre.
• ETL. Ferramenta própria e bastante conveniente de ETL
• Requer suporte mínimo de TI. Especialmente quando se trata de modelagem
• Custo. Um pouco caro para o mercado russo, mas em comparação com os líderes internacionais (o mesmo Oracle Hyperion), o custo total de propriedade é menor
• Velocidade de implementação. Comparado ao Hyperion e Planning Analytics, o produto é mais fácil de usar e implementar

Desvantagens:

• Formatação
• Trabalho em equipe (em termos de trabalho com eventos: notificações, mailings, etc.)
• Sintaxe de fórmula personalizada. Em geral, usar seu próprio código é sempre uma desvantagem do ponto de vista dos usuários finais.
• Hierarquias. Costumava haver problemas com o uso de uma hierarquia de diretório diferente para diferentes modelos de orçamento. O problema não é importante para muitas empresas, mas crítico para algumas. Talvez (espero que sim) Anaplan já tenha resolvido esse problema agora.
• Ad-hoc . , : Anaplan , .

Os pontos positivos e negativos de Anaplan são sua especialização relativamente clara e o fato de que ela não invade o ecossistema de TI da empresa. A vantagem é que o produto definiu claramente seu propósito funcional e as direções de seu desenvolvimento são bastante previsíveis. É um serviço para realizar análises de variações hipotéticas, calcular e aprovar planos (orçamentos), e você precisa planejar a arquitetura do cliente com base nisso. A desvantagem é que o produto não pode substituir um data warehouse corporativo completo, não pode substituir todos os recursos de BI, uma infraestrutura ETL corporativa complexa não é construída sobre ele e, na verdade, todo o sistema de computação corporativo. Tudo isso não seria problema se o produto não fosse oferecido apenas na versão em nuvem.



Ao contrário de Oracle e SAP (que afirmam ser ecossistemas), Anaplan não enfatiza a capacidade de "mover" facilmente dados e ferramentas entre a nuvem e os servidores da empresa. Assim, no caso dele, as desvantagens do produto em nuvem (levando em consideração a tarifação em função da quantidade de dados utilizados no servidor) aparecem mais perceptíveis.



Por não substituir um storage corporativo universal, em certos casos pode ser utilizado como serviço de cálculo que “agrega” dados planejados ao próprio DWH da empresa, de onde os dados são transferidos para um sistema de BI separado para a construção de relatórios e dashboards rápidos.





Figura: 13. Arquitetura de orçamento Anaplan (cenário de automação alternativo)



Em geral, o uso de sistemas EPM e BI é uma prática normal.

Oracle Hyperion

Ele vem em pelo menos duas versões: Oracle Hyperion Planning e Oracle Hyperion Financial Management.

Agora sendo substituído ativamente pelo novo produto Oracle EPM Cloud.



Devido ao ecossistema, as arquiteturas podem assumir uma variedade de tipos, mas a típica se parece com isso.





Figura: 14. Arquitetura de orçamento em Hyperion (opção possível)



Na figura, dei um sistema de BI como exemplo, já que o banco de dados analítico Oracle Essbase é um excelente banco de dados para analítica de big data em ferramentas de BI.



O Oracle Data Integrator é oferecido como uma solução ETL, que atua como um mecanismo universal de integração de dados no ecossistema Oracle.



Prós da automação de orçamento no Oracle Hyperion:

• Ecossistema. No caso da Oracle, vou observar isso como um ponto positivo, já que a Oracle é um dos maiores fornecedores de banco de dados, e a integração para empresas que trabalham com Oracle DBMS (e existem muitas empresas desse tipo) realmente traz vantagens. Em particular, é mais conveniente distribuir a funcionalidade entre a nuvem e o servidor. Além disso, os colegas falam sobre vantagens bastante sérias em termos de segurança na arquitetura da Oracle (não sou especialista nisso, se houver alguma aqui, corrija).
• Ad-hoc ("relatórios sob demanda").

Desvantagens da automação do orçamento no Oracle Hyperion:

• Ecossistema. Notarei também como sinal de menos, pois, de acordo com as informações disponíveis, o Hyperion é escolhido principalmente por empresas que trabalham na pilha de tecnologia Oracle, e a partir de seu uso em um ambiente não Oracle a longo prazo, um efeito menor é possível.
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

Destinado principalmente a grandes empresas, não é muito fácil de implantar e administrar, mas um sistema EPM muito funcional. Atualmente, a analítica do IBM Planning é construída em tecnologias TM1 (que são o núcleo do Cognos).



Para processos ETL, a IBM sugere o uso de um produto separado, IBM DataStage (usado anteriormente pelo Cognos DataManager), Turbo Integrator, Cognos Integration Server ou uma ferramenta ETL externa.



A arquitetura típica é muito semelhante ao Hyperion.





Figura: 15. Arquitetura de orçamento em Planning Analytics (opcional)



Pontos fortes do IBM Planning Analytics:

• Previsão.
• Trabalho com eventos.
• Flexibilidade. O produto não pode ser considerado não exigente em termos de pré-configuração, mas tenta ser adaptável a modelos em mudança.
• Não é um ecossistema. O que é surpreendente em trabalhar com a IBM é que um grande volume de materiais didáticos produzidos pela empresa tem como objetivo descrever as melhores práticas para interação dos produtos IBM com outras soluções (incluindo Oracle e SAP) e em uma variedade de questões. Na minha opinião subjetiva, é bom que no longo prazo, a empresa mantenha a tendência de desenvolver integração com sistemas de terceiros (o que permite suportar uma variedade de arquiteturas que se desenvolveram nas empresas), e não reduzi-la.
• Suporte ao produto.

Minuses

• Complexidade. Tal como acontece com o Hyperion: requer treinamento significativo do usuário, não a infraestrutura mais leve.

SAP BPC

Em geral, as características distintivas do SAP são os ecossistemas, a complexidade da arquitetura e a infraestrutura das soluções.



Como eu disse antes, a SAP deu suporte e oferece suporte a diferentes opções de arquitetura em momentos diferentes; De acordo com as informações mais recentes, a versão carro-chefe da arquitetura recomendada pelo fornecedor hoje é assim:





Fig. 15. Arquitetura de orçamento no SAP Business Planning & Consoldation (exemplo)



Vantagens do orçamento baseado em SAP BPC:

• Integração de dados. Embora complexo, é funcional e rápido, o que é essencial para as grandes empresas.
• Visualização.
• Fluxo de trabalho.

Desvantagens do orçamento baseado em SAP BPC:

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• Preço. Em termos de custo total de propriedade, ele acaba sendo um dos sistemas EPM mais caros do mundo, o que é influenciado por mudanças na arquitetura.

ETL-TOOLS

Ferramentas ETL bem conhecidas são usadas para construir processos ETL, entre os quais existem muitos produtos dos mesmos fornecedores que produzem soluções de BI / EPM:

• IBM DataStage
• Informatica PowerCenter
• Talend
• Apatar
• SAP Data Services
• Oracle Data Integrator
• Microsoft Azure Data Factory
• e muitos outros dr.

Prevê-se que o artigo seja atualizado gradualmente, possivelmente com a adição de informações sobre novos produtos e os princípios de desenvolvimento de produtos de software para orçamentação a partir do zero.