4)Com os
resultados do passo anterior, construir um Plano de GD, com foco nos “Ps” como Pessoas e Papéis, Processos, Patrocínio,
Procedimentos e Planos detalhados . O objetivo do plano é “encaminhar soluções”
sobre as lacunas mostradas no passo
anterior. Poderá ser um Plano ou um programa contendo vários projetos.
5)Definir
uma estrutura organizacional: Nesse passo, deverão ser pensadas as formas de
estruturação de pessoas e papéis, a fim de se criar o arcabouço organizacional
da GD. Uma das propostas mais encontradas é a definição de três(3) camadas: No
alto, um Conselho, formado por pessoas influentes nas áreas “targets” do
programa, como vice-presidentes de marketing, ou de finanças, ou de logística,
etc. Esse conselho será o tira-teima dos problemas que certamente aparecerão em
função da falta de “ownership” de dados nas empresas. No segundo nível aparece
o que poderia ser chamado de DMO-Data Management Office, que seria uma gerência
constituída por uma liderança tática definida, vindo da área de business, com participação
de elementos da TI. Essa camada, representa o nível gerencial tático sobre os
dados da empresa, da mesma forma que os PMO estabelecem controles sobre os
projetos da companhia. Na terceira camada, no nível mais operacional, ficariam
os “gestores de dados”, ou data steward, elementos escolhidos e lotados em cada
área de business envolvida no projeto, com o objetivo de aplicar os conceitos
de gestão sobre os dados daquele domínio. Seguirão os processos e regras
definidas nos níveis hierárquicos anteriores. Há algumas proposições sobre o
tipo de Data steward(gestor de dados):
·
Orientado
a sistemas: Essa abordagem define o gestor(steward) associado a um ou
mais sistemas de informações. Por exemplo, um gestor de dados que tomaria conta
(dos dados) dos sistemas de Faturamento e Arrecadação do SAP para empresa “utilities”.
Normalmente ficam situado no âmbito da TI-Tecnologia de Informação, o que pode
sugerir dificuldades na venda da idéia para toda a empresa ;
·
Orientado
a unidade organizacional: Essa
abordagem define o gestor de dados num nível funcional, dentro de uma unidade
da empresa. Por exemplo, a área de Faturamento poderia ter um data steward, que
seria o gestor para os dados que circulam por aquela unidade organizacional.
Ele estaria gerindo outros dados de outros sistemas, que estivessem naquela mesma
unidade da empresa, expandindo o escopo da proposição anterior;
·
Orientado
para Assunto: Essa abordagem define
o gestor de dados num âmbito corporativo, ficando com a incumbência de gerir o
dado de forma mais ampla, num conceito de Entidade, ou “assunto”. Isso
perpassaria várias unidades organizacionais e vem ao encontro do conceito de
MDM(Master Data Management) . Assim um gestor seria responsável pelo assunto
Cliente, Fornecedor ou Conta, etc, com forte associação com o conceito de dados
mestres. Tem a vantagem da visão mais completa, porém sugere maiores
dificuldades na sua implantação. Essas
diferentes estratégias de definição de gestores de dados, tem graduações
proporcionais de dificuldades de implementação e dependerão da maturidade da
empresa. A mais facilmente implementada é aquela mais focada em sistemas de
informações e a mais difícil esta relacionada com a visão mais corporativa de
dados e sua gestão como um ativo da empresa.
·
Ver
os conceitos ilustrados nas figuras abaixo (final do texto) com a separação em 3
níveis hierárquicos e o posicionamento organizacional dos Gestores de Dados,
conforme algumas soluções: Visão corporativa(Assunto),Visão de Unidade
Organizacional e Visão de Sistema de Informação.
6,7,8)Entender
os dados, construir o Dicionário de Dados e criar um repositório de metadados
podem ser vistas como etapas de prospecção e mergulho nos dados existentes
naqueles domínios em estudo, objetivando o pleno entendimento de seus
depósitos, campos, descrições, dicionários, etc, visando a criação de uma
camada documentacional . O Dicionário de dados ajuda no entendimento dos dados
existentes e o repositório de metadados seria a sua extensão com a criação e
merge dos metadados técnicos (advindos
das inspeções e descobertas de BD), e dos metadados de negócios, advindo dos
DD, caso existentes. Os principais passos para se alcançar esses objetivos
seriam:
·
Baseado
no domínio de estudo, identificar as principais fontes de dados, ou seja:
tabelas de bancos de dados, tabelas dimensões de sistemas analíticos, arquivos
independentes, arquivos manuais, etc
·
Identificar
e entender os principais tipos de dados,
segundo a classificação:
o
Dados
Mestres, ou seja os objetos, pessoas,
clientes, fornecedores, vendedores, colaboradores, representando os diversos
papéis de relacionamentos da pessoa
física ou jurídica com a empresa. Alguns autores ainda classificam os dados
mestres de acordo com a sua volatilidade. Por exemplo, dados mestres do tipo Contrato
normalmente são mais estáticos depois de criados, enquanto que dados mestres de
Clientes
podem ser mais voláteis, quando esses elementos|(clientes) evoluem no seu ciclo
de vida;
o
Dados
Transacionais, ou seja aqueles normalmente com uma ou mais referência temporal,
como Ordens de pedido, Notas fiscais, Ordens de compra, lançamentos,etc;
o Dados de Referência, ou seja lista de valores padronizados
(paises, estados, datas, códigos, etc), usados em codificações ou
decodificações, com o objetivo de trazer maior clareza sobre a definição do
dado. Alguns exemplos: dados de códigos postais(CEP) com associações com unidades
geográficas, dados de códigos de padrões universais de produtos e serviços,
como UNSPSC( convenção hierárquica, definida e adotada pelas Nações Unidas - de
âmbito e aplicação mundial, usada para classificar todos os tipos de produtos e
serviços). Os dados de referência estão próximos dos dados mestres, com um
sabor mais de origem externa(nem sempre)
e codificado. Ambos (Mestres e
Referências) são fundamentais na geração dos dados transacionais
o
Metadados,
ou seja os dados sobre os dados, que podem ser técnicos, como nome,
comprimento, lay-out, array, etc ou de negócios
que são usados para aplicações no entendimento do negócio(títulos, nomes de
telas, estatísticas, páginas web, etc), ou metadados de auditoria, com dados como
tipo de informação para rastreamento, visando proteção, recuperação, quem,
quando, como , o porquê, audit, log, etc;
o
Dados
Históricos, que são dados de variadas naturezas(Mestres, Transacionais), com
referência passada de tempo, normalmente não mais alteráveis e usado como
registro de fatos acontecidos e de valor
histórico;
o
Dados
Temporários que são dados usados em certas circunstâncias técnicas, na memória
de sistemas, por exemplo, como elemento de otimização de tempo, performance,
constantes, etc.
·
Criar
os modelos de dados, casos inexistentes, ou entendê-los casos existam, a fim de
produzir a visão documentacional composta por entidades, relacionamentos e
atributos chaves e atributos
descritivos;
·
Criar
os repositórios de metadados, com os elementos do tipo técnico, de negócio ou de
auditoria.
9)Definir
métricas: Esse passo é fundamental como estabelecimento de baselines que serão
confrontadas após os ciclos dos programas de GD, que objetivam melhorar a
performance dos dados. Serão as definições de KPI´s de natureza técnica e de negócios. Os
conceitos fundamentais sobre medidas e medições são:
•
Medidas
são valores numéricos que representam extensão, quantidade, tamanho, dimensão
ou capacidade de um produto ou de um processo. Por exemplo, são expressas
por metro linear para comprimento,
escala Richter para intensidade de terremoto, metro cúbico para volume,
quilograma para peso, contadores para registros/eventos para medidas diversas dentro do processo de
desenvolvimento de sistema, etc. São normalmente definidas por convenção;
•
Métricas
representam o valor resultante do ato de colocar as medidas numa escala de
relatividade. Por exemplo, metros cúbicos/hora, metros/segundo, quantidade de
não conformidades (NC) na Fase de Elaboração, Esforço Realizado e Esforço
Planejado em homens/hora estimado no mês de setembro de 2007, no projeto XABC,
etc.;
•
Medição
representa o ato ou processo de levantar medidas/métricas sobre produtos e
processos com o objetivo de prover informações para uma análise e/ou tomada de
decisão;
•
Indicadores
são informações relacionadas a uma medida, métrica ou combinação de métricas
que pode ser utilizada para ter uma compreensão de uma certa entidade objeto da
análise;
•
Um
exemplo que ilustra os conceitos: quando você realiza uma avaliação para
começar a “malhar” numa academia, uma das métricas obtidas é o seu índice de
massa corporal, que indica se você está com seu peso ideal ou não. Para tal,
duas medidas são importantes: altura (H) e peso (P). A medição é o ato de
levantar essas duas informações. Existe uma métrica chamada “índice de massa
corporal (IMC)” que é calculada, em função das duas medidas, segundo a seguinte
fórmula: IMC = P / H2. A partir dessa
métrica, foram estabelecidos indicadores que apontam se um adulto está acima do
peso, se está na faixa aceitável ou abaixo do peso ideal. Por exemplo, para que
uma pessoa seja considerada dentro do peso normal, o IMC deverá estar entre
18,5 e 25. No ambiente de Processos de
Software existem várias medidas que poderão ser obtidas, dentro dos domínios de
tempo (tempo estimado e tempo realizado para certa atividade ou conjunto
delas), custo (custo estimado e custo realizado para certa atividade ou
conjunto delas), qualidade (número de defeitos observados em certas atividades
ou conjunto delas), esforço (esforço em homens/horas estimado e realizado para
certa atividade ou conjunto delas). As métricas poderão ser obtidas por
operações realizadas entre essas medidas. Por exemplo, o valor agregado é
definido como a percentagem de conclusão de uma atividade declarada no ato da
medição multiplicada pela quantidade de horas planejadas para a realização
daquela atividade. É importante definir para cada medida/métrica os limites ou
faixas que representem valores bons, aceitáveis ou inaceitáveis. Por exemplo,
se a densidade de defeitos for menor do que X defeitos por ponto de função, ela
é considerada boa. Com valores entre X e Y ela é considerada mediana, e maior
do que Y ela é considerada inaceitável. Normalmente, para essas situações de
limites críticos, o processo de medições da empresa deverá definir ações a
serem implementadas, visando a correções ou ajustes a respeito.
Do ponto
de vista de GD as métricas deverão centrar em informações que agreguem valores
ao negócio, principalmente no que tange a aspectos de dados relacionados com
conteúdo, disponibilidade, integridade, segurança, etc e que possam implicar
riscos e perdas no escopo do negócio, de sua credibilidade, de aspectos de aderência a padrões,etc. Por
exemplo, um campo código que indique uma classificação industrial ou geográfica
poderá ter implicações sérias de riscos, caso não estejam adequadamente
preenchidos. Uma análise de risco, numa instituição financeira, aplicada por
tipo de indústria, poderá perder o seu valor caso esses códigos não esteja
devidamente corretos e íntegros. O mesmo se aplicaria para estratégias a serem
aplicadas em áreas de um país, com códigos regionais frágeis e sem qualidade. Um
número de telefone, elemento de informação que pode ser importante em ações de
marketing, por vezes, deverá ser validado contra arquivos externos oferecidos
por provedores, como companhia de telecomunicação. O quanto dessas verificações
resultaram em acertos poderia ser uma métrica sobre campos de telefones. Da
mesma forma, a incidência de registros duplicados de fornecedores, vendedores,
colaboradores, etc pode ser uma medida a se gerenciar, buscando-se
gradativamente a sua minimização. A verificação de data de nascimentos de
grandes arquivos mestres pode apontar erros como um número excessivo de pessoas
com mais de certa idade, ou com idades impossíveis. Um medida sobre essas
discrepâncias poderia ser feita em sistemas que apoiam linhas de negócios onde
a idade do cliente, paciente, colaborador é considerada importante. Consistências
em CPF ou no número da carteira do plano de saúde podem ser importantes em
certos domínios de negócios. Essas métricas estariam, de certa forma, atreladas aos aspectos de negócios da empresa.
Outras métricas, poderiam ser definidas, associadas aos aspectos de
documentação dos dados(metadados), como ausência de informações de origem de
certo arquivo, no que são chamados metadados órfãos, ou seja não trazem os
dados completos de sua origem. Por exemplo, um arquivo documentado sem a
informação do seu departamento de origem(orfandade ou a ausência de linhagem
dos dados). Métricas também podem ser definidas em certos assuntos emergentes
como dados não estruturados, com medições de percentagem de documentos de
negócios que estão sendo preparados para buscas de text mining. Indicadores de
BI, como número de usuários, relatórios e suas execuções, por área de negócios,
grau de atendimento da área de BI, etc. As métricas, ensina Sunil Soares, no
seu Selling
Information Governance to the business practices, devem ser D.A.T.A, ou
sejam: Digestible, ou facilmente digerida por quem as consome. Para
tal deve ser concisa, clara e objetiva. As métricas devem ser Actionable,
ou seja devem sugerir ações concretas quando atingirem certos limites
estabelecidos; Timely, ou disponíveis no tempo, ou seja devem ser entregues no
menor tempo possível, encurtando a distância entre o ponto de sua captura e o
momento de sua análise e consumo; e Auditable, ou auditável, no sentido
de que os números obtidos naquela métrica devem ser rastreados de volta ao
ponto da coleta ou captura, a fim de oferecer uma tonalidade de
confiabilidade.
10)A partir desse ponto, o road map da IBM,
sugere trilhas paralelas, que poderão ser projetos fundamentais do Programa de
GD, como: Governança de Dados Mestres, com a definição de gestores de dados de
áreas de domínios envolvidas, gerenciamento da qualidade dos dados desses DM
analisados, e definição de soluções
arquiteturais para MDM dessas fontes. Figuras:
