Consolidar dados SAP e não-SAP com governança, acelerando o caminho do dado à decisão — sobre a plataforma que a empresa já tem.
A consciência coletiva destes pontos é a base para entender as escolhas de arquitetura.
Cada área extrai e calcula seu próprio KPI. Reuniões de resultado viram reconciliação de números, não decisão.
Extrações paralelas do ERP, dados defasados entre cópias e um custo crescente de armazenamento e manutenção.
Planilhas e bases legadas alimentando relatórios oficiais — sem owner, sem qualidade medida, sem linhagem.
Cada análise nova exige novo pipeline. IA e ML travados por falta de dado com contexto de negócio.
O case pede relatórios consistentes para as áreas de negócio — e o desenho precisa servir também o que vem depois.
Uma única versão dos KPIs oficiais — o mesmo número do ERP, sem recálculo manual e sem esperar extração.
Indicadores dos processos ponta a ponta, cruzando dados SAP e não-SAP com contexto de negócio.
Fechamento confiável e comparabilidade entre áreas — a reunião de resultado volta a ser decisão, não reconciliação.
Orçamento e forecast sobre os mesmos modelos do reporting — real × plano sem reconciliação entre ferramentas.
O maior valor represado: ML com contexto de negócio — previsão de capital de giro e ruptura, modelos híbridos SAP + operação, GenAI sobre dado governado. Sem dado com semântica e qualidade, não há IA confiável.
A comunidade analítica (Power BI) explorando dados governados — liberdade dentro de guardrails.
A solução não nasce no vácuo: ela precisa respeitar (e aproveitar) o landscape que já existe.
“O dado SAP permanece governado no SAP; o dado não-SAP permanece no lakehouse; a integração acontece por compartilhamento e federação — não por cópia.”
Federação e Delta Sharing primeiro; replicação quando a medição provar necessidade — uma vez, com CDC, owner e linhagem.
Cada KPI tem um único sistema de definição; o outro plano recebe o número pronto, não a fórmula. Fim das múltiplas verdades.
Todo dado relevante vira produto: contrato, dono, qualidade medida, catálogo. Confiável para BI, planning e IA.
Ingestão → plataforma governada → consumo por perfil. Delta Sharing conecta tudo sem duplicar.
O que o case quer saber se resume a três frentes — integração, reporting e data products. Elas são o roteiro do restante da conversa.
Como conectar S/4HANA, BW/4HANA, SQL Server e APIs no Datasphere — e garantir consistência sem duplicar dados?
E os dados críticos em Excel e bancos legados, sem comprometer a governança?
SAC ou Power BI/Tableau? E como garantir a mesma semântica de KPIs em todos os relatórios?
Como estruturar o reporting para executivos, analistas e operacionais?
Como aproveitar os data products pré-configurados do BDC — e como explicá-los a um público leigo?
Como criar um data product customizado com governança e reúso garantidos?
"Como você conectaria sistemas SAP (S/4HANA, BW/4HANA) e fontes não-SAP (SQL Server, APIs externas) no SAP Datasphere? Quais conectores ou métodos usaria?"
| Fonte | Método / conector | Porquê |
|---|---|---|
| S/4HANA | Data Products do BDC (1ª opção); gaps: CDS Views via Replication Flow (CDC/ODP); remote tables para baixa volumetria / alta volatilidade | Data products eliminam pipelines e preservam a semântica do ERP; CDC evita full loads; federação evita cópia |
| BW/4HANA | BW Model Transfer (queries e CompositeProviders com a semântica) + remote tables; com BDC, objetos BW expostos como data products | Reaproveita 100% da lógica investida no BW — reescrita é o maior custo e risco de qualquer migração |
| SQL Server | Replication Flow com conector nativo MS SQL (CDC), via Cloud Connector quando on-premises | Near-real-time sem sobrecarregar o sistema de origem |
| APIs externas | Conexão OData/REST; Open Connectors sob demanda | Integração gerenciada e padronizada, sem código customizado a manter |
| IoT / logs massivos | Streaming → lakehouse (Databricks), integrado ao Datasphere por Delta Sharing | Object storage: custo por TB ordens de magnitude menor para alta volumetria |
"Como garantiria consistência sem duplicar dados?"
A consulta vai até o dado — ele não se move. Zero cópias, zero pipeline.
Quando: acesso esporádico ou dado volátilOutra engine lê o dado? Compartilha-se o ponteiro, não a cópia: um único dado físico para vários consumidores — hub-and-spoke, no espírito Data Mesh.
Quando: Databricks das franquias lendo data products SAP (e vice-versa)Quando inevitável (transformações pesadas, proteção do produtivo, histórico longo): uma única vez, com CDC, owner nomeado, linhagem registrada e contrato de dados.
O problema não é replicar — é a extração descontrolada em paralelo, que fabrica as "múltiplas verdades""Se a empresa tivesse dados críticos em planilhas Excel e bancos legados, como você os integraria sem comprometer a governança?"
Template validado, owner nomeado, registro no catálogo
A planilha alimenta o fluxo oficial — visível, com linhagem
Toda planilha crítica vira candidata a data product
O data product entra em produção antes do corte — o negócio não sente
Para o lakehouse, conforme o legado ainda receba escrita ou não
Dados registrados com classificação e owner
A origem é desligada quando o consumo migra — sem sistema zumbi
"Qual solução de reporting você recomendaria para consumo dos modelos do Datasphere? Justifique entre SAC e ferramentas externas como Power BI ou Tableau."
O Power BI é realidade consolidada na empresa — para uso pleno e governado, a resposta é uma camada de serving no Databricks: SQL Warehouse com SSO (Entra ID), metric views no Unity Catalog e RLS/mascaramento por usuário.
| Critério | SAC | Power BI via Databricks (serving) |
|---|---|---|
| Semântica | Live connection nativa ao Analytic Model: hierarquias, moedas, unidades, variáveis e autorizações — sem mover dados | Metric views no Unity Catalog: métrica governada e reutilizável (SQL Warehouse, Genie, Power BI). A semântica rica do ERP não é recriada: chega materializada do Datasphere |
| RLS | DAC do Datasphere aplicado automaticamente por usuário | SSO (Entra ID) até o SQL Warehouse: a identidade do usuário final chega ao Unity Catalog — row filters e column masks valem por usuário, sem duplicar RLS em roles de dataset |
| Planning | Nativo, sobre os mesmos modelos do reporting | N/A — planning fica exclusivamente no SAC |
| Escala | Dimensionado para o público SAP/executivo | SQL Warehouse serverless (Photon, result cache, materialized views) absorve milhares de usuários, com FinOps por warehouse |
"Como garantiria que todos os relatórios compartilham a mesma semântica de KPIs?"
| Tipo de KPI | Onde a definição nasce | Como o outro canal consome |
|---|---|---|
| Natureza SAP financeiro, fiscal, ordem-faturamento | Analytic Model do Datasphere: hierarquias, regras e tipagem do ERP, sem reconstrução manual | Materializado como dado (tabela/share certificada) no gold do lakehouse — o Power BI consome o valor calculado; o SAC consome o mesmo modelo, live |
| Híbrido / não-SAP custo por tonelada, OTIF, produção | Metric view no Unity Catalog, sobre o gold do medalhão | Direto via SQL Warehouse; quando precisa aparecer no SAC, volta via Delta Sharing → Datasphere — o mesmo número nos dois canais |
Regras de convivência — o que torna os dois canais um sistema, não uma disputa
"Descreva como você estruturaria a camada de reporting para diferentes perfis de usuários (executivos, analistas, operacionais)."
É isso que garante que todos estejam na mesma página, do boardroom ao chão de operação.
SAC stories curadas e Digital Boardroom: visão agregada, tendência e exceção — incluindo KPIs híbridos (SAP + operação) já consolidados.
Publicação controlada: somente conteúdo certificado, mobile-ready, drill-down guiado.
consome o produto prontoSelf-service em dois canais: SAC sobre Analytic Models (dado sensível: RLS com tabela DAC + grupos do Entra ID via Graph) e Power BI sobre datasets certificados. Quem tem Azure Databricks recebe via Delta Sharing.
Liberdade de exploração dentro do modelo governado — podem criar visões próprias, não redefinir KPIs certificados.
explora dentro dos guardrailsRelatórios padronizados embarcados no fluxo, agendamento e alertas, com dados certificados e KPIs calculados.
RLS por corredor / estrutura hierárquica: cada um vê o seu recorte.
recebe o recorte certo"Como você aproveitaria os data products pré-configurados do BDC para acelerar entregas no Datasphere? E como explicaria data products para um público leigo?"
O caminho: instalar no Datasphere (zero-copy via Foundation Services) → compor os Analytic Models por cima → publicar no SAC. São os "produtos de prateleira": finanças, logística, suprimentos, vendas e RH entregam valor rápido.
Pronto para consumir — ninguém precisa "ir à fazenda" buscar o dado bruto
O que contém, origem, prazo de validade — schema, linhagem e SLA no catálogo
Um responsável por reclamações — owner e governança nomeados
Em vez de cada área preparar "do seu jeito" e gerar versões diferentes do mesmo número
"Cite exemplos de KPIs ou modelos que poderiam ser reutilizados. E como você utilizaria o Datasphere em conjunto ao SAP Databricks?"
| Domínio | Data products / modelos | KPIs reutilizados |
|---|---|---|
| Finanças | Universal Journal (ACDOCA), Contas a Pagar/Receber, Working Capital | DSO/DPO, capital de giro, aging, custo por centro de custo |
| Logística | Estoque, Compras, Entregas | Giro e cobertura de estoque, lead time, OTIF |
| Vendas | Ordens de Venda, Faturamento | Receita por cliente/produto/região, margem bruta, carteira vs. faturado |
| Suprimentos | Pacote Procurement do BDC: Purchase Order/Requisition/Contract, Supplier Invoice, Service Entry Sheet + Insight App Spend Control Tower (S/4 + Ariba) | Gasto por categoria, lead time de compra, saving, performance de fornecedor |
Camada semântica e de BI: modela KPIs, federa fontes, aplica segurança e serve o SAC
Ciência de dados e ML lendo os data products via Delta Sharing, sem cópia — apenas para dados SAP-only
Recomendado para dados híbridos e não-SAP — é onde IoT, PIMS e LIMS moram, e onde a comunidade já opera
"Se fosse necessário criar um novo data product customizado, como você estruturaria o processo para garantir governança e reutilização futura?"
Demanda registrada com objetivo, ganhos e KPIs. Gate anti-duplicidade: já existe produto que atende?
Owner do domínio + contrato rascunhado + decisão federar × replicar documentada + classificação.
Space/repositório do domínio, Git Flow com PR para QA/PRD, testes automatizados de qualidade.
Arquitetura + governança validam contrato, linhagem e aderência aos padrões.
Registro no catálogo com tag do domínio, no space certificado — visível e descobrível.
Monitoramento de uso e SLA; sem consumo por N meses → revisão de descontinuação. Sem cemitério de dados.
Quatro movimentos, do quick win à escala — cada um entregando valor sozinho.
Data products do BDC + Insight Apps (ex.: Working Capital): valor visível em semanas, sem construir pipeline.
Spaces e Analytic Models no Datasphere com DAC; SAC live para executivos e planning. KPI definido uma única vez.
Serving no Databricks: SQL Warehouse com SSO Entra ID, metric views e RLS no Unity Catalog — a comunidade inteira governada.
Hub-and-spoke via Delta Sharing: domínios produzem e consomem com contrato, certificação e FinOps por área.
"Tirar a decisão de cima da planilha e colocá-la sobre dado governado — sem pagar por cópias."
Os riscos reais do desenho, endereçados — não escondidos.
Federação degrada com joins pesados; Delta Sharing entre regiões tem egress. Mitigação: federar × replicar é decisão medida e documentada por produto; FinOps por domínio.
Nem todo cenário tem produto pronto (ex.: manutenção/EAM). Mitigação: gap analysis formal por onda; fallback CDS + Replication Flow; roadmap trimestral com a SAP.
SAC e Power BI podem derivar com o tempo. Mitigação: uma definição por KPI, serving único no UC, reconciliação periódica dos KPIs críticos.
Autonomia sem guardrails recria o problema. Mitigação: proibido extrair direto do S/4; políticas como código no Unity Catalog; gate de certificação para publicar.
Ela se constrói governando o dado onde ele nasce e conectando as plataformas por compartilhamento.
Data products do BDC entregam o dado SAP curado; o Datasphere define uma única versão de cada KPI; o lakehouse processa o não-SAP em escala e serve a comunidade Power BI; as franquias produzem nos domínios.
Resultado: menos pipelines, menos cópias, menos reconciliação — e mais velocidade entre a pergunta de negócio e a resposta confiável.
SAC Planning · RLS na prática (DAC + Entra ID) · SAP Databricks × Azure Databricks · Primeiros 90 dias
Única ferramenta do desenho onde reporting e planejamento usam o mesmo modelo — real × plano sem reconciliação entre sistemas.
| Capacidade | O que entrega |
|---|---|
| Modelos de planning | Versões (real, orçado, forecast), dimensões compartilhadas com o reporting, moedas e conversão nativas |
| Entrada de dados | Grades de digitação com spreading, alocações e regras (data actions); workflows de aprovação por área |
| Previsão | Predictive forecast embutido como ponto de partida; simulações what-if em versões privadas antes de publicar |
| Integração S/4 | Retração para o ERP (ex.: orçamento aprovado de volta ao S/4) e leitura dos mesmos Analytic Models do Datasphere |
| xP&A | Planejamento financeiro e operacional conectados: volume → custo → resultado na mesma plataforma |
A pergunta clássica: "e a segurança por linha, como fica em cada canal?"
Membership extraído via Microsoft Graph
Usuário × recorte (corredor, gerência, site) carregada no Datasphere
Data Access Control filtra as linhas na consulta
Automático na live connection — sem RLS duplicada na ferramenta
A identidade do usuário final chega ao SQL Warehouse
Row filters e column masks avaliados com os grupos do AD, nativamente
Sem roles de RLS duplicadas no dataset
| Critério | SAP Databricks (BDC) | Azure Databricks |
|---|---|---|
| Dado de origem | Data products SAP via Delta Sharing interno, sem cópia e sem sair do BDC | Híbridos e não-SAP: IoT, PIMS, LIMS já moram lá |
| Consumidor do resultado | Volta curta para Datasphere/SAC (scores em story SAP) | Power BI, franquias, aplicações — a comunidade já opera lá |
| Capacidades | Serverless notebooks/SQL; sem ingestão externa própria — escopo SAP | Plataforma completa: streaming, MLflow, Model Serving, Vector Search, DABs |
| Custo | Consome capacidade BDC contratada | Commit Azure existente + FinOps por franquia/warehouse |
| Regra prática | ML SAP-only e resultado para o SAC → SAP Databricks; todo o resto → Azure Databricks — e o Delta Sharing conecta os dois sem duplicar o dado | |
Inventário do que existe: data products BDC ativáveis, extrações paralelas do S/4, KPIs com múltiplas versões, custo das cópias.
Entrega: mapa de gaps + 3 quick wins nomeadosPrimeiro domínio de ponta a ponta (ex.: Working Capital): data product BDC → Analytic Model → SAC + dataset certificado no Power BI.
Entrega: o mesmo KPI nos dois canais, rastreável ao catálogoProcesso de data product formalizado (6 etapas), contrato-modelo, gate de certificação e onboarding da primeira franquia via Delta Sharing.
Entrega: esteira repetível — não um projeto isolado