Governança e Gestão de dados na prática-Parte VIII

Performance e desempenho

Representam os processos especializados para medir e avaliar a intensidade de uso e aceitação dos preceitos de GD na empresa. No fundo, são processos emprestados dos modelos consagrados (no mundo de engenharia de software), agora aplicados aos dados. Basicamente definem métricas acerca da Governança e uso dos dados e verifica a sua efetiva aplicação. O DMM-Data Management Maturity Model, do CMMI Institute(hoje, ISACA) trouxe os processos chamados de apoio. Envolvem MED-Medições, GQA(Garantia de Qualidade), GCO(Gerência de Configuração). São formas de averiguar o uso correto das definições, processos, padrões, políticas,etc e que, em última análise, representam o “retorno” do investimento feito na GD. Nesse contexto, trataremos de MED e GQA. MED-Envolve medições nos domínios de Custo, Tempo, Qualidade, Issues (Reputação, etc), “Compliance”,etc. De maneira geral se associam com indicadores de Qualidade de dados(número de erros encontrados periodicamente nos repositórios de dados mestres), número de “issues” de dados resolvidas num certo período, etc.  Além de MED, a performance também envolvem os processos de GQA, que estabelecem mecanismos de auditoria, normalmente presencial, para garantir que os P´s da GD estão sendo cumpridos. Algumas considerações importantes:

•       As métricas nesses domínios de GD e QD(Qualidade de dados) tendem a demorar para produzir visibilidade de retorno;

•       É importante começar por medir pontos críticos do business(processos críticos de negócio), que possam trazer visibilidade  e sugerir uma percepção de que “valeu a pena”;

•       Genericamente objetiva-se reduzir custos, aumentar receita e lucro, melhorar “time to market” , atentar para aspectos de regulação(penas, reputação,etc) , e incidência de “issues” de qualidade. Deve-se sempre balizar o uso dos dados e o retorno da GD com esses parâmetros;

•       Pesquisa/Questionário: Algumas métricas são mais difíceis de serem medidas diretamente. Assim, por vezes, a pesquisa qualitativa de usuários dos dados é fonte importante. Exemplo: Houve melhora no entendimento dos dados?; Houve melhora na percepção de qualidade dos dados? Esses pontos não são facilmente detectados por medidas quantitativas e deverão ser coletadas por levantamento de percepções;

•       Há basicamente dois tipos de métricas: Métricas de resultados de negócios e métricas operacionais(GD, Integração, QD,etc)

•       Métricas de negócios:

–      Redução em multas penalizações/advertências devido a documentos regulatórios não aderentes;

–      Penalizações/multas/advertências por pendências de privacidade;

–      Penalizações/multas/advertências por pendências de reputação;

–      Possível perda em crédito devido a pendências de dados;

–      Possível aumento do custo operacional devido a problemas de dados;

–      Redução nos custos de desenvolvimento por integração de sistemas;

–      Por pesquisa junto aos usuários, observar:

•       Melhora do entendimento dos dados;

•       Melhora na percepção de melhor qualidade dos dados;

•       Melhora na visão preventiva de erros de dados via data profiling;

•       Número de reclamações de clientes oriundo de erros de dados(baixa qualidade);

•       Número de problemas de pendências regulatórias medidos e gerenciados;

•       Houve redução no tempo necessário para limpeza e correção dos dados;

•       Houve redução em tempo despendido com discussões sobre o significado do dado .

•       Indicadores de Governança

–      Percentagem de áreas(assuntos) da empresa sob os domínios da GD;

–      Contador de acesso aos repositórios de metadados, glossário de negócios e portal de GD, indicando interesse e comprometimento com os conceitos;

–      Feedback sobre GD-pesquisas sobre áreas governadas pela GD;

–      Número de participantes em treinamento de GD e DQ;

–      Uso de elementos padrões de GD: códigos, processos, modelos, padrões, procedimentos,etc-MED de GQA;

–      Issues(pendências)  resolvidas pelo Comitê de  GD/Issues(pendências)  incidentes;

