Total de visualizações de página

segunda-feira, 16 de dezembro de 2013

Maturidade em Dados-DMM-Data Maturity Model-Parte VI


A última categoria do DMM Qualidade de Dados tem também dois grandes componentes, com 6 áreas de processos. O primeiro componente é FRAMEWORK DE QUALIDADE DE DADOS  e o segundo é GARANTIA DA QUALIDADE DE DADOS, conforme a figura DMM-08, abaixo.


Figura DMM-08- Qualidade de Dados

Esse componente trata do assunto que , no fundo, é o objetivo final de tudo isso. A Qualidade dos dados e as suas consequências e benefícios. A categoria tem dois componentes: Um trata da estratégia a ser adotada, definida num framework e o outro trata da Garantia da Qualidade de Dados. Simplificadamente uma forma de planejar e a outra de aplicar. O framework de Qualidade de dados inicia com um processo chamado Desenvolvimento da Estratégia de Qualidade de dados(32) Esse processo visa definir os planos de ação para a melhoria do estado corrente de Qualidade dos dados(QD) para atingir os objetivos da organização. Deve ser uma  estratégia de QD definida baseada  na análise do estado corrente de qualidade de dados comparado com os requisitos de qualidade necessários  para alcançar os objetivos  de negócios e planos estratégicos. Ela deverá estar  alinhada com os objetivos gerais de GD e ligados com os requisitos de negócios. O objetivo central é criar uma cultura compartilhada de QD começando com a gerência executiva e integrada  ao longo das operações da empresa. A fim de realizar isso, a empresa deve concordar com um perfil consistente de QD que possa ser medido ao longo de múltiplas unidades de negócios e aplicações. Isso permitirá aos patrocinadores de negócios, usuários de dados, apoio de infra e gerência sênior  se ligarem aos processos de gerência de QD para quantificar valores(ROI, etc) e alinhar com objetivos como risco computacional, transparência, melhores análises, automação de processo de negócios, serviços de clientes, capacidade de aderência e perdas de oportunidades. 

A seguir vem Medição e Análise da Qualidade de Dados(33) que objetiva definir as atividades  para medir qualidade de dados através do seu ciclo de vida, incluindo a criação de objetivos das medidas, bem como o mecanismo de obter, armazenar, analisar, abstrair, agregar, reportar, interpretar e iniciar ações de correção , caso apropriado. Deve-se definir um processo de medição de qualidade  de dados associado com a implementação de um sistema para gerenciar as ações corretivas. As medidas produzem um meio de feedback estruturado para os stakeholders e ajudam  a sinalizar pontos a serem observados e gerenciados e mantem a GD alinhada com os objetivos de negócios. Medições e análise incorporam análise das necessidades de clientes; o projeto, desenvolvimento, modificação e execução das regras de negócios;  implementam mecanismos de revisão de custo/benefício; e priorizam iniciativas de melhorias em QD baseadas em critérios de ROI da empresa. A medição de QD pode ser extremamente útil quando apresentada como “scorecards” para stakeholders, ajudando a sua compreensão e interpretação. Quando projetando o programa de medições  de QD é importante focar em: o processo que dispara a necessidade das medições ;  como  ações corretivas são integradas ao processo de GD; a revisão de governança de medidas para garantir que elas permanecem relevantes aos objetivos de negócios e  ênfase de medições nos pontos mais críticos dos processos de negócios. No fundo esse processo está associado com o processo de apoio de medições do CMMI(MA) e do MPS.BR(MED) e com o processo Medições(11) do DMM e deve, objetivamente, desenvolver um conjunto de métricas de QD para satisfazer os requisitos de negócios.
Dentro do componente de Garantia da Qualidade de dados há o processo de Data Profiling(34) que visa definir  um  processo de identificação do real  estado e  significado e da estrutura dos dados correntes. É um dos primeiros passos associados com as boas práticas de GD. É um processo  crítico e ainda muito negligenciado . Muitas organizações fazem o “profiling” de seus dados quando estão implementando um DW, carregando  repositórios de metadados, realizando uma migração operacional, planejando integração ou qualquer outro ponto quando os “data stores” são significativamente modificados. É um dos ingredientes chaves para uma abordagem de GD com sucesso. O processo de “profiling”  de dados é visto como um conjunto de esforços de descoberta “do que” está armazenado nos BD e como os valores  podem diferir daqueles listados em repositórios de metadados(de suas definições). Profiling normalmente examina as áreas como valores de dados, range de  valores de dados, distribuição de frequência, falta de coerência com o metadados, algumas estatísticas, formatos não padrão de registros, etc . Muitas estratégias de convencimento de GD começam justamente por aqui, apontando os riscos de “data flaws” encontrados nos seus arquivos fundamentais.
A seguir vem o processo de Avaliação de Qualidade de Dados(35), que objetiva Realizar a avaliação de QD envolve a combinação de metodologias, processos, e regras de negócios usadas nas medições e análise de QD. A avaliação de  QD conduz a um plano de  melhoria formal de QD para alcançar expectativas de qualidade e é necessário para apoiar processos de negócios. O objetivo da avaliação de QD é medir a QD e priorizar melhorias(se necessárias). O output da avaliação será no formato de “scorecard”  que poderá ser usado para avaliar  iniciativas de melhorias de QD e garantir que estão alinhadas com as tolerâncias de riscos, limites de exposição, obrigações de stakeholders  e objetivos de negócios da organização. Sinteticamente objetiva: Estabelecer e sustentar um plano de melhoria de QD baseado em “scorecard” de QD e desenvolver, refinar e usar as métricas de QD em alinhamento com os objetivos de negócios da empresa e expectativas de efetividade.
A seguir vem Qualidade de dados de integração(36) que objetiva garantir que os dados tem padrão de qualidade ao longo do seu ciclo de vida de tal forma que podem ser integrados em “data stores” operacionais  e atendem aos requisitos de usuários de negócios. De novo manifesta preocupação com o fator “integração”. Foca na gerência da QD(incluindo a identificação de conteúdo faltante, processos de enriquecimento de dados, validação contra padrões internos) para prevenir erros antes que os dados sejam propagados através de ambientes de produção. Atividades associadas com QD na integração cobrem o estabelecimento de padrões de QD com fornecedores, uso de aparato estatístico, estabelecimento de limiares e  faixas de tolerância para vários uso de dados em coordenação com data owners/data stewards e a criação de mecanismos de comunicação bidirecional com fornecedores. Essa atividade também cobre todos os passos que devem ser tomados para qualquer correção de erros de dados que sejam descobertos. Procura estabelecer gerência consistente de qualidade no ponto de entrada dos dados e também em múltiplos pontos de “checkagem”; estabelecer , avaliar e refinar padrões de QD para fontes internas  e externas de dados; gerenciar pontos de inserção de erros como  conversão, transformação e processos de enriquecimento de dados de forma que os dados  estejam em condições satisfatórias antes de entrar no ambiente operacional.

Finalmente vem o processo de Limpeza de dados(37) que visa definir mecanismo, regras e processos usados para validar dados contra conjunto predefinido de regras de negócios e corrigir dados imprecisos. O processo de limpeza de dados foca na correção de dados para atender aos requisitos de usuários finais , como medido pelas regras de negócios de QD contemplando várias dimensões de qualidade(precisão, completude, consistência, timeliness(disponibilidade),conformidade,etc). As regras de negócios são críticas na medida em que provêem um mecanismo padrão para identificar anomalias que podem ser ligadas a processos operacionais. A limpeza de dados deve ser realizada no ponto mais próximo da captura dos dados e deve ser precedida por um profiling de dados, avaliação de regras de negócios e análise de conformidade. Deve haver uma estratégia clara definida (com owners) para limpeza de dados para garantir  que as regras de limpeza sejam conhecidas e para evitar processos de limpeza duplicados em múltiplos pontos do ciclo de gerência da informação. O objetivo geral é limpar os dados no ponto de captura baseado em regras de negócios documentadas e verificadas. As correções de dados devem ser comunicadas para( e alinhadas com) todos os repositórios “downstream”(impactados na sequência do fluxo) e sistemas “upstream”(de onde se originaram os dados). É importante ter um processo consistente e documentado para escalonamento de “issues” e verificação de alterações para  provedores (originadores)  internos e vendedores externos   de dados .

segunda-feira, 11 de novembro de 2013

Maturidade em dados-DMM-Data Maturity Model-Parte V



Plataforma e Arquitetura:
A categoria Plataforma e Arquitetura de GD tem dois grandes componentes, com 6 áreas de processos. O primeiro componente é FRAMEWORK ARQUITETURAL  e o segundo é PLATAFORMA E INTEGRAÇÃO, conforme a figura DMM-07, abaixo.

Figura DMM-07- Plataforma e Arquitetura

O Primeiro componente da Categoria Plataforma e Arquitetura é o Framework Arquitetural. Ele é composto de duas áreas de processos. A primeira é a Padrões Arquiteturais(26). Esse processo objetiva a identificação de padrões de arquitetura que serão usadas na empresa, sob a visão de GD. É  como se olhássemos a arquitetura de dados, nas suas diferentes nuances: modelagem de dados, modelagem de mensagens(SOA, Mensageria), metadados, dados transacionais(legados,ERP), dados analíticos(DW,DM), Big data(Sharding,Sand Box),dados não estruturados(Content Management), distribuição de dados(MPP), integração(ETL),etc. Cria uma visão lógica e ampla da arquitetura de TI com os elementos de dados e inclui sistemas operacionais, ETL-Extração, Transformação e Carga e linguagens. Incluem orientações para adaptações no caso de se ajustar determinadas arquiteturas para certos ambientes operacionais, demandados em projetos. Sugerem padrões que incluem guias relativos a :  escolha de hardware e sistemas operacionais, regras associadas com níveis de manutenção de hardware e software; padrões de criptografia e segurança; expectativas de performance para vários tipos de operações de dados, como “analytics” e transacionais; importação e exportação de dados , auditoria, retenção e métodos de acesso para diferentes tipos de data stores; opções de projeto de bancos de dados; regras de normalização; formatos de armazenamento e acesso; guia para espaço de tabelas e limitações; projetos de MDM(abordagem de registry/index, híbrido, federada, single master,etc); regras de tradução de dados; métodos de interfaces e API; padrões de qualidade,etc. Na essência envolve: Padrões de arquiteturas (relacionadas a dados), políticas e regras de aderência a elas; acompanhamento e manutenção desses padrões; possíveis alterações e evolução deles.
O processo seguinte deste componente é Abordagens Arquiteturais(27). Esse processo define a  arquitetura de processo  e arquitetura técnica usada para adquirir, produzir, armazenar e entregar dados às aplicações consumidoras e unidades de negócios. Objetiva projetar um framework de produto  e  processo que atenderá às necessidades da empresa  e que seja seguro, confiável, adaptável e consistente com os padrões estabelecidos. O output é uma visão lógica que se transforma no “blueprint” desejado para a  abordagem arquitetural usada para as  implementações específicas .  A arquitetura é traduzida em um “roadmap”  de implementações de TI, de acordo com a realidade orçamentária, que incorpora aderência com  as abordagens padrões, definidas anteriormente. Pode ser entendida como a aplicação dos Padrões arquiteturais, vistos anteriormente, em projetos e situações específicas. Em linguajar CMMI e MPS.BR seria algo como a arquitetura padrão adaptada para a criação da arquitetura definida. Na essência envolve:  Foco na arquitetura; arquitetura a ser implantada, documentada, analisada e aprovada contra os padrões definidos; fluxo dos dados por entre os elementos da arquitetura; coerência com as plataformas(PA seguinte) onde será “deployed”.
O outro componente desta categoria é PLATAFORMA e INTEGRAÇÃO. O anterior falava de arquitetura, digamos numa visão mais conceitual e este fala de Plataformas, uma visão mais estrutural. Arquiteturas estabelecidas sobre plataformas e plataformas recebendo arquiteturas de soluções. Nesse componente há 4 PA´s ou processos. A primeira PA é a Plataformas de GD(28). Esse processo visa definir as plataformas em função dos requisitos de dados e das arquiteturas definidas . O processo visa também interpretar o ambiente tecnológico como um sistema único, gerenciado por um conjunto de instruções, por uma entidade de negócios definida. São definidos pontos de como a plataforma será gerenciada e como os sistemas a integrarão. Um passo importante nesse processo é realizar um inventário das plataformas existentes, com sistemas e capacidades para analisar a sua oportunidade de reutilização. A visão de plataformas deve ser um projeto plurianual, dentro de padrões organizacionais definidos e com “blueprint”(esquema/arquitetura) aprovados para facilitar integração. Aspectos de restrições de acesso e de configuração são considerados na gerência das plataformas. A integração das plataformas é um fator a ser considerado. Na essência envolve: conjunto de sistemas de  registros de dados(arquivos,BD) e plataformas como SAP,Oracle,DB2, IBM-InfoSphere,etc

A seguir  vem a PA associada com Integração de Aplicações(29). Esse processo descreve como as aplicações existentes serão reconciliadas e integradas no ambiente arquitetural de dados. Tem como objetivo garantir que o dado mantido pela organização possa ser gerenciado de forma que seja consistente com o seu objetivo original  e numa forma que permita que o ele(dado) seja eficientemente usado pela organização.  Integração é o coração da atividade de GD e é  um fator crítico a ser pensado antes que a organização possa obter os benefícios associados com o investimento no projeto arquitetural. A complexidade dos componentes de integração pode ser grande, tornando crítico que os envolvidos relevantes entendam os componentes, relacionamentos e dependências associadas com as entregas de projeto; mantenham  uma “visão longa”  sobre o estado final; entendam a natureza iterativa do objetivo da integração  e mantenham flexibilidade quando defrontados com obstáculos de integração. Usuários de negócios necessitam entender o processo de integração e a lógica de decisão que precisa ser aplicada na arquitetura. Entender as necessidades de TI para definir o processo de tomada de decisão do negócio, as regras de negócios e a lógica por traz  das regras de negócios se o processo de negócio tiver que ser  efetivo. A falta de clareza nos requisitos e a pobre tradução entre TI e negócios pode causar dano(ruptura) na realização dos benefícios do programa  de GD. Requisitos de negócios, abordagens de TI e múltiplas visões de dados na organização necessitam ser verificados (e reverificados) numa forma contínua para garantir que esses relacionamentos estejam corretamente entendidos. Na essência envolve: Integração de plataformas , arquiteturas e dos dados, em última análise de dados. Envolve planos de integração e de implantação e é uma espécie de ITP do MPS.BR e de PI do CMMI, com foco nos dados.
A seguir, dentro do mesmo componente vem  Gerência de Liberação(30). Esse processo objetiva definir como a organização gerencia as alterações nos “data feeds”(fluxos de atualização de dados), incluindo os procedimentos de “rollback” no caso de “quebras”/ do sistema e  trata da  comunicação para os sistemas “potencialmente” afetados. Objetiva ter uma abordagem definida e aprovada para gerenciar alterações no ambiente operacional (sistemas e  fontes de dados). A Gerência de release(liberação) é realizada como uma parceria entre “proprietários” de negócios, proprietários/responsáveis pelos dados e TI para analisar e endereçar qualquer pendência relacionada ao processo, alterações de fontes, infraestrutura de rede, hardware e  aplicações que suportam a gerência de dados. Há uma forte dependência/relacionamento com a gerência das interfaces de dados. A gerência de release(liberação)  pode ser planejada ou ser uma resposta a um problema. Em qualquer caso, o planejamento formal  e a coordenação com os envolvidos é  essencial para garantir alinhamento ao longo da organização. No fundo, objetiva garantir que a integridade dos dados seja mantida quando ocorrerem alterações em “data feeds” e sistemas. É uma espécie de “como” do processo de gerência de alteração(23). Por último, fechando a categoria de Plataforma e Arquitetura vem a parte de Dados Históricos(31). Esse processo define a abordagem usada para gerenciar a história de dados (alterações de dados) bem como a gerência de dados históricos(archives e informações sobre dados e metadados). Objetiva  garantir que o dado mantido pela organização é gerenciado de forma consistente, alinhado com os requisitos de retenção de dados e mantidos de acordo com os seus objetivos. Deve haver regras(para padrões de campos , regras para modelagem de dados, segurança de dados e permissões) para definir os dados históricos a serem capturados e armazenados. As políticas de arquivos históricos de dados(archives) necessitam ser documentadas para atender os aspectos regulatórios sobre retenção de dados. Fontes autorizadas de arquivos históricos de dados(archives) necessitam ser mantidas incluindo registro de quem fez a alteração e o “racional” para a alteração.


sexta-feira, 11 de outubro de 2013

Maturidade em dados-DMM-Data Maturity Model-Parte-IV


Operações de Gestão de dados:

A categoria Operações de Gestão de dados , está relacionada com Fontes de dados e Padrões e procedimentos. A área de operações, como o nome sugere,  está associada com as atividades operacionais de GD. Baseado na figura DMM-04 (post anterior),  ela se valerá de Política, objetivos e diretivas da estratégia, além de aspectos de Governança e gerência de Funding. Da área de Plataforma e Arquitetura recebe os vetores  relacionados aos meios de execução . Da categoria de Qualidade de dados recebe os controles da gerência de QD. Como vetores de saída, a categoria Operações de GD fornece os requisitos de sistemas, padrões e procedimentos para a Plataforma e Padrões e para procedimentos de qualidade. 

A categoria Operações de GD tem dois grandes componentes, com 8 áreas de processos. O primeiro componente é PADRÕES e PROCEDIMENTOS e o segundo é FONTES de DADOS, conforme a figura DMM-05, abaixo. 
                                                        Figura DMM-05- Operações de Gestão de Dados 

O processo  de Áreas e Padrões(18), como sugerido, reflete os aspectos de padronização. Dos 9 P´s, conforme a figura DMM-06  que definimos para a Gestão de Dados, esse processo define 3 dos principais “P”´s : Padrões, Procedimentos e Políticas. As Políticas são regras amplas que você gostaria que toda a empresa soubesse acerca dos dados. Definições macros e organizacionais que estabelecem ações, obrigações, direitos e responsabilidades. Os padrões são formalizações de regras que devem ser seguidas por todos no momento de se criar algo novo . Padrões de nomes de dados, padrões de modelos de dados, padrões de segurança, etc. Os procedimentos são definições mais focadas no “como fazer”, ou “How to”, como procedimentos para definição de password, procedimentos para criação de Políticas ou para verificação de QA(Quality Assurance). Procedimentos são partes mais ativas e operacionais,  um pouco mais específicas e se associam com processos. Por exemplo, no Processo de Medições, há “procedimentos” para a coleta de dados. Algumas áreas dentro da GD são mais susceptíveis aos procedimentos , padrões e políticas. A área de Garantia da Qualidade, por exemplo, tem uma série desses elementos moldando a forma de se atuar e de se monitorar. A parte de acesso a dados deve ter políticas e procedimentos definidos. O momento de definição desse trio de conceitos(procedimentos, políticas e padrões)  é considerado importante e deve acontecer quando o programa de GD já estiver iniciado permitindo uma participação mais intensiva das áreas, que podem e devem contribuir nas suas definições, criando dessa forma comprometimento e cumplicidade. A seguir vem o processo de Promulgação(19). Esse processo  instancia e estabelece a validade das regras e padrões definidos. A matriz de RACI(Responsible, Accountable,Consulted e Informed) pode ser um instrumento para melhor definir atribuições. Esse processo se acopla com o processo de Comunicação, cuja estratégia foi definida em CULTURA ORGANIZACIONAL-estratégia de comunicação(5). Promulgação e Comunicação são lados da mesma moeda e fundamentais na GD. O processo seguinte, Processos de negócios e Fluxos de dados(20), objetiva entender e gerenciar como as áreas de negócios operam os seus dados. É uma visão  partindo dos processos de negócios, detalhando os seus fluxos e atributos de dados, focando e conectando  os produtores aos consumidores de dados. A palavra chave aqui é o FLUXO de DADOS e se relaciona , de certa forma com o processo que foca no ciclo de vida dos dados-PA-14. O processo seguinte, chamado Ciclo de Vida de dependência de dados(21), já tem um foco mais invertido. A palavra chave é “Dependência”. Observa agora os dados sendo compartilhados por diferentes processos e as consequentes dependências que estes (os processos) tem daqueles(os dados compartilhados)  e como isso reflete na sua operação . A alerta fundamental deste processo  é o compartilhamento dos dados por vários processos e a dependência e os impactos causados por isso. Implica na observação de qualidade dessas fontes e de seus fornecedores, na medida em que estamos analisando a origem dos dados que atenderão aos requisitos do processo de negócios.
A seguir aparece o processo denominado Ontologia e Semântica de negócios(22). Esse processo sugere a preocupação com a grande lacuna, talvez a maior, observada hoje na Gestão estratégica de dados, que são os Metadados e suas definições . Objetiva que todos tenham um entendimento comum dos termos e definições sobre os dados, criando uma base forte para se promover a integração de dados entre as diversas unidades da empresa. O grande desafio é a definição, manutenção e reconcialiação dessas terminologias, buscando uma semântica não ambígua. Para terminar o componente de PADRÕES e PROCEDIMENTOS da Operações de dados há o processo genérico de Gerência de Alteração de dados(23). Esse processo/área de processo é  comumente encontrado em todas as propostas de maturidade. Trata do controle sobre as alterações e seus impactos. É a famosa “Change Management”. Cuida de garantir que as alterações de dados sejam avaliadas, analisadas nos seus impactos e aprovadas e divulgadas. O conceito de rastreabilidade entre dados, processos, fluxos,etc ajuda  a garantir a manutenção da integridade nos momentos de alterações. Lembre-se que as alterações são sempre as grandes responsáveis pelos impactos proporcionados em elementos e componentes de um sistema, pois, geralmente as suas propagações não são devidamente analisadas com o risco merecido. Esse é um processo que será usado em outros momentos, convocado de outros processos, como o Ciclo de vida de dependência de dados(21). Agora chegamos no último componente da Operações de Dados: As fontes de Dados. Aqui, como o nome está sugerindo, a preocupação é com as fontes e origens dos dados. Há dois processos ou PA´s propostas pelo DMM. A primeira é sobre os Requisitos de fontes de dados(24). Esse processo visa  fazer um batimento dos requisitos de dados de negócios definidos com as fontes de dados existentes, numa visão mais física mesmo(fonte-arquivo). Lembre-se que Requisitos de negócios poderão ser atendidos por dados oriundos de uma ou mais fontes. Esse processo também sugere a convocação de outros, que veremos mais adiante, relacionados com a verificação da qualidade daquelas fontes. Implica na avaliação desse quesito de qualidade através de processos de profiling. Esse processo de Requisitos de fontes é  uma espécie de zoom da PA-12 de Requisitos, vista pelo outro lado(das  fontes de dados-fornecedor). Apoia a visão do modelo Canônico, que deixa transparente as fontes de dados necessárias para o atendimento dos requisitos de dados, permitindo se trabalhar com uma visão conceitual. Finalmente chegamos na última PA da Categoria de Operações que é a Gerência de Aquisição e Fornecedores de dados(25). Esse processo representa um zoom nos fornecedores de dados. Enquanto a PA-24 anterior tem foco nas fontes de dados, essa se preocupa com os fornecedores de dados(donos/responsáveis pelas fontes). Espécie de SM(Supply Management do CMMI) e AQU-MPS, focado nos dados. O processo visa selecionar, contratar,gerenciar/acompanhar os fornecedores de dados(internos e externos), definindo SLA com os provedores de dados. Mesmo internamente o provedor deve ser visto como um fornecedor formal de dados. Há métricas de QA atreladas com os fornecedores e fornecimentos de dados e exige um claro entendimento das  competências, serviços, processos e tecnologias empregadas pelos provedores de dados. Deve-se acompanhar aspectos formais de atestados de correção, integridade, disponibilidade dos dados exigidos dos FN de dados e deve-se também considerar certificações de qualidade de dados dos FN.

Figura DMM-06- 9P´s da GD-Gestão de Dados 

sábado, 10 de agosto de 2013

Maturidade em dados-DMM-Data Maturity Model-Parte-III



As quatro categorias do DMM abrangem 11 componentes(5 da Estratégia, 2 de Operações, 2 de Plataforma e Arquitetura  e 2 de Qualidade) e 37 Áreas de Processos (17 da Estratégia, 8 de Operações, 6 de Plataforma e Arquitetura e 6 de Qualidade de dados) . Essas 37 áreas de processo serão enumeradas (x), na medida em que falarmos sobre cada uma. Vamos dar um “zoom” em cada uma delas, começando pela Estratégia de Dados. Veja a figura DMM-03, a seguir:
Figura DMM-03



Estratégia de Gestão de Dados:
A Estratégia  está relacionada com as ações pilares da GD(Data management-GD-Gestão de Dados), ou seja: objetivos, cultura organizacional, modelos de governança, apoio financeiro e entendimento do ciclo de vida dos dados. A essência da Estratégia está nas ações que darão embasamento para uma implementação correta e sustentável da GD na empresa. Primeiro pensamos nos OBJETIVOS  da empresa para justificar um plano tão ousado e complexo, que é controlar dados na empresa. Entender bem e explicitar  o porquê de se partir para GD é o primeiro grande desafio . Em outras palavras, os objetivos de gestão de dados(1). Isso envolve  também avaliar as áreas críticas e definir prioridades(2)  e escopo(3), visto que os dados são onipresentes na empresa e nunca se conseguirá controlá-los em todas as suas fronteiras. Além disso, há aspectos fundamentais de CULTURA ORGANIZACIONAL  que deverão ser quebrados. O sentido de “proprietarismo” de dados é um deles. O de replicação “impune” dos dados  é outro. O de desvio de padronizações é outro. Assim haverá outros vícios culturais desenvolvidos ao longo de anos. Isso, obviamente, implica na busca por um alinhamento(4) entre as áreas envolvidas no trabalho, começando, por exemplo, por uma Gerência executiva e passando por Comitês( executivos e/ou de GD) até chegar nos gestores locais de dados, focais responsáveis pela condução dos procedimentos de dados nas áreas de negócios. Um dos fatores críticos no alinhamento e no sucesso de qualquer programa, principalmente deste que mexe com elementos fundamentais como os dados é a comunicação(5). Pronto. Chegamos em outro ponto importante da estratégia: a comunicação. Resolvidos ou desenvolvidos as primeiras ideias sobre objetivos e cultura organizacional, parte-se para pensar, compartilhar, discutir e consensar os MODELOS DE GOVERNANÇA a serem aplicados na abordagem daquela empresa. Esse é o desafio de se dar a primeira forma organizacional àqueles que serão os responsáveis por materializar como a governança de dados vai ser conduzida na empresa . Primeiro na estrutura de GD(6)  ou seja a  concepção interna da própria área de GD, com seus papéis e responsabilidades, contando com camadas  mais estratégicas como o Comitê/Conselho executivo e de GD, áreas táticas como CDO/DMO ou áreas mais operacionais como gestores de dados. Isso tudo alinhado com os “custodiadores”(DBA´s,DA´s,etc), que são os papéis já existentes na esfera de dados, normalmente localizados dentro da TI.  A seguir vem a forma de se dar oficialidade a esta estrutura, pensando no seu encaixe e  nas fronteiras com as áreas existentes da empresa, através de um modelo organizacional(7)  oficial, com responsabilidades e “accountability” para todos os envolvidos nessa gestão. Lembre-se que os dados  perpassam áreas funcionais e hierarquias na empresa. Isso posto, chega-se ao mecanismo de supervisão(8), ou seja a forma pela qual isso tudo será observado, medido, analisado e mantido ou modificado. Seria uma espécie de Gerência de portfólio das ações de GD que estão sendo desenvolvidas, analisando-se o desempenho da GD como processo que flui pela empresa. Todas essas atividades de GD a serem executadas deverão ser preparadas e planejadas, com recursos alocados,papéis,etc. Para isso temos que ter um plano de implementação de GD(9), que definirá como vou fazer tudo isso funcionar e envolve como preparar para o funcionamento da GD, das ações de supervisão, da comunicação, etc. Isso, por sua vez,  pede uma análise dos recursos humanos necessários, ou requisitos do capital humano(10)  para se tocar a GD. Por fim, dentro ainda do componente Modelo de Governança, há o processo de Medições(11). Esse é o mesmo conceito emprestado do CMMI(MA) ou do MPS.BR(MED).Há que se ter medições para fazer esse acompanhamento das atividades e dos resultados de GD, pois não se gerencia o que não se mede. Terminadas essas visões de processos , digamos preparatórias, devemos pensar nele, o motivo de tudo isso, o gerador desses posicionamentos. Sua excelência: “O DADO”. Dentro da  categoria Estratégia há um componente chamado CICLO de VIDA dos dados. É aqui que vamos ter que entender o dado como um elemento gerenciável dentro da empresa.  Aqui começamos a materializar aquela máxima de que os dados são ativos da empresa. O conceito de ciclo de vida de dados é muito próximo do nosso conceito de ciclo de vida. Se você pensar em você, com os seus dados, ao longo da sua vida,  você entenderá o que é o ciclo de vida. Pense nisso:  Quando você nasceu, os seus dados fizeram parte do sistema de informações da Maternidade onde sua mãe deu à luz. Apareceram sob a forma de fichas, registros de internação  em papel, etc. Os resultados  desse , digamos , processo, foram a etiqueta que você teve pregada no berçário e o papel que declarava o seu nascimento, entregue aos seus pais quando saíram. Com esse papel, o seu pai foi ao Cartório de registro, entrando num outro “processo de negócio”, por assim dizer. Fez o registro com esses dados (que agora viraram input). Os dados foram transformados em outros registros e teve como saída(output) a sua certidão de nascimento lavrada. Ela serviu de entrada no sistema do grupo escolar, que gerou alguns registros internos e como saída originou-se o seu boletim de aprovação  e seu certificado. Dessa forma os seus dados foram sendo tratados por diferentes processos ao longo da sua vida. Até que  um dia, como acontecerá com todos nós, o ciclo se fechará. Alguém fará o registro de seu óbito(uau..), tendo como entrada um atestado emitido por um outro processo de negócio(do hospital onde você esteve internado)  e terminará o ciclo de vida de seus dados. Ainda haveria outros processos subsequentes, relativos a espólio, herança,etc, por onde os seus dados trafegariam, mas paramos por aqui. Entendeu o que é um ciclo de vida de dados?. Pois é...No DMM, dentro da categoria Estratégia e dentro do componente CICLO DE VIDA, há alguns processos. O primeiro deles é o chamado Definição de Requisitos de dados(12). No fundo esse processo identifica as áreas de negócios da empresa(todas ou aquelas sob o foco prioritário da GD), os processos de negócios dentro delas e os dados que são usados em cada um. Há uma forma de se registrar isso, via modelos de dados, que podem ser canônicos(aqueles com alto grau de independência de como os dados serão usados, envolvendo entidades,relacionamentos e atributos fundamentais), lógicos(entidades, relacionamentos e atributos numa visão menos computacional), físicos(maiores detalhes sobre a sua forma de implementação, numa visão mais computacional). Outro elemento sugerido nesse processo é o registro disso tudo num Repositório, num casamento com outro processo que foca nos metadados, como o Ontologia e semântica de negócios(22), falado mais adiante.
Um outro processo, vizinho deste, chamado Gerência do ciclo de vida dos dados(14)  detalha o “como” cada processo usa/altera/consome os dados, numa espécie de “zoom” do anterior,agora com ênfase nos processos, enquanto o anterior tinha olhos mais voltados  para os dados. Aqui o olhar é sobre os Processos de negócios e como os dados são tratados dentro deles: São analisados de vários pontos de vistas: de quem consome, de quem os produz, envolve também a identificação de dados que são usados e consumidos por “vários” processos de negócios, os chamados Dados Mestres. Aqui há a necessidade de se começar a conhecer e manter oficialmente o ciclo de vida dos dados, a partir do conhecimento dos processos de negócios. A essência da visão desse processo é o ciclo vida, obtido via a análise de vários processos. Lembre-se que o ciclo de vida de um dado perpassa vários processos de negócios. Associado a esses dois processos anteriores, ainda dentro do componente CICLO DE VIDA, há um terceiro processo chamado Impacto Operacional(13) . Esse processo, batizado com um nome, que a princípio soa pouco adequado, tem como objetivo dar um foco mais operacional às atividades de DM. Enquanto os dois anteriormente versavam sobre a visão dos dados numa perspectiva mais de ciclo de vida, este foca  em como os dados serão planejados com relação às atividades operacionais de GD, documentando e validando workflows, garantindo SLA(acordo de nível de serviços das atividades de dados) e garantindo que os requisitos de dados(12) demandados anteriormente serão alcançados ou materializados . Cogitam também dos aspectos de transição para o ambiente de produção  e de aceitação dos processos e das plataformas implementadas. No fundo é uma visão, digamos mais CPD, operacional, numa espécie de preparação para a categoria seguinte de OPERAÇÕES de DADOS . Para fechar a categoria Estratégia de DM, há o último componente, denominado APOIO FINANCEIRO, ou Funding. Ela contempla as ferramentas e estratégias de convencimento, ou seja, tem como objetivo provar que tudo isso tem valor de negócios e será dedicado à alta gerencia e camada decisória da empresa. Esse componente tem 3 áreas de processos(PA), ou processos. O primeiro é TCO(15), ou custo total de propriedade. O outro é Business Case(16) e o último é Modelo de funding(17). Os dois primeiros têm como objetivo provar, convencer e demonstrar que os  investimentos(terceiro)  a serem aplicados terá retorno. Embora seja a visão menos técnica do modelo DMM, é uma das mais importantes pois define a viabilização de um projeto extremamente sensível na importância e no investimento.
Observe a figura DMM-04. Ela mostra um diagrama de bolhas enfatizando os vetores de relacionamentos entre as quatro categorias do DMM. Veja que da bolha Estratégia de GD saem as diretivas para as outras categorias do DMM. As políticas, objetivos e direções são enviadas para a Plataforma e Arquitetura e para a categoria Operações de GD. Para a categoria de Qualidade de dados, saem nas necessidades de qualidade e aspectos de Governança. Na seta de baixo, aparecem os Processos considerados de Apoio (Requisitos, Riscos, Configuração e Medições) .

