Por que E na abreviação EHD é sobre processos de negócios

Data Warehouse sem E

Hoje, em qualquer empresa relacionada a empresas de grande e médio porte, a disponibilidade de um data warehouse é um padrão corporativo de fato. Não importa em que setor a empresa opera, sem analisar os dados disponíveis sobre clientes, fornecedores, finanças, é impossível manter uma vantagem competitiva. Com o desenvolvimento da automação e otimização em cada nível de produção de um produto ou serviço, a organização usa cada vez mais sistemas de TI que criam dados - produção, contabilidade, planejamento, gerenciamento de pessoal e outros.

Como criar o processo de criação de um data warehouse com mais eficiência do ponto de vista da otimização global dos recursos da empresa, das necessidades de negócios novas e atuais e por que a manutenção de metadados é importante.

As tarefas para usar dados acumulados são usadas com mais frequência para as seguintes classes de tarefas:

• relatórios regulatórios
• contabilidade financeira
• planejamento e controle
• orçamento
• análise da base de clientes
• gestão de riscos

Frequentemente, para os propósitos mais urgentes, basta usar uma fonte - por exemplo, se estivermos falando em fornecer ao regulador alguns detalhes de um determinado sistema ou em enviar ao cliente todo o histórico de seus pedidos usando CRM. Mesmo ao alterar os sistemas de informação, geralmente não há dificuldade em obter relatórios.

Métodos e tipos de armazenamento de dados

No entanto, quando o tamanho da organização se torna grande o suficiente, ou se você deseja aumentar sua vantagem competitiva, não basta mais criar um produto e trazê-lo ao mercado. Tendências atuais - em um estudo abrangente do consumidor para aumentar sua lealdade. Você precisa analisar os negócios de diferentes ângulos e aprender a avaliar com mais precisão os custos. As tarefas típicas da categoria devem ter são as seguintes:

• como alocar despesas para unidades de mineração de negócios
• Como prever a demanda dependendo de fatores internos ou externos
• Como gerenciar riscos em organizações financeiras e de seguros
• Como aumentar o cheque médio do cliente (segmentação)

Cada um dos exemplos acima requer o uso de mais de uma fonte de dados. Além disso, é importante que os métodos para comparar dados entre fontes sejam consistentes. Caso contrário, uma situação inevitavelmente surgirá quando a organização, digamos, o diretor de estratégia e o diretor de vendas levarem as mesmas informações ao diretor geral, mas com números diferentes. E então, um mês, eles descobrem quem estava "à direita", usando quase metade do pessoal à sua disposição.

A maneira mais primitiva de organizar um data warehouse é o chamado "data lake" (ou data lake), quando simplesmente coletamos e empilhamos dados de diferentes fontes. Nesse caso, temos uma plataforma técnica única para trabalhar com dados e isolar consultas analíticas complexas das principais tarefas dos sistemas de informação. Esse data warehouse pode ser bastante não-relacional. No entanto, nesse caso, você pode esquecer a análise complexa e operar apenas com consultas simples. Além disso, as pessoas que trabalham com dados devem ter conhecimento não apenas da área de negócios, mas também dos modelos de dados dos sistemas de origem.

Além disso, de acordo com o nível de organização do data warehouse, o armazenamento segue, de acordo com o chamado Classificação de Kimball (Kimpball). As medidas de sistemas diferentes são unificadas e, dessa forma, obtemos algo como uma rede com dois tipos de tabelas - fatos e medidas. Esse é o principal enriquecimento de diretórios, quando, usando alguma chave natural comum nas mesmas tabelas de fontes diferentes, por exemplo, TIN no diretório de organizações, obtemos uma única referência.

O próximo em complexidade e confiabilidade é um data warehouse com um único modelo de dados que reflete os objetos mais importantes que descrevem as atividades da organização. A confiabilidade reside no fato de que os dados, apresentados de forma semelhante à terceira normal, com um modelo corretamente formulado, são um meio universal de descrever a vida de todo o negócio e, portanto, o modelo de dados pode ser facilmente adaptado não apenas para relatórios analíticos e regulatórios, mas e para a operação de alguns sistemas corporativos.