–      Issues(pendências) escaladas para o Conselho de GD/Issues(pendências)  incidentes;

–      Revisões de desempenho realizadas (nas métricas de GD).

•       Indicadores de integração

–      Número de usuários e acessos às fontes MDM;

–      Percentagem de redução de acesso a Bancos de Dados departamentais e planilhas locais.

•       Indicadores de QD:

–      Contador de ocorrências  de tipo  de erro XX/período;

–      Percentagem de “accuracy”/precisão  dos dados em arquivos críticos;

–      Perdas de pedidos on-line ou de produtos retornados devido à gerência com erros de informações de catálogos(dados mestres);

–      Perdas de clientes devido a erros de qualidade de dados;

–      Resultado de Profiling de dados, mostrando os diversos indicadores de completude, precisão, integridade, etc.

•       Indicadores de segurança e privacidade

–      Número de incidentes relativos aos aspectos de segurança de dados(vazamentos, reclamações , breaches,etc).

Importante: As medidas acima são exemplo. As Medidas/Métricas/indicadores deverão ser definidas em função de objetivos / diretrizes estratégicas de negócios.

Por que as medidas de Performance são importantes?

·       As métricas , devidamente escolhidas, devem ajudar no alcance de objetivos de negócios

·       As métricas não têm valor se não estiverem alinhadas com o interesse dos envolvidos na GD, seja de negócios ou de tecnologia

·       Sempre definir as métricas a partir dos objetivos de negócios dos envolvidos e da GD

·       Sempre traduza os resultados das métricas numa linguagem dentro do alcance dos envolvidos

·       Embora existem exemplos de métricas, como mostradas anteriormente, é fundamental que cada empresa (e cada programa de GD) tenha um processo de definição desses indicadores e métricas. Sempre parta dos objetivos a serem alcançados, dos problemas a serem resolvidos, entendendo claramente esses elementos(de novo o Why e o What do processo da medição). Conceitualmente uma métrica é uma medida estabelecida sobre algum processo ou elemento. Uma KPI é uma métrica mais elaborada que , por exemplo, será aplicada para se medir a evolução e o desempenho do programa de GD.

·       Observe que uma medida deverá ter metadados: nome, descrição, objetivo, fórmula/cálculo, unidade, mecanismos para coleta de dados, periodicidade, meios de armazenamento, formas de interpretação, com faixas e valores e critérios de aceitação.

Palavras(Comunicação)

Representam os processos de comunicação do que está sendo feito sobre os dados na empresa. Por se tratar de um desafio cultural, a comunicação é um dos fatores críticos de um programa de GD. Através dele, as diversas áreas partícipes observam o seu grau de contribuição no movimento, as outras áreas são notificadas de Processos, Políticas, Padrões e outras definições institucionalizadas e a GD percebe a receptividade de suas ações e produtos. Todas as formas de eventos que dizem respeito aos dados são divulgadas e a cultura “data driven” se capilariza por entre o tecido estrutural da organização, via processos de comunicação.

Por que a Comunicação é importante?

·       A comunicação pro-ativamente encaminha as possíveis mudanças a serem realizadas

·       Ajuda na sensibilização e conscientização da importância dos movimentos da GD na organização

·       Cria alinhamento de expectativas e de ações entre áreas

·       Estabelece um mecanismo de feedback e de envolvimento entre os participantes

·       Ajuda a responder alguns W e H dos 5W2H

·       Pense num Plano de comunicação, envolvendo informações qualitativas, quantitativas(métricas de performance, discutidas anteriormente), a frequência ,  os alvos(targets) da comunicação, os mecanismos usados e os responsáveis pela comunicação.

Exemplo prático:

o   Neste exemplo “driver”, há incidência de problemas de dados que deverão ser medidos efetivamente pelo processo de Performance. Os dados de possíveis erros existentes nos arquivos envolvidos (Mestres, Referenciais ou Transacionais), detectados por análises de profiling poderão ser indicadores importantes para confirmar os problemas levantados no Why do Canvas MGD. As medidas levantadas acerca de problemas de agendamento e cancelamento de consulta também poderão ser medidas definidas. Os aspectos de “compliance” com a agência reguladora sugerirá indicadores de autuações e glosas incidentes. Essas métricas deverão ser analisadas, definidas, implantadas e acompanhadas durante períodos estabelecidos para verificar a consistência estatística da informação. Deverão produzir tomadas de ação. Toda métrica deverá ter ações associadas com os seus limites definidos(acima ou abaixo dos thresholds)

o   Os aspectos de comunicação, nesse exemplo driver, deverá se iniciar, com um evento envolvendo as áreas que estão no domínio do problema e da solução (GOP, GPC, riscos, etc). Essa ação e outras, deverão estar definidas num plano de comunicação, com informações recorrentes sobre o andamento das medidas adotadas e dos resultados retornados, o que servirá de elemento de apoio às mudanças propostas e efetuadas.  

Conclusão: Assim, concluímos a aplicação dos conceitos de P´s da Governança ao longo deste projeto hipotético aqui desenvolvido. A figura 08 abaixo, é republicada para ilustrar o Canvas P, que serve como balizamento para as ações descritas. 

Referências:

Baker, B. How to design visual templates: and 99 examples. Creative Commons license. 2016.

Canvas-MGD-Melhoria de Gestão de Dados-Carlos Barbieri-CBCA-Material treinamento (2014-2015).

Canvas-P da Governança de Dados-Carlos Barbieri-CBCA-Material treinamento (2014-2015)

DAMA-DMBOK2-Framework-Patricia Cupoli; Susan Earley; Debora Henderson-Set. 2012.

Giordano,A. Performing Information Governance-A Step-by-Step to making Information Governance work. IBM Press.2015.

Ladley, J. Data Governance-How to design,deploy and sustain effective Data Governance Program. Elsevier-2012.

Learning 3.0-Alexandre Magno-Happy Melli-Material de Treinamento-Junilson Souza (Facilitador)-2015.

Soares, S. Data Governance tools-Evaluation criteria, Big Data Governance and alignment with Enterprise Data Management. MC Press-2014.

The DAMA Guide to Data Management Body of Knowledge(Dama-DMBOK Guide)-First Edition 2009.

Williams,B. Data Governance by Example.Databaseanswers.org.2012 .

Governança e Gestão de dados na prática-Parte VII

Pessoas e Papeis:

Representam os recursos humanos, suas atribuições e capacitações para o desempenho de papeis no âmbito da Governança e Gerência de dados. Há a definição formal de papéis, responsabilidades e “accountabilities”, sendo esta definida como responsabilidade final. Poderá haver diversos tipos de estruturas organizacionais para abrigar essas pessoas e o desempenho de seus papeis. Cada empresa deverá buscar o seu modelo, dependendo de suas especificidades. Por exemplo, empresas que são globais poderão ter GD descentralizadas, unidas por um Conselho ou Comitê global. Empresas que são centralizadas poderão ter uma estrutura mais canônica de GD, com um Conselho de alto “board”, um Comitê tático que envolve os Gestores de dados líderes e a camada operacional com os diversos tipos de gestores de dados(de negócios a operacional). Nessa formulação, os aspectos de integração funcional com a área de TI é fator crítico, bem como a definição de um DMO, ou Grupo de condução da GD na empresa, numa espécie de Escritório de Dados. Um ponto fundamental é o treinamento que deverá ser conduzido na preparação desses recursos. Envolverá a discussão dos P´s da GD mais convenientes às suas funções. Dos papeis normalmente definidos, dois são fundamentais de serem destacados:

•       Data Owners/Data Stewards:  O data owner representa  “a área responsável”  ou “accountable for” pela função de negócios, responsável pelo estabelecimento  do significado dos dados (definição)  e das regras de negócios(criação, uso e qualidade daquele dado) que o contextualizam.