Figura DMM-04

sábado, 29 de junho de 2013

Maturidade em dados-DMM-Data Maturity Model-Parte-II


As quatro grandes categorias do DMM são:

·         Estratégia de Gestão de dados
·         Operações de Gestão de dados
·         Plataforma e arquitetura
·         Qualidade de dados

Além das quatro categorias acima, observe que há os processos chamados de apoio que gravitam em torno delas. São processos herdados do CMMI/MPS.BR e que são aplicados para apoiar a implementação das atividades de DM. Há processos de Gerência de Requisitos(REQM/GRE), Configuração(CM/GCO), Riscos(RSKM/GRI) e Medições(MA/MED). Esses processos serão convocados para apoiar os 11 componentes e as 37 áreas de processos do DM.
Outro aspecto importante de se entender é o conceito de Capacidade, um dos fatores que diferenciam os corpos de conhecimentos, como DMBOK  dos modelos de maturidade, como o DMM ou CMMI. Os níveis de capacidade estão ao lado da pirâmide, na figura DMM-01, no post anterior.  
A capacidade de se implementar uma área de processo(ou processo, como chamamos no MPS.BR) é uma medida que define a profundidade ou a extensão como aquele processo é implementado. Por vezes um processo é implementado contemplando parcialmente os seus pontos ou resultados, porém adequados àquele nível específico. Na medida em que o processo evolui na escala, outros requisitos são adicionados e exigidos. Os conceitos abaixo ilustram as diferentes graduações de implementação de um processo:
       Nível zero: Incompleto
      Processos ou não são executados ou são parcialmente executados. O que existe está no estado das mudanças dinâmicas, ou seja mudam à vontade. Indivíduos  realizam tarefas e não há objetivos formais
       Nível 1: Realizado
      Processos são “adhoc” e localizados em projetos. Não há processos unificados entre áreas de negócios. A disciplina de processos é improvável de ser rigorosa, há ênfase em  consertos(acertos) de dados. O desempenho pode não ser estável e pode não se alcançar objetivos específicos como qualidade, custo e prazo. Podem estar acontecendo melhorias mas não há mecanismos que garantam que  elas(as melhorias) persistirão
       Nível 2: Gerenciado
      Processos são planejados, realizados, monitorados e controlados para alcançar um certo objetivo ou em resposta a certa necessidade específica. Há um infraestrutura colocada  para suportar processos num nível de unidade de negócios, mas não no nível da organização com um todo. Regras claras e responsabilidades foram definidas. Há ações em projetos ou conjuntos de projetos, sem uma orquestração organizacional, uma visão corporativa.
       Nível 3 : Definido
      Conjunto de processos padrão (PP) foi definido e os processos  são melhorados ao longo do tempo. Processos que visam alcançar objetivos específicos são “adaptados” a partir do conjunto de PP de acordo com regras definidas  e garantem uma certa uma medida previsível de consistência. Há uma visão organizacional, com orquestração central pela GD.
       Nível 4: Medido
      Métricas medidas e acompanhadas são estabelecidas. Há um processo formal para gerenciar variância (variações de processos). Desempenhos de qualidade e de processos são entendidos em termos estatísticos e gerenciados através da vida do processo
       Nível 5:Otimizado
      O foco é continuamente melhorar o desempenho do processo através de melhorias incrementais e inovadoras. Feedbacks são usados para direcionar as melhorias do processo e o crescimento do negócio

No DMM os níveis de maturidade são definidos escolhendo-se, no mínimo, uma das quatro grandes categorias desejadas e todos os processos daquela categoria deverão estar no nível de capacidade homogêneo, a fim de garantir que aquela categoria esteja naquele nível de capacidade. Por exemplo, a empresa escolhendo a sua busca inicial de maturidade pela Estratégia, deverá apresentar todos os 17 processos no nível de capacidade(1,2,3,4 ou 5). Isso definirá a maturidade da empresa, naquela categoria e naquele nível. Além disso, a empresa deverá ter implementado também os processos de apoio, no mesmo nível. Veja figura DMM-02



Figura DMM-02-Nivel de Maturidade e de Capacidade-Data Maturity Model



No exemplo acima, a categoria Qualidade está implementada em nível de maturidade 3, maior nível de capacidade alcançado por todas as PA´s. Além disso, os processos de apoio também estão implementados.

sábado, 25 de maio de 2013

Maturidade em dados-DMM-Data Maturity Model-Parte-I


Iniciaremos neste post, um conjunto de publicações sobre o DMM, o modelo de dados associado ao CMMI e seu alinhamento com o DMBOK.

