🙆🏻 💊 🔸 Características de dados orientados a petroquímicos 👨🏾‍🤝‍👨🏽 👩🏿‍🌾 👩🏾‍🤝‍👨🏿

Ao criar qualquer negócio, cada uma de suas divisões se automatiza. Como regra, os fluxos de dados de ponta a ponta entre eles são únicos. Isso leva ao fato de que os dados não podem ser comparados entre si, porque cada departamento os considera à sua maneira. Não há problema se você coletar algumas métricas para toda a empresa, mas quando se trata de calcular indicadores de ponta a ponta, previsões ou resolver problemas de modelagem e otimização, o caos começa.

Data Warehousing (DWH) não é uma história nova. Tradicionalmente, eles foram usados para gerar relatórios. Mas a modelagem e previsão completas dos processos de negócios de ponta a ponta nos dados DWH começaram relativamente recentemente. Usando os dados coletados, as modernas ferramentas de análise possibilitam não apenas criar painéis com janelas suspensas, mas também configurar algoritmos de previsão e otimização para cada atributo, escalar algoritmos de teoria dos jogos para toda a empresa como um todo. E também construa e teste imediatamente hipóteses sobre o desenvolvimento futuro dos negócios em dados reais.

E parece que tudo parece ótimo. Mas nem todas as empresas têm pressa de dar o exemplo dos principais especialistas (Booking.com, Amazon.com) e continuar trabalhando como de costume. Então, o que os está impedindo? No mínimo, entender a viabilidade de investimentos em larga escala em ferramentas de processamento de dados, a laboriosa implementação de processos de descrição de dados, o surgimento de novas funções (curadores de dados responsáveis pela qualidade dos dados, engenheiros e arquitetos de dados etc.), aprendendo a considerar o efeito econômico da implementação do gerenciamento de dados , isole claramente os direcionadores de custos, como tornar o escritório autossustentável, reconcilie-se com a estratégia da empresa e escolha aqueles que levarão a empresa adiante e muito mais.

Meu nome é Victoria Krasnova, sou o chefe do Gerenciamento de Dados Corporativos da SIBUR. Juntamente com meu colega, o líder da equipe de Governança de Dados, Rinat Abdurakhmanov, vamos lhe contar como fazemos isso.

Quando os grandes varejistas (Wallmart) começaram a digitalizar, eles tiveram que descobrir quais pegadas e artefatos digitais um processo de negócios deixava para trás e o que o próximo pegava como entrada. Ou seja, descreva o processo de negócios de ponta a ponta. O mesmo é necessário para a digitalização de qualquer outra empresa. Uma maneira de responder a essa solicitação é o conceito de gerenciamento e arquitetura de dados.

No sentido aplicado, isso significa: reunir os dados mais importantes e não muito importantes da empresa em um só lugar, descrevê-los em uma linguagem clara, vincular-se a processos de negócios e criar métodos fáceis de acessar para esses dados.

A arquitetura de dados, entre outras funções, fornece respostas claras para as perguntas “onde é considerado?”, “O que é considerado?”, “Por que é considerado?”, “Quem é responsável pela qualidade?” e “onde está localizado, em qual sistema está?”.

É importante que as respostas para essas perguntas sejam separadas da própria empresa. Muitas vezes acontece assim: o analista deseja testar uma hipótese. Para fazer isso, ele precisa solicitar os dados necessários ao proprietário, provar por que e por que isso é necessário e importante, passar meio dia nisso. Melhor cenário possível. E, eventualmente, obter uma recusa. Por quê? Como o proprietário dos dados é responsável por fornecer acesso aos dados e sua subsequente disseminação, porque não se sabe como os dados serão interpretados pelo analista e podem não ser adequados para ele etc.

Portanto, é necessário construir uma estrutura e uma lógica que sejam intuitivas, funcionem de acordo com regras uniformes e não desviem o analista nem o proprietário dos dados das tarefas imediatas.

Para esses propósitos, um modelo de dados lógico é excelente - uma descrição dos dados na linguagem comercial, do detalhamento aos detalhes técnicos, em combinação com um modelo de função flexível. Nesse caso, o analista obtém acesso ao repositório e ao conjunto de dados com base em sua função na empresa. E ele coleta o conjunto de dados exigido com base no senso comum, e não no conhecimento de que em 2005 um certo camarada trabalhou na empresa, cujo arquivo contém os dados necessários.

Essa abordagem de estruturação permite que as pessoas analisem rapidamente, torna os dados comparáveis e, como resultado, permitem obter benefícios secundários - digitalizar todo o negócio em etapas.

Quais são os desafios que enfrentamos

No SIBUR, alguns processos são digitalizados muito bem, por exemplo, preparação de dados para marketing, finanças, gerenciamento da cadeia de suprimentos, dados de produção e desvios da planta de produção. Tudo o resto é mais complicado, porque o SIBUR é uma produção com um ciclo no qual, do ponto de vista dos negócios, não há necessidade de coletar informações na mesma velocidade que é necessária no varejo, telecomunicações ou bancos. Nesse sentido, a questão da velocidade na análise de dados também não foi levantada. Mas difícil - não significa impossível. Este ano, planejamos otimizar processos, tornar o cálculo de dados mais transparente, aumentar a taxa de transferência de dados para a tomada de decisões e também começar a coletar faixas digitais em todas as etapas dos processos, sempre que possível.

Por que as empresas digitais são altamente precisas e rápidas para a tomada de decisões? Porque eles praticamente não têm margem para cometer um erro se, de repente, os dados estiverem errados. Na produção, tudo é diferente - não para, as plantas não resistem se houver alguma imprecisão nos dados para análise. Portanto, a arquitetura de dados é a própria força que, ao contrário de tudo, lidera a produção na direção digital. E o gerenciamento de dados é uma biblioteca que permite otimizar o fluxo de dados em toda a empresa.

Recentemente, lançamos uma linha que trata da descrição dos dados. Enquanto estamos em busca de uma ferramenta para descrever os dados, armazene e acesse confortavelmente as descrições. Se a ferramenta para descrição for inconveniente e, por causa disso, não conseguiremos manter a catalogação atualizada, então usá-la não fará mais sentido. Como resultado, os próprios dados no repositório podem não ser relevantes. Por que precisamos criar algo com base em dados cuja data de validade já expirou?

Aqui temos mais uma tarefa: como motivar arquitetos que acompanham os sistemas de informação existentes, descrever os dados e mantê-los atualizados. O princípio de "você constrói, executa" é popular nas empresas digitais. Nossa historicamente a implementa para que algumas pessoas a introduzam, mas outras a apóiam. Frequentemente, a documentação não está atualizada e alguns algoritmos vivem apenas nas mentes dos veteranos. Portanto, a descrição dos sistemas é um trabalho muito demorado, especialmente quando é realizado do zero (como no nosso caso). De fato, na realidade, o efeito deste trabalho virá para eles muito mais tarde, somente depois de descrever uma massa crítica de dados. Mas, no final, ao introduzir outro novo sistema, eles não precisarão procurar dados para alimentá-lo. Agora, leva em média duas semanas ou mais para pesquisar esses dados.

Os dados são necessários não apenas para introduzir novos sistemas, mas também para testar hipóteses. Eles geralmente surgem muito e são testados em lotes. E, de fato, verifica-se que existem dados, existem muitos, eles são diversos, mas apenas muito tempo e dinheiro são gastos em sua pesquisa.

Outro ponto ao alterar dados "sem aviso" em um local faz com que os dados no outro local se tornem incorretos. Por exemplo, o indicador "Volume de produção" costumava levar em conta as perdas nos estágios de redistribuição e depois parava. Eles mudaram o sistema, mas o restante não está atualizado e continuam a usar o indicador como antes. Como resultado, os dados para tomar uma decisão de gerenciamento estão incorretos. Ou, em algum momento, verifica-se que os dados não são comparáveis, as pessoas começam a procurar erros. E isso também é trabalho, apenas invisível e incalculável.

Em geral, como você entende, enfrentamos completamente a questão de escolher uma ferramenta para trabalhar com dados. E antes de escolher um instrumento, você precisa escrever critérios adequados para essa escolha.

Critérios de seleção do instrumento

Estamos em busca de uma ferramenta que ofereça suporte à descrição de metadados na forma de um modelo de objeto com a capacidade de adicionar independentemente novos tipos de objetos. Nem todos os produtos oferecem esse recurso. Por exemplo, algumas ferramentas permitem exibir apenas tabelas físicas como objetos, mas não há classe de objetos para entidades conceituais ou lógicas.
A configuração flexível de conexões entre objetos é muito importante. Por exemplo, hoje temos três níveis lógicos de abstração, mas devemos ser limitados em nossa capacidade de eliminar ou adicionar qualquer número de níveis.

Outro critério importante é a presença de conectores internos nos sistemas de origem, especialmente no SAP. Temos muito SAPa (acho que qualquer empresa grande, em princípio, tem muito SAPa) - uma instalação enorme e escavá-la com as mãos é uma tarefa completamente ingrata. Ideal se houver um. Se não houver esse conector, você poderá escrevê-lo.

Não vamos esquecer a pesquisa de texto completo, a pesquisa semântica com a capacidade de adicionar seus próprios dicionários de sinônimos (por exemplo, o Elasticsearch integrado).

Um papel importante é desempenhado pela possibilidade de feedback. Além disso, idealmente, deve haver a possibilidade de comentar, avaliar o princípio de 1 a 5 estrelas, comunicação direta com a pessoa responsável pela entidade ou atributo de uma entidade específica, além de definir sinalizadores e tags para chamar a atenção, além de adicionar objetos aos Favoritos.

Além disso, é bom teria um conector nativo para o SAS DQ ou qualquer outra ferramenta que possa ser usada para avaliar a qualidade dos dados e exibir o índice de integridade de uma entidade específica, para que o usuário possa ver imediatamente que os dados podem ser confiáveis, porque foram executados com verificação. E dê sua opinião sobre isso.

Em geral, você precisa de algo como isto:

Aqui está um exemplo de um caso típico para você: uma pessoa viu que você pode confiar nos dados, olhou mais de perto e encontrou um erro e escreveu diretamente para o proprietário, solicitando a correção. Acontece uma demonstração de integridade de dados. Essa abertura e ampla disponibilidade de dados reduzem gradualmente o grau de desconfiança de usuários e proprietários. Um analista com o acesso mais básico aos dados pode obter rapidamente as informações necessárias que foram verificadas e, ao mesmo tempo, não depende do proprietário dos dados que contribuem com essas informações. Vantajoso para as duas partes.

Mas geralmente todo mundo tem tudo no Excel, e esse é um grande problema (não o próprio Excel, é claro, mas essa situação). As pessoas contaram os indicadores e os corrigiram em seu próprio tablet, mas nada mudou no sistema geral. E o analista está com medo de entender algumas fontes corporativas publicamente disponíveis; é mais fácil procurar um colega e pedir um arquivo. Isso é bastante difícil de lidar. De fato, o critério para o sucesso da implementação de um escritório de dados pode ser considerado a criação de ambientes nos quais os funcionários, em regra, confiam nos resultados da análise ao tomar decisões e preferem SQL e Python a partir de ferramentas.

Separadamente, vale mencionar a manutenção dos status atuais dos dados “Segredo Comercial”, “Dados Públicos”, “Dados Pessoais”, “Dados Corporativos de Distribuição Limitada”. Ou seja, para um analista de dados, é importante saber exatamente o que ele está navegando e descarregando atualmente ou está deixando seus colegas verem.

Afinal, quando a pessoa comum recorre à legislação relacionada a segredos comerciais e informações confidenciais, vê informações generalizadas sobre o que pode prejudicar as empresas. Em casos frequentes, eles começam a considerar como dados críticos em geral tudo o que contém números (de repente algo). Assim, quando solicitado a fornecer dados para análise, o proprietário começa a se perguntar: “isso é um segredo comercial?”, “As ações do solicitante exigirão danos?”, E, sendo ressegurado, muitas vezes se recusa. Afinal, ele é responsável por essas informações e não sabe como o analista as utilizará.

