Total de visualizações de página

quarta-feira, 22 de fevereiro de 2012

Governança de Dados-Parte II- GD via 5W e 2H.



A Governança de Dados é um termo recentemente produzido na esteira dos jargões que brotaram a partir do termo genérico “governança”.  Extraída do contexto maior da governança corporativa, e meio implícita na Governança de TI, a de dados foca em princípios de organização e controle sobre esses insumos essenciais para a produção de informação e conhecimento das empresas. Por tudo discutido no post anterior, a Governança de Dados será um tema recorrente nos próximos anos e as empresas deverão se preparar para adotá-la, ou no mínimo, entendê-la com a profundidade com que será discutida.  A definição de Governança de Dados(GD) é ampla e plural. É um conceito em evolução, que envolve o cruzamento de diversas disciplinas, com foco em qualidade de dados, passando por avaliação, gerência, melhoria, monitoração de  seu uso, além de aspectos de segurança e privacidade associados a eles. Para tal, as empresas deverão definir objetivos organizacionais e processos institucionalizados, que serão implementados dentro do equilíbrio fundamental entre TI e áreas de negócios . Através da GD as empresas hoje também definem mecanismos para analisar os processos que se abastecem de ou produzem os dados, criando um sentido maior de qualidade conjunta entre esses dois elementos  seminais (dados e processos)  e contribuindo para a valorização desses ativos, através do pleno conhecimento da cadeia produtiva de informação e conhecimentos. Como processo organizacional, a GD estabelece políticas e diretrizes corporativas legislando sobre os dados e atribuindo papéis de criadores/produtores (collectors), mantenedores (custodians) e consumidores de dados (consumers), gerando a trinca CCC (collectors, custodians and consumers), siglas que começam a aparecer nas telas da GD. Acoplados com os preceitos de GD surgem com muita força os aspectos de qualidade de dados e de informação, até como vínculo de causalidade. Assim a GD pode ser vista como um guarda-chuva conceitual sob o qual se abrigarão diversas ações que, no fundo, visam à melhoria desses insumos, agora fundamentais à luz dos novos tempos: os dados.  
Para facilitar a discussão sobre GD, encaminharemos a nossa reflexão adotando a  abordagem comum, centrada na abordagem do 5W2H, conforme a figura 2.1  lá no final desse “post”:
1) O quê? (What): definir claramente a Governança de Dados como um componente dentro da visão de Governança Corporativa e de TI, voltada para os recursos de dados, as informações e os conhecimentos da empresa, o seu uso controlado, a sua qualidade e as diretrizes para o seu consumo e produção. Há quem defina a GD como o viés  legislativo e judiciário dos dados, quando comparado com um sistema de poderes da República;
2) O porquê (Why): como os domínios de dados de uma empresa são amplos e sensíveis, há que se definir claramente os objetivos que se deseja alcançar com a adoção de um programa  de Governança de Dados. Por exemplo, pode-se se basear na missão da empresa e em alguns de seus valores, analisados sob certos prismas:
·         Dimensão empresa, mercado e clientes: a constante preocupação com a dinâmica do mercado, que pode envolver aspectos de regulação, aderência às normas e aos relacionamentos com clientes, além de fatores surgidos por fusões e parcerias, etc.;
·         Dimensão da qualidade: pode ser baseada na qualidade corrente de dados do sistema, no número de erros e reclamações decorrentes dessa qualidade,  e dos riscos pelas perdas de valores reais ou de reputação devido aos problemas originados na manifestação da baixa qualidade desses ativos;
·         Segurança dos dados: pelo crescimento do volume de dados, o aumento da conectividade da empresa e o consequente volume de acessos aos dados, criando fronteiras mais expostas e aumentando as chances de invasões, adulterações e uso indevido de dados e informações. Os aspectos de privacidade de dados são fatores também considerados nesse ponto;
·         Liquidez e disponibilidade da Informação: pela crescente necessidade de obter mais rapidamente as informações competitivas e confiáveis demandadas por áreas estratégicas da empresa, nem sempre integradas pelos dados. Além disso, pela demanda por novos aplicativos em novos domínios (mineração de comportamento de clientes, de colaboradores, gerência de projetos, dados não estruturados, etc.), a geração e retenção cada vez maior de conhecimento do negócio da empresa, sempre considerando o dado como elemento central na produção de informação e derivação de conhecimento.
Uma forte motivação organizacional é fator preponderante na adoção corporativa e no engajamento e  comprometimento com um programa cuja implementação não é trivial. Ela envolve esforços e investimentos, além de fortes alterações culturais visando quebrar paradigmas enraizados, como o “proprietarismo” , as “paróquias” de dados  e  a indulgência sobre o descontrole  a que esses  importantes ativos foram relegados;
3) Onde (Where): como qualquer programa de natureza organizacional deverá seguir os preceitos de pensar global e agir local. Definir claramente que áreas deverão ser focos prioritários dos trabalhos de GD é um dos primeiros passos. Por exemplo, áreas críticas em que residem os MD (Master Data - Dados mestres), como clientes, fornecedores, produtos, locais, etc. Os dados considerados mestres já são focos de uma perna da GD, denominada MDM (Master Data Management), que exploraremos adiante. As áreas escolhidas deverão ser aquelas que apresentam maior sensibilidade aos negócios, permitindo uma abordagem que objetive a produção mais consistente de dados e informações para a geração de conhecimentos estratégicos e melhoria nos processos de tomadas de decisão da empresa;
3) Quando (When): planejar a implementação dos programas de GD em ciclos, com iterações que possam produzir melhorias metrificadas em termos de qualidade, controle, risco e segurança de dados. Um projeto dessa natureza certamente requererá iterações com entregas periódicas de resultados, que permitam a sua reavaliação constante e o seu amadurecimento ao longo do caminho. Uma abordagem com ciclo de vida “cascata” num processo dessa natureza certamente implicará altos riscos. De novo, vale a filosofia de pensar globalmente e agir localmente;
4) Quem (Who): identificar e trabalhar com os principais envolvidos nas áreas críticas definidas, contemplando os CCC: Creators/Collectors, Consumers e Custodians, que, traduzidos, seriam os criadores, consumidores e mantenedores  dos dados.  Definir um grupo capaz de conduzir as ações propostas, numa espécie de Escritório de Dados que, através de reuniões, acompanhe o desenvolvimento e a implementação da estratégia, envolvendo todos os interessados e definindo caminhos e alterando rotas, quando necessário. Seria o equivalente ao PMO, para os projetos e o SEPG (Software Engineering Process Group) para
os processos. Seria algo como o DGPG, ou Data Governance Process/Program Group, ou DMO (Data Management Office). Um conselho de Governança de dados, composto por elementos de várias áreas de negócios e TI, atuando como um comitê de supervisão é fator fundamental na solidificação do programa, na consolidação da parceria “TI+Negócios”  e na resolução de conflitos. E finalmente, a criação de figuras de gestores de dados(data steward), representantes locais de áreas de negócios responsáveis pelos dados mais sensíveis daquela unidade organizacional ou sistema. Todos esses papéis já estão sendo gradativamente amadurecidos em várias implementações de projetos de GD, podendo, em alguns casos, oferecer variações de títulos. Por exemplo, o conceito de “data custodian” pode variar entre implementações, sendo que em algumas aparece  mais associado à equipe de TI e em outras também é  sinônimo de data steward(gestores de dados presentes nas áreas de negócios). O importante é entender que basicamente , em todas as implementações, você distinguirá 3 camadas de papéis: a mais alta formada pelos decisores da alta gerência, aos quais competem as definições maiores e as diretrizes do programa, além da resolução de conflito; uma camada média, formada pelo DMO, ou escritório de dados, que gerencia os programas de GD e na ponta, com os data stewards(gestores de dados), lotados nas áreas de negócios, responsáveis pela custódia semântica e lógica dos dados. Os envolvidos de TI também estariam nesse nível, responsáveis pela custódia física dos dados, habitantes de bases de dados, ERP´s e data warehouses.  ;
5) Como (How): pensar em definir as regras e as diretrizes do processo de GD, através de políticas que deixem claro quais são as restrições, suas aplicações e os envolvidos. Também a definição dos direitos, padrões e responsabilidades associadas ao uso, à atualização e à liberação das informações. Definir como se pretende a implantação dos mecanismos ou      subprojetos de melhoria e alcance dos objetivos traçados na missão. Por exemplo, implantando um Plano de Qualidade de Dados, baseado na filosofia de TDQM (Total Data Quality Management), do MIT, para as ações de melhoria de qualidade, ou desenvolvendo projetos na área de MDM (Master Data Management) para tratamento de cadastros mestres  considerados estratégicos. Definir objetivos e métricas que possam ser usadas para medir o alcance do programa, dentro da ótica de que somente se gerencia aquilo que se mede. Por exemplo, diminuição de erros em dados, redução de número de reclamações/erros por liberações de sistemas e produtos, redução de dados mestres duplicados em áreas recentemente submetidas a fusão/merging, diminuição da proliferação de bancos de dados setorizados, etc;
7) Quanto (How Much): o programa de GD deverá contemplar um conjunto de projetos que, por definição de prioridades, implicará custos de várias naturezas. Custo de pessoal envolvido, custo de software/hardware, custo de treinamento, consultoria e mentoring, etc. Tentar obter ROI pode ser uma tarefa difícil, devido aos ganhos intangíveis que a qualidade, ou a falta dela, traz à imagem, à marca e à reputação da empresa. Uma boa estratégia a se adotar é trabalhar com o “custo negativo” : Imaginem o custo de uma Área pública de Saúde, com dados mal controlados sobre cidadãos atendidos em suas unidades. Imaginem, por hipótese, que dois cidadãos atendidos têm o mesmo nome: José Ferreira dos Santos. Imaginem também que um tem problema de diabetes(hiperglicemia)  e o outro tem crises de hipoglicemia. Imaginem as complicações produzidas se as fichas forem trocadas por falta de uma identificação mais efetiva de registros, ou seja um descontrole na qualidade dos dados. Imaginem o quanto os problemas de qualidade de dados podem significar em termos de reputação ou de valores mais significativos do que esse!. Larry English, no seu livro Information Quality Applied, da Editora Wiley(2009) , mostra  no capítulo 1, uma tabela com dezenas de exemplos que mostram o alto custo da baixa qualidade. Leia e se espante.
Com esse esquema de 5W e 2H, a empresa deverá criar os seus primeiros entendimentos e a busca de seus caminhos em direção à Governança de dados e de informações. Desafio puro. 