DMM-Data Maturity Modelo-Introdução
A adoção de certas práticas exige determinado grau de amadurecimento das empresas, principalmente quando falamos de mudanças que passam pela cultura organizacional, como no caso dessa nova visão sobre o cuidado e a propriedade dos dados. Na esfera de processos, o CMMI (Modelo Integrado de Capacidade e Maturidade) prescreve cinco níveis para serem trilhados e o MPS.BR (Melhoria do Processo de Software Brasileiro)  tem sete na sua escala. A ideia, por trás dessas escalas, é que nenhuma empresa consegue galgar pontos de maturidade, num tempo menor do que a sua cultura permite. Ou seja, tal como nós, as empresas precisam “rodar”  durante certos períodos, aplicando as práticas apontadas e criando uma camada cultural que lhes sirva de degraus para gradativamente ascender na escala do modelo. É igual banana amadurecida à força. Amadurece, fica comestível, mas sem gosto. Há que se ter um amadurecimento natural. Alguns modelos de maturidade e qualidade se valem dessa necessidade de amadurecimento gradual e definem níveis que são planejados pelas empresas, de acordo com o oxigênio disponível para abraçar tais mudanças. Diferentemente do CMMI e MPS.BR, focados em amadurecimento de processos,  o conceito de Gestão e Governança de Dados, ainda  carece de maior cuidado na definição do que venha a ser maturidade . Embora no mesmo barco dos processos e serviços, o conceito de maturidade em gestão de dados ainda é relativamente “imaturo”.  Os primeiros conceitos sobre uma gestão mais formalizada de dados apareceram com o modelo DMBOK, da Dama-Data Management Association. Essa proposta, entretanto, não representa classicamente um modelo de maturidade, mas sim um conjunto de corpos de conhecimentos, o que é , sensivelmente diferente. O DMBOK apresenta uma série de sugestões de natureza técnica, administrativa e organizacional, de forma a facilitar a aplicação de melhores práticas, nesse mundo tão complexo dos dados. O padrão DMBOK, embora um conjunto válido de preceitos, não é centrado em uma abordagem voltada para se definir maturidade. Tem mais foco no “como” do que no “o quê”.  Não possui níveis de maturidade nem de capacidade, como encontrado nos modelos CMMI e MPS.BR. Já o DMM-Data Maturity Model, modelo de maturidade em dados do SEI e do EDM Council, previsto para 2014, traz todos os elementos necessários para se escalar a maturidade, galgando níveis de capacidade. Diferentemente do anterior sua preocupação é com o “o quê” e não com “o como”.  O modelo DMM que aqui descrevemos foi baseado no estudo do “draft” publicado na internet e acessado em   março de 2013, no endereço
Esse material analisado ainda está em “estado”  de “draft” não podendo ser considerado a versão oficial do modelo, que será lançada em 2014, após revisões previstas para esse ano. Esse meu trabalho objetiva a análise em detalhe das Categorias, Componentes e Áreas de processos do DMM-Data Maturity Model, a fim de se alinhá-los  com os Corpos de Conhecimento do DMBOK-DAMA-Data Management Association e com os conceitos de maturidade e capacidade do  CMMI-SW e do MPS.BR-SW . Dessa forma, o trabalho aqui publicado não constitui uma simples versão do inglês para o português das referências citadas, mas também uma agregação de conceitos acerca dos aspectos de dados, sua gestão e governança, aliado com experiências em projetos de implementação de modelos de qualidade.   Como elementos de ilustração foram usados alguns desenhos e imagens obtidas do Google image e outros desenvolvidos pelo próprio autor.
O modelo DMM-Data Maturity Model foi desenvolvido através de uma ação conjunta envolvendo o SEI-Software Engineering Institute, a casa do CMMI, o EDM-Enterprise Data Management Council e  corporações financeiras como Grupo Citi, Bank of America, Chartis Insurance e Fannie Mae, além das consultorias  Deloitte and Touche; Booz, Allen, Hamilton; elemento-22; Kingland Systems e Ernst and Young.


A estrutura do DMM-Data Maturiy Model:

DMM-01-Visão geral das Categorias do DMM-Data Maturity Model

Continuaremos no próximo post.

sexta-feira, 15 de março de 2013

Governança de Dados-Maturidade em Gestão e Governança de Dados-Introdução-Parte-I



Veja figura abaixo. Ela foi apresentada por mim no último DMC-Latam-Data Management  Conference-Latin América, no Brasil, promovido pela Dama-BR,em agosto de 2012. A minha ideia foi tentar imaginar qual seria o grau com que os conceitos de Gestão/Governança de dados estão sendo praticados no Brasil. Adaptei um diagrama contendo os corpos de conhecimento do DMBOK- Dama e solicitei a alguns técnicos, altamente especializados em dados, que votassem apontando o número de bolinhas verdes(de 1 a 5) que eles imaginavam representar o estado daqueles processos. Tudo isso numa visão pessoal, desconectada de empresas em particular e somente se valendo do conhecimento sobre cada processo e a percepção intuitiva da sua possível aplicação. Claro que isso está longe de ser algo formal, científico, preciso ou rigoroso. Seria uma visão, digamos de ‘apaixonados por dados’, um exercício de “eu acho”, sem nenhum rigor científico, vindo porém de pessoas  altamente especializadas na área, como Fernanda Farinelli(Prodemge), Cláudio Lúcio(Core Synesis), Gustavo Leal(Localiza) e Marcelo Lamounier(MGInfo). Na visão de maturidade apresentada no DMC Latam/2012, a  escala usada, com cinco bolinhas verdes, podendo ter meia bolinha, é uma forma simplificada de se graduar a aplicação dos processos, com intensidade baixa (0  a 2) bolinhas, média(2,5 a 3,5) bolinhas e alta(4 a 5) bolinhas.




Cabe ressaltar que uma pesquisa, mais formal e estatisticamente consistente, foi posteriormente realizada, numa colaboração entre Dama-BR e Fumsoft(Dama-MG) e com uma importante participação de Fernanda Farinelli. Essa pesquisa, certamente jogará luzes mais reais sobre os conceitos de dados e sua gestão, levantados em empresas de variados segmentos, no Brasil todo. O resultado dessa pesquisa e uma interpretação feita por mim (colaboração de FFarinelli),  estão disponíveis aqui: http://www.fumsoft.org.br/qualidade/gestao-de-dados  .

O modelo DMBOK foi o escolhido pois, diferentemente de outras escolas, como visto aqui nesse espaço em posts anteriores, apresenta o mais amplo espectro do conceito de Gestão de dados, indo de Governança a segurança, de bancos de dados a dados não estruturados, perpassando assim, todos os temas atrelados a dados .

DAMA-DMBOK:
A gerência de dados, segundo a DAMA tem como missão e objetivos atender( e exceder) as necessidades de informação de todos os envolvidos(stakeholders) da empresa em termos de disponibilidade, segurança e qualidade. O processo de DM é capturado em funções e atividades e está distribuído por dez(10) funções , ou áreas de conhecimento:
Ø  Governança de dados(GD):
Ø  Gerência de Arquitetura de Dados:
Ø  Desenvolvimento de dados:
Ø  Gerência de operações de dados:
Ø  Gerência de Segurança de dados:
Ø  Gerência de Dados Mestres e de Referência:
Ø  Gerência de DW(Data Warehousing)  e BI(Business Intelligence):
Ø  Gerência de Conteúdo e Documento
Ø  Gerência de Metadados:
Ø  Gerência de Qualidade de dados:

DMM-Data Maturity Model:
Os conceitos de maturidade em dados deverão evoluir, cada vez mais, a partir de agora. No post passado, falei sobre o DMM-Data Maturity Model, que deverá chegar oficialmente em 2014, pilotado pelo CMMI Institute, a nova “ casa” dos modelos consagrados de maturidade de processos, serviços, aquisição, pessoas,etc. Com a chegada do DMM, cuja síntese está publicada no post anterior e traduzida abaixo, os aspectos de maturidade finalmente chegarão aos dados. Com pouquíssima informação disponível na rede e ainda em estado de “draft” o DMM mudará, na minha opinião, o domínio dos dados e a sua relação com aspectos de gestão e qualidade. Com 4 grandes categorias (Estratégia de Gestão de dado, Plataformas e Arquiteturas de DM, Operações e Qualidade), 11 componentes e 37 áreas de processo, o modelo trará, ao mundo dos dados, os mesmos conceitos já amplamente praticados em outros domínios(processos, serviços, pessoas, etc), através de modelos consagrados como CMMI, ISO,MPS.BR,etc.    
Os elementos presentes no DMM estão em plena sintonia com o modelo da DAMA, porém com uma visão mais ampla e  sempre centrados no conceito de que, um modelo é algo sugerido e não uma fórmula definida de implementação. Como filho mais novo derivado da família CMMI, o DMM trará também processos de apoio não observados na proposição DAMA, mas fundamentais na implementação de processos de maturidade. São: MA(Measurement and Analysis-Medições e Análise, MED-no MPS.BR), CM(Configuration Management-Gerência de Configuração, GCO no MPS.BR),REQM(Requirement Management-Gêrencia de Requisitos, GRE no MPS.BR) e RSKM(Risk Management-Gerência de Riscos, GRI, no MPS.BR). Com isso o DMM se aproxima do CMMI e do MPS.BR, numa conjugação perfeita de maturidade e qualidade que deverá mudar o eixo dos modelos de qualidade, agora chegando aos ativos informacionais da empresa.
Os componentes do DMM, definidos dentro de cada categoria abrangerão a seguinte estrutura, conforme o único documento disponível na internet, e referenciado no post anterior: Data Management Maturity Model-(DMM)-Model Update- Rawdon Young-Novembro, 2012, acessado em 01/02/2013, no endereço:  www.dtic.mil