E - um

Falando sobre a tese deste artigo, listarei os principais problemas enfrentados pelos responsáveis ​​pela construção de data warehouses:

" Cavalo no vácuo ." O repositório é construído, mas ninguém o usa.

A caixa preta . O armazenamento é construído, mas o que está nele e como funciona é incompreensível. Por esse motivo, ocorrem erros constantes e, se uma parte da equipe de desenvolvimento também foi encerrada, como resultado, entramos no ponto a.

" Calculadora ". O armazenamento é construído, mas atende apenas a solicitações primitivas, os negócios mudam muito mais rapidamente que a implementação de requisitos, novas solicitações de negócios não são levadas em consideração. Além disso, alguns dados podem estar desatualizados ou raramente atualizados.

" Vaso de cristal ". São necessários muitos controles manuais, verificações e ações de controle manual para o armazenamento; se um dos participantes do suporte não estiver trabalhando, há um grande risco de receber dados inválidos ou de não recebê-los.

Analisaremos todos os quatro casos com mais detalhes.

"Um cavalo no vácuo." Se você obtiver esse resultado, isso aconteceu por um de dois motivos:

1. Menos provável. Você não coletou requisitos de unidades de negócios (ou, o que é o mesmo, eles foram mal projetados). Uma situação aparentemente absurda surge se a idéia de criar um repositório não vier de um negócio, mas de um departamento de TI, que simplesmente possui um orçamento "extra", e o repositório foi concebido porque todo mundo o possui. Encontraremos os clientes mais tarde (ainda melhor é a opção "eles virão correndo com as mãos estendidas") - se colocarmos tudo lá. As pessoas responsáveis ​​pela alocação do orçamento consideram que isso é algo necessário, leem e ouvem nos livros, é como uma modernização e concordam.
2. Mais provável. Os clientes do data warehouse foram identificados, por exemplo, este é o departamento de vendas, e aqui vem a idéia brilhante: "vamos fazer um pouco mais de esforço no delta, direcionar finanças, pessoal para ele e um pouco mais e toda a empresa usará o armazenamento". O armazém foi construído, mas é usado apenas pelo departamento de vendas, embora tudo esteja bonito lá e eu não queira ir às margens do leite, mas não, meus colegas não têm tempo para os bancos de kissel, eles precisam cavar um pedaço de dados na mina de manhã até a noite. Afinal, esta é uma peça obtida por suor e sangue (leia-se: tempo gasto).

Nos dois casos, não há nenhum elemento de assumir responsabilidade no gerente superior e reduzi-lo na hierarquia. É como na cultura corporativa. Se o gene. Se o diretor da empresa tiver 2 deputados, apenas o próprio gene poderá fazer uso do armazenamento no nível da empresa. um cervo ou o armazenamento está sendo construído para parte da empresa - aquela que é supervisionada pelo chefe da posição mais alta, que está ciente da necessidade de introduzir o EDM.

Para eliminar essas situações, é necessário o seguinte:

1. Determinar formalmente o patrocinador do projeto de data warehouse - quem será o responsável pelo resultado, tanto financeira quanto espiritualmente
2. Aprovar o escopo do projeto, possivelmente em fases, indicar datas aproximadas
3. Coordenar com todos os departamentos - de preferência com a construção dos processos de negócios como estão e a serem

Somente depois disso podemos começar a implementar o projeto - coletando requisitos, projetando a arquitetura etc.

A caixa preta . Então, você alega que construiu o repositório, que todos os requisitos são levados em conta, no entanto, ninguém entende como usá-lo; além disso, se um dos principais desenvolvedores for embora, torna-se quase impossível entender o que foi feito e como.