terça-feira, 7 de fevereiro de 2012

Governança de Dados-Parte-I-Introdução


Qualquer empresa que mantenha intenções de competitividade nesta arena leonina dos anos 201x deverá ter, além da preocupação com a melhoria dos processos, um foco também  no outro lado do espectro: os dados. Essa dualidade entre dados e processos sempre existiu e mostra que esses dois pilares são fatores críticos em empresas que intencionam seguir os caminhos da reputação, via qualidade. Fazendo uma comparação superficial é como entender que um bom prato é fruto de uma boa receita (processo) e de bons ingredientes (dados). Se um dos dois não estiver adequado, o produto final poderá perder em qualidade. Além disso, como a proposta de BI (Business Intelligence) é transformar dados em informações que possam ser usadas para ações analíticas, tomadas de decisões tático-estratégicas e até definições operacionais, a qualidade dos dados que serve como input para o BI se reveste, cada vez mais, de extrema importância. Lembre-se de que BI é um processo fundamentalmente transformador e logo a qualidade do seu input irá refletir diretamente na correção das tomadas de decisões efetuadasNos anos 80, após a consolidação das técnicas de Bancos de Dados, com a cristalização das funções de ABD-Administradores de bancos de dados, surgiu o conceito de Administração de dados(AD). Diferentemente da proposta de ABD(Administração de Bancos de Dados), que objetivava a gerência das bases de dados, a partir do controle centralizado dos seus gerenciadores (SGBD), a AD(Administração de Dados) tinha uma visão muito mais ampla e  penetrava  nos domínios conceituais dos dados . A ideia de AD era criar uma grupo, com visão centralizada sobre os dados, independentemente de onde esses recursos estivessem armazenados(SGBD, ou arquivos VSAM, etc), dando a esses ativos um status um pouco maior do que meros habitantes das estruturas hierárquicas ou relacionais dos gerenciadores. Um pouco mais do que tabelas, chaves primárias, índices, etc. Várias empresas criaram então, esses núcleos de AD, com variantes na sua posição hierárquica. Algumas ousaram colocar a AD em níveis elevados, próximos às gerencias superiores. Uma das que me recordo colocou o AD ligado à vice-presidência  e outras colocaram a AD nas vizinhanças da ABD, devido à afinidade que os dados, no plano físico(SGBD), teriam com os dados no plano conceitual(AD). Espremendo bastante, a prática de AD acabou por não funcionar a contento. O conceito de AD foi aos poucos se diluindo por diversos fatores, sendo o principal a falta de percepção dos dados como um ativo empresarial.  A área de AD, naquela época seria a responsável pela manutenção dos modelos conceituais dos dados, modelando, entendendo, gerenciando, documentando e mantendo sob controle os elementos seminais como entidades, relacionamentos, atributos e regras que gravitam em torno do conceito elementar de dado. Os bancos de dados, antes de serem criados, deveriam passar por um crivo conceitual, mapeando os dados necessários àquela aplicação, com os já existentes e catalogados nos modelos que estavam sob as chaves da AD. Com a fragilidade sobre a percepção corporativa dos dados, que deveriam ser vistos  como um recurso organizacional, mas não eram, as coisas não andaram bem. Os dados continuavam entendidos como combustíveis imediatos para aplicações que se desenhavam e as regras que definiam a obrigatoriedade de  seus controles em modelos conceituais, começaram a ruir. O fato de que a AD estava, na maioria de suas estruturações, colada nas imediações da ABD e subordinada à TI, também serviu, paradoxalmente como alavanca para essa abaixa adoção de AD. A TI, que deveria resolver,  criar  e rodar os sistemas demandados pela empresa, premida pela força dos cronogramas, era a primeira a dar dribles de corpo na AD, liberando a ABD para criar os dados necessários, na forma desejada, e o que era pior, nas duplicações que fossem necessárias. Com a chegada da microinformática e o consequente  aparelhamento computacional nas unidades de negócios, os dados se espalharam mais ainda.  Assim, pela força do imediatismo, a própria TI minou a ideia de AD. Como a TI era, em tese, a “mãe” dos dados, ela própria abortava um conceito, priorizando a rapidez de suas entregas.
Esse foi o primeiro erro fatal: Os dados, que deveriam ser vistos como da empresa, tiveram a sua administração estabelecida longe daqueles que realmente conhecem e entendem esse insumo, ou seja os seus criadores e consumidores, que habitam as áreas de negócios. A TI, mera processadora deles, definitivamente não era o melhor lugar para acolher o conceito de administração de dados. Assim surge a primeira lição aprendida: Os dados não são da TI , são das áreas de negócios e sua administração deve ser do “business” , com a TI tendo um papel de partícipe  muito importante, porém de co-responsabilidade. Diferentemente da administração financeira, de recursos humanos, de materiais, etc, a de dados nasceu no lugar equivocado, inspirado por motivações nobres, porém não firmemente estabelecidas  e nem abençoada pela aquiescência do “business”.
Outro fator importante que contribuiu para essa morte precoce, foi o advento dos ERP´s. Com a aproximação do final do século, o problema do bug do milênio agilizou a necessidade de se buscar soluções prontas que integradas e harmonizadas nos dados e processos, resolveriam uma boa parte das aflições existentes naquele momento. Assim, os ERP´s, como SAP, JDEdwards, Oracle Application, DataSul, etc já traziam no seu arcabouço, os dados já definidos, padronizados e integrados. Isso de certa forma, esfriou as ações da AD, que justamente se preocupava  com esses elementos, que agora vinham prontos, modelados e blindados nos caros e complexos pacotes aplicativos. Dessa forma, por causa desses fatores, dentre outros, a AD passou de uma boa idéia para um conceito com um obituário anunciado. Embora em algumas empresas o nome AD tenha até sido preservado, ele simplesmente  ficou como uma célula inoculada pelo pecado maior: estava sob o controle da TI e sem a cumplicidade da área de negócios. No vácuo do conceito de AD deixado para trás,  surgiram, na maioria das empresas, uma série de problemas que hoje estão potencializados. Bancos de dados, que deveriam em tese, ser depósitos de dados únicos, formando a verdade “única” sobre as informações de consumidores, clientes, colaboradores, materiais etc  falharam no seu objetivo. Hoje são encontrados diversos bancos de dados sobre o mesmo “assunto”, contendo informações divergentes sobre elementos mestres da empresa. Os dados, além de duplicados, foram definidos sob variados padrões semânticos, não permitindo a inferência de que representam a mesma entidade, ou o mesmo atributo. Os dados, incluídos nos Bancos de dados, não necessariamente tiveram a sua metadefinição, ficando atrelado a mnemônicos por vezes ininteligíveis, como cod-cli, ou dat-vc-fat , o que dificulta a sua interpretação. Soma-se à duplicação de dados, o estranho fato de não se saber se, mesmo replicados, eles representam a mesma “coisa”. Com o beneplácito da TI, premida pela rapidez nas soluções, os dados se espalharam em unidades de negócios, habitando sistemas paralelos, ou esquadrilhas de planilhas excel, sobre os quais se perdeu o controle. Dessa forma, os dados espalhados nas corporações não observam hoje aspectos mínimos que garantam: integridade, precisão, disponibilidade, atualidade etc. Com o surgimento dos sistemas de BI turbinados pela necessidade de informações para tomadas de decisões, o problema se potencializou, se instalando, agora, no mundo das informações. Os dados, com seus problemas acumulados,  começaram a produzir informações carentes de credibilidade.
Com o advento da Web, o informática alavancou a criação exponencial de dados. O que era, até então, produto de sistemas estruturados, começou a ser produzido nas formas de emails, clickstream, posts de blogs, redes sociais, etc. Surgiu o conceito de Big Data, já discutido em posts anteriores. Com eles, o problema de qualidade e controle dos dados produzidos ou consumidos na empresa se potencializa pela diferenciação no volume e nos tipos de dados.   
A apatia que se estabeleceu sobre esses importantes ativos organizacionais deverá ser revista com os cuidados demandados pela sociedade da informação. Assim, os conceitos de Governança Corporativa e de TI  foram estendidos  para os domínios de Governança de Dados, visando não somente à organização desses acervos, mas também a aspectos típicos desses novos tempos. Os cuidados singulares com a  segurança de dados, a necessidade da sua definição clara e sem ambiguidade, uma maior fluidez na sua distribuição e um uso democrático e controlado se tornaram alguns drivers dessa nova fronteira.  Além disso, existem alguns vetores apontando para o fato de que em alguns países, a governança de dados poderá ser obrigatória em breve, dentro de uma capa regulatória, que demandará que o valor dos dados seja considerado um ativo da empresa e  que a sua qualidade seja traduzida em métricas, compondo indicadores-chave de desempenho da área de TI. Isso foi definido pelo fato de que a qualidade dos dados implica riscos corporativos que a nova TI e o novo papel de CIO deverão estar preparados para mitigar. Diferente dos tempos quando os dados eram simples combustíveis de programas Cobol, ou eneplicados aos borbotões pelas áreas negociais das empresas, agora eles se tornam elementos fundamentais do capital intelectual da empresa, geradores que são de informação e conhecimento. Só isso....