Total de visualizações de página

terça-feira, 4 de março de 2014

Implementação prática de MGD-Melhoria de Gestão de Dados-Parte IX

Depois de analisarmos os aspectos de Gestão e Governança de dados, envolvendo os conceitos de DMM e DMBOK,  vamos discutir os passos necessários para se estabelecer, de forma prática, os trabalhos de implementação da MGD-Melhoria de Gestão de Dados. Nesse particular, a empresa poderá adotar os conceitos do DMM-Data Maturity Model, ou do DAMA(Data Management Association), convergentes como mostrado nos posts anteriores. A aplicação de DMM permitirá um caminho mais incremental, em direção à uma maturidade de dados. O da DAMA sugere um conjunto de melhores práticas, mas não define camadas de maturidade. Ambos são trilhas certas e inclusive, podem ser adotados de forma conjunta, permitindo que a empresa estabeleça a sua MGD-Melhoria de Gestão de Dados.

1)Criação de um grupo de estudo,  envolvendo a TI e as áreas de negócios  cujos dados sejam mais sensíveis e críticos, como dados financeiros, de clientes, de vendas, etc.  É fator absolutamente crítico de sucesso o alto envolvimento das áreas de negócios, com a busca de patrocinadores fortes e comprometidos com a melhoria da gestão de dados. Dessa forma, você deve
·        Entender os problemas existentes
·        Entender e levantar os principais objetivos de  melhorias de dados e ter uma visão clara de como isso acontecerá;
·        Levantar e identificar prioridades em solução de dados: áreas, processos, dados, regras de negócios, tudo balizados pelo incômodo dos  problemas e apreensões existentes nessa ;

2)Definir políticas para a conceituação de Dado, como um ativo(asset) da empresa e diretrizes para a formação do Conselho de Governança de dados da empresa. As políticas deverão ser regras gerais “consensadas”  entre as unidades organizacionais envolvidas e aprovadas pela alta gestão da empresa e deverão ser parte de processos e padrões definidos para a Gestão/Governança de dados na empresa. Começar a pensar nas pessoas envolvidas;

3)Definir os riscos de dados “impuros” (data flaws) ou como os aspectos de baixa qualidade dos dados criam impactos nos negócios da empresa, na sua reputação ou na produção adequada e confiável de informação. A definição de riscos potenciais ou  de “business cases” de problemas derivados de qualidade de dados é fator crítico na aprovação de um Programa de Governança de dados, pela alta gerência e fundamental para sua sensibilização ;

4)Inventariar nas  áreas definidas, TI inclusive, as principais fontes de dados, de forma a se ter uma visão do grau de replicação de arquivos considerados críticos, como BD de Clientes,  de Pessoal, de Materiais, Financeiro, etc; Esse item, que oferece uma visão qualitativa do problema, compõe parte do item 3 acima descrito;
·        Levantar e identificar os Dados, metadados e envolvidos naquela área/ assunto prioritário analisando e catalogando as informações;
·        Selecionar as fontes de dados consideradas mais críticas para tratamento quantitativo de qualidade. Buscar e aplicar soluções de “data profiling” em bases escolhidas baseadas em priorização, visando demonstrar o grau de qualidade dos dados considerados críticos;

5)Analisar as lacunas observadas e o nível de maturidade atual no assunto dados. Observar qual o grau de pré-disposição das áreas com relação ao compartilhamento e “proprietarismo” de dados. Isso poderá indicar o grau de dificuldade nas ações de GD. Com eles, fazer a  proposição de plano de ação, que poderá envolver  a criação de gestores de dados(data steward) localizados em áreas críticas de negócio da empresa. Os gestores de dados atuam em áreas funcionais/linhas de negócios com a responsabilidade de aplicar e preservar as políticas, regras , diretrizes de qualidade, como criação, uso, replicação,etc;  Alguns gestores comporão a camada tática da GD, através do Comitê de Gestores, juntamente com o CDO(autoridade em dados na empresa, caso haja) e com o grupo responsável pela implementação das ações de GD na empresa(DMO-Data Management Office ou DGPG-Data Governance Process Group), semelhantemente ao SEPG das implementações CMMI e MPS.BR

6)Assim, definir  a GD em camadas  funcionais distintas, com papéis definidos e pessoas alocadas:
        A camada estratégica, onde está o Conselho de GD, ou de Conselho de Dados, ou que nome venha a ter. Formado por gerentes funcionais de áreas (TI, inclusive), terá o objetivo de estabelecer  as políticas e diretrizes que definem o dado como um ativo da empresa. Resolverá impasses que certamente surgirão e será uma espécie de Comitê Consultivo;
       A camada tática com o Grupo de implementação do programa de GD(CDO-Chief Data Office, ou DMO-Data Management Office, ou DGPG-Data Governance Program/Process Group), formado pela gerência média, responsáveis pela execução dos planos de ação. Aqui entrará o Comitê dos Gestores de Dados, formado pelos gestores das áreas funcionais. As palavras chaves aqui são: envolvimento, cooperação e convencimento por resultados concretos. A gerência de uma área de negócios deverá ter pleno entendimento das definições de GD, vindas do Comitê acima, a fim de apoiar as ações de seus gestores de dados e as definições do CDO/DMO/DGPG;
·       A camada operacional, com os gestores de dados(data steward) alocados nas áreas e linhas de negócios, responsáveis pelas atividades do dia a dia. Por exemplo, na área de Faturamento de uma empresa de energia elétrica, poderá haver gestores de dados divididos em domínios ou subdomínios, como faturamento secundário/primário/grandes consumidores de alta tensão, etc. O aproveitamento de recursos humanos nas áreas de negócios, com grande conhecimento do assunto(subject área) pode ser considerada  uma excelente estratégia na definição dos gestores de dados(data steward). Esse conceito é chamado “Governança de dados não invasiva”, e foi definido por Robert Seiner, da Kikconsulting, especialista em Governança e Administração de dados;
        Pensar nas Pessoas e Papeis(Estrutura  Organizacional)
       Não se esquecer de buscar o apoio executivo fundamental nos CxO
       Não se esquecer dos envolvidos nos dados, owners de dados, responsáveis pelo uso dos dados nas áreas de negócio
       Não se esquecer da camada tática envolvendo o DMO, ou o DGPG e  Comitê dos gestores de dados
       Não se esquecer dos Gestores de dados(de negócios e de TI), com suas variantes nos projetos SDLC(project data stewards). Pensar nos Gestores de dados de áreas cujos dados serão compartilhados (domain data stewards)

7)Pensar a Governança de dados em interação com  alguns projetos específicos,  com seus respectivos planos, selecionados pela prioridade, definidos em programas, como MDM(Master Data Management), Segurança de dados, Qualidade dos dados para tomada de decisão(BI com Analytics), Dados não estruturados(Geo-BI, por exemplo),etc. Por exemplo, na trilha MDM, identificar as ações para reduzir as replicações de fontes de dados críticos(Consumidor, Órgãos, Produtos, etc) , levantados nos itens anteriores. Envolver as áreas de negócios que atuam no domínio daquele dado e criar ações alinhando “business e TI”. Esses projetos devem ser vistos como iterações do processo maior de GD, aplicando-se  neles as atividades de identificação de metadados, definição de métricas(processo de MED), garantia da qualidade(processo de GQA), etc.  Na trilha de BI com Analytics, considerar aspectos de governança no sentido de identificar por áreas de negócios: os seus usuários, os relatórios ou cubos produzidos e consumidos, o valor de retorno dessas informações de BI para o usuário, freqüência e tipo de solicitações atendidas, etc. Esse trabalho deverá ser feito com envolvimento do Núcleo de BI  e apontará , de certa forma, o grau de maturidade com que a área de BI atua. Na camada de dados não estruturados, entender que 80% dos dados de uma empresa hoje estão na forma semi ou não estruturada. Assim aspectos relacionados com dados de mapas, GED (Gestão Eletrônica de Documentos), etc devem ser observados  e também  merecer os olhares da GD;