Houve outro caso: quando estávamos trabalhando em uma lista de informações confidenciais para um projeto de democratização de dados, verificou-se que essa lista contém dados que os proprietários chamam de confidenciais, e somos obrigados por lei a fornecê-los no site oficial. E, é claro, eles são publicados lá. Ou seja, em condições em que não existe uma ferramenta única na qual todos possam ver informações claramente verificadas de uma só vez, muitas pessoas trabalham no modo "não importa o que aconteça" e são muito resseguradas.

Então, isso é tudo sobre os critérios. Mas pelo que exatamente escolhemos.

Procure uma solução

Dizemos "escolher" porque ainda não escolhemos, ainda estamos em busca da ferramenta perfeita. Inicialmente, escolhemos entre Collibra, SAS SAS, Alation, Alteryx Connect e Informatica. Também analisamos projetos estrangeiros de código aberto, mas eles os varreram quase imediatamente, porque ninguém sabe trabalhar com o alfabeto cirílico.

Depois, houve uma experiência malsucedida com a Collibra. Quase concluímos o acordo, mas ele fracassou - não concordamos com as condições. No curto prazo, eles mudarão completamente para a nuvem e, para qualquer empresa russa, isso não é uma opção. Na verdade, eles não fornecem um produto, mas um serviço: o Collibra fornece uma assinatura e nós fornecemos nossos dados. Formalmente, este não é um segredo comercial, mas metadados, mas, de fato, se algo der errado, o negócio ficará completamente paralisado.

Após essa história, percebemos que escolheríamos a caixa por um longo tempo: temos processos longos, abordamos cuidadosamente transações, condições e contratados, verificamos tudo muitas vezes para garantir que o risco seja mínimo. Conhecendo todos esses recursos, desenvolvemos nosso próprio desenvolvimento para criar pelo menos uma solução temporária para os usuários. Afinal, os dados estão vazando e é impossível usá-los sem uma descrição! Paralelamente, analisamos mais detalhadamente o Alation e o Alteryx Connect e comparamos sua funcionalidade e custo com a nossa solução.

Nós mesmos inventamos o modelo lógico de armazenamento, é um pouco mais complicado para nós aqui do que para outros setores. Por exemplo, para bancos e telecomunicações, existem arquiteturas de dados de referência - estruturas e recomendações geralmente aceitas sobre o que e como decompor dados. Para petroquímicos, não há um ciclo completo de fontes para empréstimos criativos no domínio público. Levou apenas um ano para entender como o negócio como um todo funciona. A SIBUR possui uma produção complexa, um grande número de nomenclaturas, processos, negócios, o que se reflete nos sistemas, o que significa que requer análise.

Aqui nos ajudou a existir a chamada liderança intensiva em conhecimento. Por exemplo, em outros setores com bastante frequência, gerentes e gerentes não são muito versados no próprio setor. Isso acontece, em princípio, isso não é algo diretamente terrível; no final, o negócio deles é gerenciar projetos, e acontece que o vínculo de cada novo gerente geralmente conhece um pouco menos do que o anterior. Porém, os gerentes são pessoas capazes de explicar a você todos os processos que podem ocorrer com o butadieno ao longo de sua vida, por exemplo.

Então, sobre a decisão. Uma pesquisa criativa é algo que pode levar um ano, dois ou duas vidas. Portanto, a pesquisa é boa, mas você precisa trabalhar em algo agora.

Então, fomos ao nosso próprio desenvolvimento, chamado dg_light. O desenvolvimento da frente levou quatro semanas (para dizer a verdade, não do zero, reutilizamos as conquistas da ferramenta de análise de timeshare que saiu recentemente da linha de montagem).

Composição do Projeto:

Back-end: Docker, Node.js, NGINX, Crossbar.io
Front-end: Reagir, Redux, UI do material, Highcharts, Autobahn.js
Armazenamento de dados: PostgreSQL
Protocolos: WAMP, WebSocket, HTTP (S)
SO: CentOS 7