A estrutura do DMM é :

ESTRATÉGIA:

1)Objetivos (goals) da Gestão de Dados
Objetivos  mais detalhados(objectives) da Gestão de Dados
Prioridades da Gestão de dados
Escopo do programa de Gestão de Dados

2)Cultura Organizacional
Alinhamento
Estratégia de comunicação

3)Modelo de Governança
Estrutura da Governança
Modelo da Organização
Supervisão(Oversight)
Implementação e Gerência da Governança
Requisitos de capital humano
Medidas /Medições

4)Suporte financeiro para GD
Custo de propriedade total do Ciclo de Vida
Casos de negócios(Business case)
Modelo de Suporte(Funding model)

5)Ciclo de vida dos Requisitos de dados
Definição dos Requisitos de Dados
Impacto Operacional
Gerência do Ciclo de vida  dos Dados

OPERAÇÕES:

1)Padrões e Procedimentos
Áreas
Promulgação
Processos de Negócios e Fluxos de Dados
Ciclo de vida das dependências de Dados
Ontologia e Semântica de negócios
Gerência da alteração de Dados

2)Fonte de Dados
Requisitos de Fontes de Dados
Processos de Aquisição e fornecimento de Dados

ARQUITETURA E PLATAFORMA

1)Framework Arquitetural
Padrões arquiteturais
Estratégias arquiteturais

2)Plataforma e Integração
Plataformas em Gestão de Dados
Integração de aplicações
Gerência de Release(liberação)
Dados históricos

QUALIDADE DE DADOS

1)Framework de Qualidade de dados
Desenvolvimento de estratégias para Qualidade de Dados
Medição e Análise de Qualidade de Dados

2)Garantia da Qualidade de dados
Profiling de Dados
Avaliação de Qualidade de Dados
Qualidade de Dados para integração
Limpeza de Dados

Nos próximos posts continuaremos a análise detalhada e comparativa entre as proposições de maturidade de dados.



quarta-feira, 13 de fevereiro de 2013

DMM-Data Maturity Model


Vem aí o DMM-Modelo de Maturidade de Dados do CMMI:


Fonte: Data Management Maturity Model-(DMM)-Model Update- Rawdon Young-Novembro, 2012, acessado em 01/02/2013, no endereço:  www.dtic.mil


Está previsto para 2014, o lançamento do DMM-Data Maturity Model do SEI-Carnegie Mellon. O modelo, em desenvolvimento e em espécie de "beta-teste" em grandes instituições financeiras americanas, seguirá a mesma linha do CMMI, com áreas de processos(ou processos no jargão MPS.BR). Isso simplesmente mostra que chegou a hora dos dados. Depois dos Processos, com várias alternativas de evolução em escalas de maturidade(CMMI, MPS.BR, ISO,etc), dos Serviços(ITIL,ISO-20.000) e MPS.SV,  os dados serão objetos de implementações e avaliações de maturidade. Já estou em contato com "relacionamentos" no mundo CMMI visando obter maiores informações sobre o modelo. Por enquanto segue, no slide acima, as áreas de processos definidas, ainda em forma de proposição. Alguns pontos interessantes podem ser observados na proposta:


1) O modelo apresenta 5 grandes áreas: Estratégia de Gestão de Dados, Operações, Plataformas e Arquiteturas, Qualidade de dados e Áreas de apoio;
2)O modelo, logicamente, toca em pontos que temos discutidos muito nesse Blog. Os dados, sua governança, gestão, qualidade e a necessidade de vê-lo como algo além de combustível dos sistemas. O modelo mostra a preocupação com os dados, alinhando 17 temas , que vão dos objetivos estratégicos dos dados, a cultura organizacional sobre dados, os modelos de governança, aspectos de "funding" e aspectos de ciclo de vida dos dados. Na área de operações aparecem: Padrões e Procedimentos, 2 dos 9 P´s já discutidos por aqui, além da preocupação com fontes de dados. Na área de Plataforma e Arquitetura os assuntos discutidos são: Frameworks de arquitetura e aspectos de plataforma e integração. Na área de Qualidade de dados, o modelo trata de frameworks de qualidade e da Garantia da qualidade de dados, algo como(DQA-Data Quality Assurance), numa mimetização do PPQA do CMMI que trata de Produtos e Processos(PPQA). NO MPS.BR essa área de processo é a GQA(Garantia da Qualidade).
3)O modelo nitidamente busca estabelecer compatibilidade com o CMMI-SW, mantendo (áreas de ) processos de apoio iguais, o que favorecerá a sua implementação em empresas que já implementaram CMMI ou MPS. CM(Configuration Management), que é o GCO do MPS.BR; MA(Measurement and Analysis) que é o MED do MPS.BR. Também há o REQM(Requirements Management), que vem a ser o nosso GRE(Gerência de Requisitos) do MPS.BR, além do RSKM(Risk Management), que corresponde ao GRI(Gerência de Risco) do MPS.BR. Como esses processos são de apoio, não há como fugir deles, seja Processo, Serviços ou Dados.

No futuro, voltaremos com maiores informações sobre o DMM.  

sexta-feira, 25 de janeiro de 2013

Análise da Pesquisa DAMA-Fumsoft sobre Gestão e Governança de Dados no Brasil

Já está publicada a análise sobre a Pesquisa Dama-Fumsoft sobre Gestão e Governança de Dados no Brasil. O link está no site da Fumsoft e pode ser acessado aqui:

Site Fumsoft


Essa pesquisa, realizada pela parceria Dama-BR+Fumsoft, é a primeira fotografia sobre a situação da gestão de dados no Brasil, tema que se torna, cada dia mais importante na vida das empresas. Embora seja uma primeira visão, e portanto, com um tom mais qualitativo, essa ação servirá para embasar futuros trabalhos no mundo da academia e na indústria da consultoria no segmento de dados.

Carlos Barbieri