•       Trabalham em conjunto com os seus Gestores de dados(Data stewards) que são, na camada operacional, os responsáveis pelos aspectos de uso, integridade e qualidade dos dados. São também responsáveis pela definição do Metadados e  dos dados  do Data Owner. Os Gestores de dados podem ser classificados em Gestores de dados de negócios, Gestores de dados técnicos(mais envolvidos com TI), Gestores de dados de projetos(participam de projetos com o olhar de dados e seus controles, Gestores de dados de Domínio(quando o mesmo dado mestre é usado de forma compartilhada por várias áreas de negócios e exige uma visão reguladora, com tom organizacional). Claro que, as empresas iniciantes em GD deverão ter somente os papéis mínimos para a decolagem do programa(Gestores de dados de negócios, por exemplo, em diálogo com a TI-Gestores de dados técnicos).

•       Um ponto fundamental na definição das pessoas/papéis é a formação de estruturas de comando e apoio do programa de GD. Poderá envolver diversas configurações estruturais. Na essência, deverá haver no topo da estrutura um “board” , formado pelos altos executivos que sejam responsáveis pela busca do Patrocínio à GD e pelo apoio financeiro. Abaixo poderemos ter um corpo diretivo do programa de GD, com os owners de dados, CDO,etc, responsável pela condução estratégica das ações e pela resolução de “issues” que escalem depois de passadas por camadas táticas e operacionais. Num nível seguinte , terá um “board”, composto por Gestores de dados líderes, com reuniões mais frequentes(por exemplo semanais), acompanhando o desenrolar dos trabalhos dos seus gestores de dados e tratando da ligação entre essas unidades organizacionais. Atrelado a esse grupo, pode-se ter o Grupo de implementação da GD na empresa, aqueles que fazem a roda rodar, do ponto de prático na empresa. Em implementação de melhorias de processos de software, que já fizemos em mais de 100 empresas, seria o chamado SEPG(Software Engineering Process Group). São eles que dialogam com todos, servindo de ponte com a consultoria, eventualmente presente para apoiar a implantação de GD. É a base do futuro(ou do já definido)  escritório de dados, ou DMO. Na camada de baixo, os diversos gestores de dados de negócios, nas suas respectivas áreas, cujo líder tem assento no board imediatamente acima e cujo “owner” de dados, responsável pela UO, ou LOB(Linha de negócios)  participa no nível de condução do programa. Repetindo: Cada empresa deverá buscar essa sua conformação estrutural, de acordo com a sua cultura, disponibilidade de recursos e propensão favorável à implantação da GD na empresa.  

Exemplo prático:

Neste exemplo “driver” que estamos discutindo, podemos, definir que  GOP-Gerência de Operações(envolve consultas, atendimentos/agendamento) e a GCO-Gerência de Compliance, além da TI, seriam as áreas que estariam na formação inicial da estrutura de GD. As respectivas chefias formariam o nível executivo, com os Owners de dados; os gestores de dados escolhidos de acordo com o (seu já existente) envolvimento com os dados mais críticos da respectiva UO(Unidade organizacional) e uma definição de liderança tática para compor o grupo de supervisão semanal dos trabalhos. Um conselho de supervisão, de mais alto nível, formado por outros líderes da organização, poderia ser formado, com o intuito de buscar apoio e fundos para a implantação do Programa de GD.  

Programas/Projetos /Planos:

Representam as ações efetivas que são realizadas para a implantação da Governança e Gerência  de dados, ou de projetos de dados que estarão no foco da GD.  Normalmente envolvem programa de GD com Projetos de DW/BI, MDM, Segurança, Big Data, IoT, Qualidade, Metadados, Compliance, etc. Uma estratégia vencedora é a definição de um programa estruturante a longo prazo com um projeto “trigger”, que permita obtenção de resultados rápidos e visíveis acerca dos primeiros movimentos de GD. Poderão começar com um Plano mais estratégico de dados, associado aos objetivos de negócios da empresa e um programa estruturante, com um conjunto de projetos que materializem os objetivos da GD. Os projetos de dados serão tratados como projetos tradicionais, afora a sua especificidade em dados, com a criação colateral das estruturas de GD necessárias para o seu apoio e acompanhamento.

Exemplo prático:

Neste exemplo “driver” que estamos discutindo, podemos entender, que em função dos problemas levantados, deveremos seguir em direção a projetos que atenuem aspectos de Compliance, com recorrentes ações de fiscalização da ANS-Agência Nacional de Saúde Suplementar, produzindo autuações/notificações sobre dados não condizentes acerca de atendimentos, consultas, protocolos clínicos e também reclamações sobre demora em tempo de atendimento. Vamos considerar, por hipótese, que os problemas estão por conta de dados inconsistentes, com lacunas de informações entre os relatórios enviados, além de reclamações sobre atendimentos que ultrapassam o tempo máximo definido pela ANS. Aqui podemos caracterizar quantitativamente ou qualitativamente a incidência e os impactos dos problemas. Assim, na essência observa-se, problemas de consistência nos dados de regulação e a necessidade de levantamento de dados sobre  processos de marcação e atendimento de consultas. Outro ponto sugerido no plano estratégico da organização e que poderia ser trazido à discussão nesta sessão ou em outra, é a proposição sobre “monetização” dos dados. Com esses problemas inicialmente identificados, começaríamos um detalhamento de ações, que poderão ser traduzidas em alguns projetos drivers. Por exemplo, uma aplicação analytics com relatórios rápidos para se aferir os problemas de marcações e atendimentos. Uma análise de profiling dos dados poderia ser feita , visando a detecção de possíveis problemas existentes nos cadastros, que impactem os aspectos de compliance. Por fim, um grupo de trabalho poderia ser formado, visando aprofundar o estudo sobre formas de monetização dos dados de saúde, com um detalhamento sobre dados potenciais, riscos de privacidade, anonimização de dados, mercados potenciais,etc.

Plataformas e Arquiteturas

Representam as camadas necessárias de ferramentas e tecnologias para se implementar adequadamente as funções de Governança e Gerência de dados. Passam por ferramentas de apoio direto aos dados, como Gerência de Metadados e estruturação de catálogos organizacionais de dados (Glossário),  e por ferramentas de tratamento físico de dados, como Profiling, Limpeza, Enriquecimento, Integração, etc. Outros elementos, acessórios, comumente já existentes hoje nas empresas:

• Ferramentas e camadas para controle da Arquiteturas de Dados associada à Arquitetura Corporativa(Negócios, Processos, Sistemas, Tecnologia,etc),  como  “tools” para Modelagem de dados, Modelagem de processos, BPM,etc ;
• Ambiência de tecnologia, envolvendo ferramentas  de SGBD, ferramentas de DW/BI, Analytics e Data Science como Big Data, Hadoop/MapReduce e sucedâneos(Spark, Storm,etc), além de softwares de análises estatísticas,etc.

Considerações fundamentais:

·       Nunca compre um elemento de tecnologia sem saber corretamente o objetivo de sua aplicação e o valor potencialmente retornado naquele investimento. Por vezes, na TI, as compras de recursos tecnológicos são altamente impulsivos e direcionados por fatores variados;

·       Para Governança e Gestão de dados, os trabalhos iniciais poderão ser feitos com ferramental (normalmente já) existente nas empresas como EPF, SharePoint e o conhecido Excel/Office. Mas haverá momentos em que esses produtos provarão certa insuficiência, como por exemplo, na criação de glossários e tratamento de volumes grandes de dados. Nesse ponto, você poderá ser instado a pensar em algo mais robusto; 

·       Avalie sempre as necessidades iniciais que o programa de GD tem: Glossário de dados, Controle de Políticas, Qualidade de dados, antes de decidir por qual caminho definitivo seguir;

·       Pense sempre em treinamento , apoio e suporte dessas ferramentas. Embora hoje esteja tudo em “cloud”, não desconsidere um apoio competente e profissional ;

·       Na área de Governança, Gestão e Qualidade de dados  há um conjunto de ferramentas que variam de estilo:

o   Ferramentas associadas às grandes marcas: IBM (família Infosphere), Oracle (Enterprise Data Quality),SAP e MS(esta menos um pouco), tem suítes para tratamento de dados nesses domínios. A empresa Informática, que atua verticalmente nesse segmento, também pode ser considerada um nome forte. Faz par com a SAS, presente aqui no Brasil em aplicações mais estatísticas e analíticas. Essas ferramentas, normalmente, oferecem módulos integrados que atuam no domínio de dados, integração, metadados, limpeza, enriquecimento,etc. Mas podem variar no seu poder de fogo;

o   Há ferramentas, menos conhecidas no Brasil, mas muito fortes nos EUA e Europa. É o caso da Collibra, empresa belga, que tem uma presença de destaque nos EUA e na Europa. Pelas apresentações que assisti nos EUA e em conversas com usuários lá e aqui(no Brasil acho que não há mais do que 3-5 usuários), é muito potente na gestão e governança de dados, porém exige alto investimento. Uma única licença de uso pode chegar a alguns milhares de dólares/ano. Outra ferramenta que começou bem neste segmento, mas hoje se encontra em reposicionamento de mercado é a ASG-Rochade(empresa da Flórida). Conversei recentemente em DelRey Beach com seu representante e a minha percepção é de reposicionamento da ferramenta, depois de um “merge” da companhia. Na Europa há o produto francês Orchestra, com suíte dedicada a Governança e MDM, que tenta abrir espaço nos EUA. Está sempre presente nos “boothes” das feiras internacionais de dados. Outras como a Adaptive, Trillium, Talend e Datum  são participantes deste mercado com alguma expressão, por vezes, presentes no quadrante mágico do Gartner, ou nos círculos concêntricos da Forrester, mas sempre afastadas das empresas “big shots”. Mas merecem ser observadas.

Exemplo prático:

o   Neste exemplo “driver”, plataformas deverão ser pensadas. Além das provavelmente existentes na área de BI/Analytics, outras no domínio de qualidade de dados e profiling, e de metadados e glossário de negócios seriam potenciais opções a serem analisadas,  à princípio. 

Governança e Gestão de dados na prática-Parte VI

Processos:Considerações e exemplos

É o “Como fazer” (How). Constitui  um conjunto de atividades, com entradas, saídas,  participantes( pode usar uma matriz RACI), ferramentas, recursos humanos, outros recursos, treinamentos, controle, monitoração de performance, etc. O processo deverá ter um objetivo claro dentro do escopo de dados. Deverá ser aprovado, promulgado, documentado, disseminado via treinamento e internalizado no dia a dia da empresa/área target. A sua execução deverá ser medida e acompanhada. O conceito de definição de processo é o mesmo aplicado em CMMI, MPS, etc, com um conjunto de passos(atividades), produtos e responsáveis. Os processos são elementos dinâmicos e deverão ser revistos periodicamente visando a sua evolução e ajustes. Os processos são medidos(via processos de MED) e avaliados na sua execução(via processos de GQA), a fim a garantir a sua aderência aos pontos definidos.

Por exemplo, a seguir um  exemplo de processo definido para solicitação de alteração de modelos conceituais de dados:

-----------------------------------------------------------------------------------------

•       Analista de sistemas(AS) interpreta/analisa os requisitos de dados

•       Analista de sistemas(AS) faz o modelo inicial lógico de dados, com inclusão /alteração de  entidade(s) existente(s)

•       AS envia modelo ao Gestor de dados de negócios(GDN) para revisão de padrões e definições de domínios de dados

•       GDN revisa o modelo e analisa a coerência  com os modelos lógicos existentes 

•       Uso de Check list de avaliação(Procedimento)

•       GDN planeja a sessão de revisão com  Comitê de GD, TI, AD, outros envolvidos(integração)

•       Avaliam impactos no modelo conceitual de dados

•       GDN cria ou modifica os elementos lógicos de dados passíveis de atualização

•       Se aprovado, envia ao ABD para a modificação do modelo físico em ambiente de validação

•       ABD aplica check list para aceitação do Modelo(Procedimento)

•       ABD realiza a alteração e comunica interessados e envolvidos

----------------------------------------------------------------------------------------

Procedimentos:Considerações e exemplos

São considerados detalhamento de processos ou subprocessos, que poderão ser aplicados de forma recorrente e fatorada(usada em outros processos). Representam um detalhamento mais operacional e mais focado sobre um certo conjunto de atividades. Dentro de processos como Medição(MED), GQA(Garantia da Qualidade) e GCO(gerência de Configuração) há procedimentos de check-list de pendências do processo de Segurança(manutenção de senhas) ou  de auditoria funcional de Baselines(GCO) de modelos conceituais de dados, por exemplo.

Outros procedimentos na esfera de Governança e Gestão de dados:

•       Revisão das Entidades: Observar se

–      A Entidade está na 3ª forma normal; há outra Entidade de natureza semelhante ou uma subtipo semelhante no modelo corporativo; há definições detalhadas da Entidade ou da subentidade, ou seja metadados definidos;os nomes propostos estão dentro dos padrões organizacionais.

•       Revisão de relacionamentos: Observar se

–      A cardinalidade está correta; a opcionalidade está correta; os relacionamentos possuem nomes inteligíveis em ambas as direções; os nomes fazem sentido para o analista de negócios e usuário final.

•       Revisão de Atributos: Observar se

–      Os atributos estão com o nome definido dentro dos padrões organizacionais; os domínios associados foram usados corretamente; há comentário para cada atributo; há descrição detalhada para cada atributo no dicionário de dados ou mapeamento no Glossário de negócios da organização; há atributos derivados, com regras de derivação definida.

•       Revisão de Identificadores: Observar se

–      Há para cada Entidade, pelo menos um identificador único; o identificador é um chave de negócios ou uma SK(Chave substituta); há chave de Entidade que é atualizável.

•       Revisão Geral: Observar se

–      O sistema é um OLTP ou OLAP; as tabelas e colunas estão mapeadas em entidades e atributos do modelo corporativo; no caso de projetos de DW/BI-DM há os dados equivalentes no ambiente Transacional, com exceção dos dados derivados. Para esses há regras definidas.

•       Revisão de Tabelas: Observar se

–      Há outra Tabela de natureza similar no Modelo Físico de dados; há comentário em nível de Tabela; há definições detalhadas de cada Tabela

–      Há tabela que requeira “journal” especial, ou “audit trail” para modificações? Se sim, como será feita( via trigger, API,etc); há tabela que esteja desnormalizada com um racional explicando os motivos; as tabelas estão definidas de acordo com os padrões de nomes e abreviações organizacionais.

•       Revisão de Colunas: Observar se

–      Há coluna de auditoria definida?(ex: data/hora da última atualização); há comentários e descrição para cada coluna; há colunas derivadas de outras colunas e as respectivas regras/fórmulas de derivação; os nomes das colunas estão de acordo com os padrões organizacionais; os domínios foram aplicados corretamente.

•       Revisão de Restrições de Integridade: Observar se

–      Todas as tabelas tem restrições de PK(chave primária); deve haver uma restrição de unicidade secundária definida(além da PK);  as chaves estrangeiras foram definidas corretamente; há restrições de Delete Cascade, Restriction,etc ; há restrições de CHECK em nível de colunas.

•       Revisão de implementações em NOSQL

–      Há documentação externa dos dados, na forma de diagramas conceituais para dados implementados em estruturas de chave-valor, documentos, multicolunar e grafos.

–      Aplicar os aspectos de controle desenvolvidos para dados focados em novas formas de armazenamento, como estruturas Hadoop e suas variantes; considerar armazenamento em estruturas com DNE(Dados Não estruturados) nas formas mais variadas; considerações como schema on read somente(sem schema on write);considerações sobre Data Lake(Repositório intermediário contendo dados de todos os formatos); considerações sobre transacionalidade(ACID-BASE). Maiores detalhes em Governança de dados para Big Data. 

A execução apropriada desses procedimentos será verificada pelas auditorias em sessões programadas, de GQA-Garantia da Qualidade(não exige conhecimento técnico) ou por revisões por pares(VER-Verificação, com conhecimento técnico). Isso gerará medidas que mostrarão a performance dos processos, via o processo de MED(Medições).