Depois de analisarmos várias escolas de Governança de dados,
aqui vai uma espécie de “Road map” de GD,
ou os 12 Mandamentos, que devem ser observados quando falarmos de sua
implementação prática nas empresas:
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 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;
2)Definir políticas para a conceituação
de Dado, como um ativo(asset) da empresa e diretrizes para a formação do Comitê
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 Governança de dados na empresa;
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. 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 envolvidas, 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;
5)Selecionar as bases 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;
6)Analisar as lacunas observadas e o nível de maturidade
atual em dados. 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;
7)Pensar a GD em camadas
funcionais distintas, com papéis definidos e pessoas
alocadas:
·
A camada estratégica, onde está o Comitê 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. 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;
8)Iniciar ações para conhecer e entender os dados existentes
através de levantamento de termos de negócios, visando a formação do
repositório de metadados, contendo definições, relacionamentos e áreas de
negócio responsáveis pela sua criação, custódia e consumo (CCC);
9)Pensar a Governança de dados em alguns projetos
específicos com 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 no item 4. 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, garantia da qualidade, 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. Ver mais adiante detalhamento sobre
maturidade em BI, conforme pesquisa da TDWI.
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;
10)Sempre atuar com o conceito de “quick hits”, ou seja
realizando projetos que retornem rapidamente resultados visíveis e
importantes;
11)Definir procedimentos de monitoração
dos projetos, através de ações 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;
12) 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.
Se você quiser criar uma memória sintética , pense nos “9 P”
da GD, grifados até aqui, ao longo do
texto:
1)Patrocínio
2)Políticas
3)Processos
4)Padrões
5)Papéis e Pessoas
6)Procedimentos
7)Programas/Projetos(Planos)
Com esse artigo, encerramos o primeiro bloco que objetivou o
entendimento dos conceitos alicerces de GD através de várias óticas. No próximo
bloco de posts discutiremos os aspectos de Maturidade em GD, analisando várias
propostas de modelos de maturidade, inclusive uma baseada nas premissas e
experiências obtidas nas diversas implementações de modelos de maturidade para
software: MGD-Melhoria de Gestão de Dados.
Nenhum comentário:
Postar um comentário