A estrutura das instalações de armazenamento e a metodologia foram inseridas pelos arquitetos de dados. Para estudar o design da frente, eles plantaram vários analistas de vários níveis de maturidade e perguntaram: "Como você gostaria que fosse?" De fato, eles pintaram para si mesmos.

Todo o desenvolvimento levou 6 semanas.

Uma pergunta razoável, o que faremos com a decisão quando comprarmos a industrial? Foi originalmente planejado que ambas as soluções permaneceriam paralelas: na "grande" DG haverá modelos de dados, um glossário, um modelo e o dg_light deixará chips complexos que não são fáceis de implementar em uma solução in a box, como a linhagem de dados. O que acontecerá no futuro mostrará a experiência do uso.

Modelo de dados

Física . Tudo começou com a construção de um modelo de dados do armazém. Discutimos por um longo tempo sobre como criar uma camada de armazenamento detalhada e decidimos que não levaríamos um conceito pronto para o trabalho, mas combinamos o Data Vault 2.0 e o Anchor (6NF). Novamente, porque as fontes de dados que temos são muito diferentes. Por um lado, é o SAP, que nas profundezas está em algum lugar OLAP, em algum lugar OLTP e na lógica de negócios que vive de acordo com suas próprias leis e requer o máximo de detalhes. Por outro lado, eles vivem uma vida agitada do sistema de controle de processo de fabricação (MES), no qual fluxos de dados e históricos de valores-chave fluem o tempo todo.

A combinação de hubs, satélites, links do DV2.0 e a granularidade máxima da Ankor permitiram casar tudo isso em um só lugar. Sim, escrever consultas manualmente nesse sistema será difícil, mas todo o seu conteúdo está correto. E podemos garantir a integridade do sistema, mesmo que tudo ao nosso redor de repente comece a mudar ou desmoronar.

Logics. Tendo resolvido a questão da organização da arquitetura no nível físico, passamos à sua descrição lógica. E nossa discussão com colegas mudou-se para um plano filosófico, na tentativa de determinar por nós mesmos o que é a essência e como eles se relacionam. Depois de discutir por um tempo, eles se voltaram para o DAMA-DMBOK, retiraram as definições e aplicaram-no ao seu contexto. Como resultado, constatou-se que as entidades são substantivos com os quais operamos no âmbito da SIBUR, tendo valor comercial completo e respondendo a várias perguntas. Ainda há um debate sobre a inclusão ou não de agregados e relatórios nas entidades. Cada arquiteto tem sua própria opinião, seus próprios cálculos, e agora estamos tentando levar nossos pensamentos a um denominador comum. Essa é uma das tarefas que precisamos resolver, incluindo as pessoas que procuramos como equipe.

Mas o modelo lógico não é tudo. Além disso, também construímos o modelo conceitual de que a administração precisa entender o que está acontecendo. O modelo lógico para eles é muito detalhado, por isso agrupamos tudo em domínios de dados que se encaixam bem nos processos de negócios descritos na empresa. Agora, estamos tentando negociar com o escritório de processos para vincular cada um desses agrupamentos de entidades lógicas aos processos no ARIS.

Além disso, ampliamos ainda mais: criamos um único modelo de dados lógicos, no qual inserimos as entidades lógicas de cada sistema, enquanto indicamos os sistemas de origem indicando a relação dos sistemas entre si.

Exportamos esse conhecimento para arquitetos corporativos no Sparx Enterprise Architect, eles precisam vincular entidades a fluxos e interfaces de integração.
Essa organização da arquitetura de dados ajudará as pessoas que planejam se envolver na análise de impacto no futuro, a partir dela será possível construir uma linhagem de dados completa. Em geral, esperamos que a solução seja usada não apenas por arquitetos de todas as faixas, mas também por pessoas de análises em unidades de negócios, cientistas de dados e todos os que de alguma forma estejam conectados à análise.

Agora enfrentamos uma tarefa mais trabalhosa - como ensinar os funcionários a usar tudo isso.

Pessoas e dados

Nossos planos globais são tornar a SIBUR uma empresa orientada a dados, quando absolutamente qualquer funcionário puder analisar alguma coisa. Dividimos a estratégia geral em três partes - sobre pessoas, processos e ferramentas. Com as ferramentas, pode-se dizer, eles decidiram o problema, criaram sua plataforma com dados. Agora precisamos que as pessoas comecem a usá-lo.