Nesse caso, obviamente, o processo de documentação de desenvolvimento não foi definido. O princípio da “primeira documentação”, então o desenvolvimento deve ser elevado, se não ao Absoluto, para um controle bastante rígido. E não apenas da equipe responsável pelo desenvolvimento do data warehouse. Idealmente, é necessário que desenvolvedores de relatórios adicionais (analíticos, regulatórios), proprietários dos sistemas de informações internos da empresa e, é claro, os próprios consumidores estejam conectados ao processo de documentação contínua e atualizada.

Além disso, o processo de documentação deve atender aos seguintes princípios:

• Relevância - o estado atual do código do programa é completamente determinado pela composição da documentação
• Controle de versão - a capacidade de analisar a documentação de versões anteriores e planejar modificações para versões futuras
• Separação - várias pessoas podem trabalhar em um documento ao mesmo tempo
• Aplicabilidade Ele diz que, para cada tipo de documentação de armazenamento, é importante escolher uma estrutura que seja melhor compreendida pelos usuários de destino: por exemplo, a estrutura da tabela é melhor descrita em forma de tabela, processos de negócios na forma de notações, interação entre sistemas de informação na forma de um diagrama, negócios - um dicionário na forma de um sistema wiki, etc.

Agora, existem produtos de software que simplificam seriamente a vida, ou seja, para vincular design e desenvolvimento, mas, embora ainda não exista uma solução completa para data warehouses, eles são:

• Gráficos ER
• Produtos BPMN
• Soluções ETL

Sem a documentação atualizada, a complexidade do desenvolvimento de novos requisitos aumentará e, com a documentação competente, diminuirá.

" Calculadora ". Se assumirmos que não recebemos um “cavalo no vácuo”, essa situação é quando os requisitos parecem ser atendidos, mas são atendidos formalmente. Você queria contar o resto do dia - por favor. Deseja obtê-los por região de contrapartes - isso não estava nos requisitos, é necessário fazer o upload para o excel, depois retirar do sistema X um upload para as contrapartes com a opção do campo Y e, em seguida, VPR-ite.

A situação atual indica uma falta de experiência com a equipe, sem uma visão arquitetônica do desenvolvimento subsequente do repositório, sem mesmo um modelo de dados primitivo. Normalmente, esses repositórios se tornam temporários ou são rapidamente esquecidos. De uma maneira boa, a loja deve ter o poder de uma bola de neve rolando de uma montanha. A princípio, quando o caroço ainda é pequeno e há neve solta à frente, você dificilmente precisará coletá-lo e empurrá-lo. Em algum momento, a fama sobre seu produto se espalhará e os usuários procurarão na loja cada vez mais.

Portanto, para que o armazenamento não seja uma calculadora, é necessário garantir:

1. pessoal qualificado - arquitetos, analistas, desenvolvedores de EtL e SQL
2. O termo de abertura do projeto, que indicará o objetivo do armazenamento não apenas para o próximo período orçamentário, mas também para os anos subsequentes
3. Critérios quantitativos e qualitativos para um data warehouse. Se não houver pessoal suficiente, é recomendável atrair consultores
4. Imagine claramente o que ajudará a otimizar o data warehouse no futuro - custos com equipe, software, aumentar a velocidade do desenvolvimento de relatórios etc.

" Vaso de cristal ". O armazenamento é construído, parece estar lidando com suas tarefas, mas exige muito esforço para apoiá-lo: manter algum tipo de diretório manual, recarregar constantemente algumas fontes, falhas no carregamento, duplicar dados etc.

Essa situação pode ocorrer pelos seguintes motivos:

1. Sobre o que foi dito acima - a falta de pessoal qualificado;
2. Conceito não arquitetônico - quando diferentes partes do armazenamento são feitas por pessoas ou equipes diferentes sem um conceito comum aprovado, como resultado, temos várias maneiras de extrair, transformar e carregar dados;
3. Uma situação muito comum é o "desenvolvimento de terceirização", seu próprio apoio, enquanto a aceitação do trabalho é mal realizada
4. Em algum momento do desenvolvimento do repositório, "o orçamento acabou". E então o armazenamento está sendo finalizado (suportado) não pela equipe que o criou, mas por aqueles que precisam de dados