8)Sempre atuar com o conceito de “quick hits”, ou seja realizando projetos que retornem rapidamente resultados visíveis e importantes;
        Seja prático:
       Sempre mostre valor nas ações e processos;
       Elementos de dados chaves devem ter os seus gestores de dados definidos, os seus processos e responsabilidades definidos, como  manutenção de metadados, resolução de pendências,etc ;
       Os elementos  de dados chaves a serem escolhidos, normalmente tem sabor “financeiro”, ou seja elementos de relatórios financeiros, aspectos de “compliance”, riscos regulatórios, outros dados sugeridos por alto escalão, ou pelos próprios GDN(gestores de dados de negócios);
       Identificar a função de negócio que possui o Dado(ou a mais importante). Embora o dado seja usado por várias funções de negócios, a escolha da “master” poderá ser feita observando as mudanças e impactos que aquele dado acarreta em quais funções. Quais funções fundamentalmente são impactadas  quando o dado muda? É uma diferença entre “USAR” e  “DEPENDER”  do dados. A segunda pergunta é: Onde o dado se origina, seu nascimento, a sua criação e por conseguinte a sua cadeia e ciclo de vida.

9)Definir procedimentos de monitoração dos projetos, através de ações de processos/procedimentos  de  medições(MED) ou de garantia da qualidade(GQA), criando indicadores, como número e tipos de “incidentes” relativos a dados, problemas de reclamações externas devido a erros de dados, não-conformidades com definições regulatórias detectadas, etc;

10) Por fim, entender que GD é um  programa e não um projeto isolado e portanto tem características contínuas, e que o processo desenhado para implementá-lo deverá ser constantemente avaliado por medições e ganhos tangíveis, o que viabiliza a sua continuidade e minimiza os riscos de seu colapso. 

11)Se você quiser criar uma memória sintética , pense nos “ Ps”  da GD, discutidos até aqui, ao longo desse contexto:
1)Patrocínio
2)Políticas
3)Processos
4)Padrões
5)Papéis e Pessoas
6)Procedimentos
7)Programas/Projetos(Planos)
8)Performance(MED-Medições  e GQA-Garantia da Qualidade)
9)Plataformas
10)Palavras(Comunicação) 

12)Considerações sobre a implementação de MGD-Melhoria de Gestão de Dados e o tamanho de empresas: A GD se caracteriza por um esforço , hoje ainda encontrado em grandes organizações. Isso entretanto não invalida a sua aplicação em empresas menores(SMB) fazendo as suas devidas adaptações. Algumas ações sugeridas acima poderão ser implementadas facilmente nas pequenas empresas, como o entendimento de seus problemas relacionados aos dados, a descoberta e catalogação de suas fontes principais de dados, além da definição dos P das GD(se não de todos, de alguns). Há ferramentais livres e open que podem ser usados. A estruturação das camadas de GD poderá ser adaptada, visto que em empresas pequenas, poderemos ter uma camada enxuta de GD, com os donos fazendo o papel de Conselho de GD e um recurso alocado parcialmente para as funções de gestor de dados, eliminando-se a camada tática. A nossa experiência em implementações de melhorias de processos em quase 100 empresas de variados portes em MG, nos credencia a garantir que a MGD poderá ser também implementada no segmento de SMB. Ao adotar uma abordagem de MGD-Melhoria de Gestão de Dados, essas empresas estarão se preparando de forma adequada  para o seu crescimento sustentável em termos de controlar esse ativo fundamental em qualquer empresa: os dados e as informações deles originados. Agindo agora, evitarão ou minimizarão os efeitos negativos futuros de uma gestão imprópria de seus dados.


Nenhum comentário:

Postar um comentário