A principal característica é a mentalidade dos funcionários. Eles trabalham em uma indústria petroquímica perigosa, onde a segurança é escrita para todos cujo sangue é escrito. E as pessoas são treinadas para seguir estritamente as instruções, estão literalmente impressas no subcórtex. Tal estado é fortemente contrário ao pensamento livre do analista.

Começamos pequenos: desmamamos gradualmente os funcionários para fazer apresentações em qualquer ocasião mais ou menos significativa e transferi-los para os painéis. Como as pessoas na empresa são responsáveis e executivas, elas tentam fazer uma apresentação pronta e desenhar a mesma coisa em uma versão interativa. Mas os painéis vivem de acordo com leis diferentes e, para uma pessoa, esse é um nível completamente diferente de custos de mão de obra, é necessário carregar todo o histórico dos dados e verificá-los. Os dados tornam-se automaticamente calculados e não manipulados - você não os altera com as mãos, a menos que você os configure inicialmente.

De fato, toda a automação de processos internos termina com um monte de emails do Excel +. E transplantar pessoas com o Excel é uma tarefa quase impossível. Bem, certo, por que precisamos de Python e SQL, porque no Excel você pode fazer tudo! E é muito difícil lidar com isso.

Nas versões anteriores do sistema de gerenciamento de dados da SIBUR, havia o proprietário do arquivo de informações - um funcionário que dá acesso aos dados e sabe onde o número está correto. Essa abordagem criou as barreiras sobre as quais escrevi acima. Para quebrá-los, aproveitamos as “melhores práticas” do Gartner e identificamos separadamente um curador de dados e um responsável pela qualidade dos dados.

Um curador de dados é um gerente no nível do diretor da divisão que determina as regras pelas quais ele está pronto para dar acesso aos dados. O responsável pela qualidade dos dados trabalha diretamente com as informações em si e sabe qual é o valor correto. Agora, estamos trabalhando para garantir que, para cada figura, haja uma pessoa responsável pela qualidade que responderá às solicitações dos colegas em caso de erro ou imprecisão. Já estamos dividindo os dados nas informações disponíveis para todos na empresa, nas informações disponíveis em uma unidade específica e nas informações que representam segredos comerciais.

E se algum gerente quiser fechar dados específicos, realizamos negociações de lançamentos e explicamos como o fechamento de informações afetará outras unidades trabalhando direta ou indiretamente com elas. Assim, a porcentagem de dados abertos na empresa foi radicalmente revisada. Pelos padrões da SIBUR, esta é uma verdadeira revolução.

Conclusão

Temos uma ferramenta pronta, mas até agora há muito poucas pessoas que podem usá-la. E nós os educamos. O processo acelerou visivelmente depois que construímos o processo de treinamento de fãs, quando cada funcionário que treinamos assume a responsabilidade de treinar o seguinte. Adotamos o caminho de treinar nossos próprios funcionários em vez de contratar analistas, porque, no nosso caso, é mais fácil ensinar aos deuses das macros SQL e Python do que a analistas impressionantes para explicar sobre a pirólise e seus recursos. E olhe para os rostos deles ao mesmo tempo.

Como atraímos pessoas e motivamos a estudar é uma história digna de um post separado.

Além de educar analistas internos, também estamos procurando arquitetos, pessoas que tenham conhecimento sobre gerenciamento de dados. Essa é uma nova direção, não apenas para a Rússia, mas também para o mundo como um todo, e as pessoas continuam a interpretar o conceito de arquitetura de dados quanto a isso. Existem histórias compreensíveis com análise de negócios, análise de sistemas, arquitetura corporativa.

Na SIBUR, definimos a arquitetura de dados como uma disciplina na junção de partes do sistema com bancos de dados e processos relacionados aos negócios. Uma pessoa deve entender como a organização em que trabalha é organizada e como os processos deixam dados sobre si mesmos em diferentes sistemas. E como conectar o primeiro ao segundo.