Para evitar essas situações, as seguintes ações são recomendadas:

1. Os pontos acima incluem pessoal qualificado, o termo de abertura do projeto, o plano e orçamento de longo prazo e a pessoa interessada do gerente de topo.
2. Não é a terceirização que lidera o processo, mas um funcionário interno (analista-chefe ou arquiteto) que supervisiona a terceirização.
3. Qualquer situação de falha deve ser enviada às reuniões para consideração do arquiteto do armazém. Se houver vários arquitetos, o comitê de arquitetura.
4. É aconselhável introduzir uma métrica de qualidade para o armazém de dados; você pode usar essa métrica para ligar ao comando KPI.

Como pode ser visto, em todos esses casos, apesar de a criação de um data warehouse ser uma atividade de projeto, os próprios processos de criação devem ser regulados para criar um resultado de alta qualidade.

Transição de um data warehouse para um único

Como mencionado acima, o sucesso do projeto para criar um data warehouse é determinado por muitos dados de entrada (orçamento, patrocinador, equipe, objetivos, clientes). No entanto, praticamente não tocamos em processos de negócios que visam desenvolver e manter o próprio CD. A seguir, tentarei formular os principais processos de negócios, projetados para tornar os processos de trabalho com dados na empresa verdadeiramente unificados:

1. Processos para manter a documentação técnica e do usuário atualizada
2. Processos para manter o dicionário de negócios (glossário) de dados atualizado
3. Processos de controle de qualidade de dados
4. Processos para a coleta e gerenciamento de requisitos para CD e sistema de relatórios
5. Processos de gerenciamento de infraestrutura de armazenamento
6. Processos para otimizar o armazenamento e a coleta de dados

No paradigma moderno, esse conjunto de processos de negócios forma a base do conceito de Governança de Dados.

Muitas vezes, ao tentar implementar esses processos através dos esforços da equipe de criação e relatório de CD, resistência ativa será tomada ou ignorar os processos. É compreensível, porque no sentido local é uma extensão do desenvolvimento.

Portanto, será útil executar as seguintes ações:

• Introdução de uma estrutura de responsabilidade horizontal (cada participante pode ser responsável por uma pequena área)
• Representação gráfica de todos os fluxos de trabalho possíveis para todos os funcionários (formalização do processo)
• Implementação da porcentagem e qualidade da responsabilidade no sistema KPI

Apesar de, no sentido local, o processo de transição parecer significativamente "burocrático" e pesado, no sentido global, oferece vantagens significativas e economiza tempo. Desde a principal perda de tempo - ao inventar do zero soluções já existentes devido à impossibilidade ou falta de desejo de entender o mecanismo existente.

Um pouco sobre a solução arquitetônica de destino

Apesar do fato de a arquitetura do EDS basear-se em um grande artigo separado, ou mesmo em um livro, também indicarei os principais requisitos técnicos para um data warehouse maduro:

1. O paradigma do data lake não substitui os data warehouses corporativos, mas coexiste com ele
2. O EDS deve ter várias interfaces de apresentação de dados: ferramentas bi, capacidade de executar consultas ad-hoc sql, fornecimento de dados padrão em json, xml, etc.
3. Um modelo de função de acesso a dados deve ser implementado.
4. Velocidade de resposta ao acessar dados: 90% das consultas típicas - menos de 1 segundo, 99% das consultas - menos de 10 segundos. Deve haver um suprimento razoavelmente bom de recursos
5. A presença de uma camada central única e conectada de HD (preferencialmente - metodologia Inmon)

Como resultado, o data warehouse é chamado de unificado não pela disponibilidade de fontes, mas pela disponibilidade dos consumidores de dados. E isso é muito mais complicado do que escrever um ETL universal e ajustar os petabytes de memória.