Blog que objetiva a discussão de conceitos de Governança e Gestão de Dados com os serviços de DM (Data Management) associados(Arquitetura,Modelagem de dados,BD,DWBI,MDM,DNE,Qualidade de dados,Metadados,etc) Também aspectos de maturidade via modelos MPS.BR,CMMI(ambos para Eng de SW) e DMM (Dados), além das novas formas e influências dos dados na sociedade digital.
Total de visualizações de página
quinta-feira, 18 de maio de 2017
segunda-feira, 8 de maio de 2017
Governança e Gestão de dados na prática-Parte X-final
Visão
DMM-Data Management Maturity Model
Numa outra
opção, poderia ser usado o modelo DMM do CMMI Institute, como referência para
aferição de maturidade. Aqui poderá haver duas abordagens distintas: Um assessment
formal, realizado por instituições credenciadas e autorizadas, o que
conferirá uma certificação reconhecida pelo CMMI Institute e outra abordagem,
usando os mesmos elementos de gestão de dados, sem um objetivo de busca de um
certificado, somente trilhando os conceitos públicos e abertos de Governança e Gerência de dados, aplicados também os
conceitos de capacidade e maturidade do CMMI e MPS. O modelo DMM é parte da
família desses modelos de qualidade, e guarda semelhanças também com o modelo
MPS(para software, serviços e pessoas), que também teve sua gênese no CMMI e em
normas ISO. O modelo foi desenvolvido
pelo CMMI Institute e contou, na sua equipe de revisão, com 3 brasileiros:
Antônio Braga(Crest Consulting), Carlos Barbieri(CBCA-Fumsoft) e Mário Faria,
hoje radicado nos EUA. Figuras expressivas da área de dados dos EUA, como Peter
Chen e Bill Inmon, entre outros, foram também da equipe de revisores do DMM. O
modelo já foi traduzido para o português.
Áreas de Processos:
A ideia
central, conforme o modelo lógico da figura 11 guarda semelhança com os outros
modelos da família. Há as categorias, por onde se distribuem
as PA´s(Áreas
de processos), que são compostas de práticas funcionais. As práticas
funcionais, por sua vez, estão categorizadas pela capacidade (no fundo a
forma mais ou menos evoluída/amadurecida com que elas são realizadas),
graduadas em 5 níveis(de 1 a 5), guardando certa semelhança com o modelo aplicado
e descrito anteriormente
(1-Realizado,2-Gerenciado,3-Definido,4-Medido,5-Otimizado). A figura 11 ilustra o modelo DMM,
com suas categorias e os atributos de capacidade.
A figura 12 mostra os
detalhes de Áreas de Processos por categorias(sem decomposição de práticas funcionais).
Figura-12-Tabela
de Categorias e Áreas de Processos-Modelo Data Management Maturity
(página 5) versão em Português
No nível 1, essas práticas podem ser realizadas,
digamos de forma restrita, sem grandes controles, normalmente em projetos
isolados sem processo previamente escrito ou controlado. Digamos que, isso é feito
numa iniciativa “particular”, motivada por uma área ou pessoa.
No nível 2, as práticas são realizadas já
com certa gerência, em projetos associados(um ou mais projetos), através
de um processo que foi escrito para que elas(as práticas) seguissem um roteiro.
Aqui poderemos já ter uma GD(Governança e Gerência) inicial e localizada. Observe que já há uma
evolução com relação ao nível anterior.
No nível 3, as práticas já estão com um
viés organizacional, havendo um controle de gestão e governança sobre elas. Já
há um processo relativamente padronizado e definido para a sua aplicação e
todos devem seguir esse processo padrão, ou solicitar adaptações caso ele (o
processo padrão) não atenda às
especificidades daquela aplicação.
No nível 4, temos que a empresa já está
com o nível 3 bem feitinho e agora adota alguns processos estatísticos para
melhor controlar as suas práticas(os processos serão medidos). Há uma máxima
que diz que você não controla o que você não mede. Se você acha esquisito,
lembre-se do seu saldo bancário ou do seu nível de colesterol. Um você controla
sempre numericamente, via seu extrato, quase todo dia. O outro, você também
controla numericamente, via Hermes Pardini, de vez em quando.
No nível 5, a prática já está madura,
necessitando somente de sua manutenção e evolução em busca de uma melhoria
contínua, refinando-a e modernizando-a, focando na busca de inovações. Aqui os
processos serão otimizados.
Vamos a um exemplo real:
Suponha que você percebe a
necessidade de realizar um “profiling” de dados em arquivos críticos (Mestres e
Transacionais) da sua empresa. Por exemplo, no banco de dados de Clientes, onde
você percebe que tem alguns “furos” de dados. O “profiling” varre todos os
campos de todas as linhas da(s) tabela(s) e procura por possíveis
inconsistências nos valores, identificando campos brancos, outros com erros de
CEP, endereços incompletos, valores acima de patamares definidos por regras de
negócios estabelecidas, etc. Também estabelece avaliações de integridade de
referência entre as linhas daquela ou de outras tabelas.
No nível 1, você estaria somente
executando essa rotina, que foi definida pela sua equipe, por sugestão de
alguém, sem nenhum controle específico sobre ela(a menos dos resultados), que
você e o time avaliam para as devidas correções;
No nível 2, já há a definição de um
processo(conjunto de passos/procedimentos, entradas, saídas,etc), com certos
controles de quem faz o quê, quando, quem analisa quando e como, quem verifica
se foi feito, como foi feito, se deu certo, etc. Ou seja, nesse nível há uma
visão processual sobre aquela rotina, anteriormente isolada, porém agora com
envolvidos definidos e passos estabelecidos, seguidos e controlados. Aqui,
neste nível, um outro projeto que tenha ouvido falar das vantagens da sua
descoberta, fazendo “profiling” nos
arquivos importantes, também resolve fazer o mesmo No caso farão no BD de
Pedidos, por exemplo. Você diz mais ou menos o que fez e eles(outra equipe,
outro projeto) fazem da forma deles, seguindo as sugestões que você deu.
Fizeram um processo de “profiling” deles, porém, provavelmente com diferenças
do seu processo. Assim, a empresa está no nível 2, nesse aspecto de “profiling”
de dados, pois embora realize essas práticas,
fazem de forma diferente, dependendo de cada projeto ou área.
Já no nível 3, continuamos com aquela visão
processual do nível 2, mas com o processo de “profiling” agora padronizado por sugestão da Governança/Gestão
de dados. Há definições de Políticas, Processos, Procedimentos, Padrões, etc e
a empresa passa a ter um processo dito
padronizado, ou seja uma receita mais ou menos única para orientar todos que
forem fazer “profiling”. As áreas que agora
desejarem aplicar essa prática de dados num outro projeto/linha de
negócios, deverão buscar esse padrão e adaptá-lo às suas necessidades, porém
mantendo a linha “core” definida, além de documentar as
modificações/customizações necessárias. Assim, a empresa pulou de patamar, pois
agora tem um processo organizacional padronizado e aplicado em (quase todos)
projetos com ajustes conhecidos,
documentados e aprovados.
No nível 4, a empresa continua fazendo o nível 3 como descrito, mas há
melhorias no sentido de indicadores. Agora, haverá uma coleta de medições que
produzirão indicadores sobre, por exemplo,
o número de campos com problemas, erros reincidentes em certos valores,
tempo de execução das rotinas, tempo de retorno dos erros corrigidos, grau de
intensidade com que as áreas da
organização estão realizando o “profile” dos seus dados, etc. Pronto, agora
você melhorou os seus controles, colocando indicadores e tem uma visão numérica
de como as coisas estão andando.
E
finalmente no nível 5, a empresa
continuamente vai buscando melhorias. Por exemplo, há um novo pacote de Data
Quality, disponível no mercado, que faz profiling/limpeza de dados
semiestruturados, como email, ou de dados não estruturados para serem aplicados
em Big Data. Você, que já está com essa tecnologia na empresa, implementa, avalia, adota e compartilha sua
experiência em congressos, palestras, etc. Pronto, você está exercitando o
nível 5. Isso tudo que acabamos de exemplificar, são práticas funcionais,
dentro da área de processo(PA) “Profiling de Dados”, que pertence à categoria
“Qualidade de dados”. Você poderá fazer as mesmas melhorias em outras PA´s de
outras categorias, aumentando a sua capacidade de gerir os dados. Essa
práticas, no fundo, quando aplicadas nesses níveis estão mostrando a sua
capacidade de fazer melhorias e evoluir em dados.
Práticas de Infraestrutura:
Existe
porém um outro conjunto de práticas, mais associadas à engenharia de processos,
que garante que você não só fará as práticas funcionais, mas as fará na forma
de um processo sustentável. Ou
seja, aquele processo de Profiling de dados que você escreveu já no nível 2, (lembra-se?),
deverá ser descrito e gerenciado segundo certas regras. Não pode ser uma folha
onde você escreve um passo-a-passo simplório. Tem que ter um sabor mais formal.
Assim chegamos nas práticas chamadas de Infraestrutura(de processos). Ou
seja, todos os processos(leia-se PA´s-áreas de processos), deverão conter
certos elementos e serem gerenciados, conforme regras da engenharia de
processos. O que significa isso? Significa que todos os processos, que serão
escritos, independentemente de que categoria sejam, deverão ter alguns
elementos como Políticas(regras gerais normativas que devem ser observadas, que
dizem o que se espera do processo (why), com que frequência(when),
responsabilidades(Who), etc ), um plano de execução daquele processo (How)(dizendo
como e quando ele é executado), recursos adequados de pessoas para fazê-lo (How
much/many), todos devidamente treinados. Também haverá atribuição de
autoridades e responsabilidades pelo processo (Who). Como o processo tem
produtos, serão definidos pontos e procedimentos de controles sobre eles(por
exemplo os relatórios de saída da execução de profiling), quem são os diversos
envolvidos na sua execução, a monitoração
e o desempenho do processo pela alta gerência para ver como ele está
sendo produtivo e alcançando os seus objetivos. Além disso, haverá práticas de
infraestrutura também para verificar a aderência da execução do processo àquilo
que foi definido(Quality assurance, Configuração, etc). Em resumo, haverá um
conjunto de (outras) práticas, denominadas de infraestrutura/suporte que , aplicado ao processo garante a sua
adequada execução(como processo), independente de seus objetivos(pode ser de
profiling, de governança, de arquitetura,etc). Essas práticas gerais de suporte/sustentatibilidade,
quando analisadas em conjunto com as práticas funcionais específicas, conferem
o grau devido de maturidade àquele processo. Em resumo, a aplicação de modelos
mais elaborados de avaliação de maturidade, como este, pode levar a uma visão
inicial de como a empresa está conduzindo sua gestão e governança de dados, mas
também pode ser realizada após um projeto de melhoria de dados desenvolvido,
para se aferir o seu alcance. Independentemente de qual abordagem aplicar, a
ideia é realizar uma fotografia inicial de como a sua empresa está gerindo os
seus dados. A figura 13 mostra “fragmentos” de planilhas usadas no levantamento
e avaliação de situação de dados numa empresa, enfatizando as práticas adotadas
com os respectivos níveis de aplicação.
==
Figura-13-Planilha
de avaliação adaptada do Modelo DMM-Data Management Maturity Model-CMMI Institute
Referências:
Data Management Maturity Model(DMM)
Model.CMMI Institute August 2014-version 1.0.
Modelo Data Management Maturity(DMM). CMMI Institute-Agosto
de 2014-versão 1.0 (em português).
segunda-feira, 1 de maio de 2017
Governança e Gestão de dados na prática-Parte IX
Diagnóstico do estado atual de Governança
e Gerência de dados
Uma das
práticas possíveis quando se deseja implementar um Programa de Governança de
dados numa empresa é saber um pouco do seu estado atual com relação aos dados,
sua gestão, eventualmente aspectos de Governança e Gerência e uma visão de
propensão às mudanças culturais relacionadas a esses recursos. Por mais
distante dos conceitos atualizados de Governança e Gestão que uma empresa possa
estar, ela sempre tem algum mecanismo de controle sobre alguns dos seus dados,
mesmo que em estado, digamos, mais operacional e menos organizacional. Há
provavelmente alguns controles sobre Bancos de dados, ou arquivos críticos, há
certos mecanismos de gerência sobre
segurança de dados (aqui houve forte contribuição dos hackers), há
diagramas de bancos de dados normalmente em planos físicos para não se perder a
referência dos comandos SQL,etc. Assim, uma prática que pode ser adotada é a
realização de uma avaliação sobre esse estado atual, via entrevistas/discussões,
que poderão ser realizadas com duas visões separadas: Uma inicial e outra mais
detalhada. A inicial, normalmente com a alta e média gerência (inclusive CIO),
buscando-se a captura da propensão da empresa para os aspectos de dados, sua gestão e
controle e a outra, com uma aproximação
focada na gerência média, onde detalhes e especificidades serão levantadas em
contextos já priorizados.
a)Visão inicial : Lembre-se que a cultura sobre
dados nas empresas vem acompanhada de um viés de “proprietarismo”, espécie de
clima onde vemos áreas e funções se considerando possuidoras daqueles recursos,
carecendo de uma percepção maior sobre a conveniência e pertinência dos dados
serem um ativo de âmbito organizacional.
Nessa abordagem inicial se buscaria a
resposta ao “Why” ou “ o porquê” de um programa de dados. Nesse ponto seriam levantados os
principais desafios organizacionais, “dores” , problemas, aspectos de riscos de
reputação e de “compliance”, valoração, etc, tudo relacionado aos dados, permitindo
também a aferição do grau de motivação/convencimento que um programa desse
demanda, em função de posições de defesas e argumentos “culturais” colocados.
Essa visão seria um primeiro olhar sobre os
dados sensíveis e críticos da empresa(“What”), escopo e áreas
organizacionais/assuntos que merecem maior foco (“Where”) e aspectos de
prioridades(“When”). Em função desses parâmetros, os primeiros sinais de
“How”(Como-os dados são tratados), “Who”(Quem está envolvido com dados) e “How
much”(Custos potenciais das possíveis soluções e também dos problemas
relacionados) aparecerão, ampliando a possibilidade de uma solução mais embasada e direcionada de Governança de
Dados, aplicada na resolução de problemas de negócios.
b)Visão mais detalhe: Essa visão seria feita, com mais
foco, através de entrevistas nas áreas
selecionadas, em função dos “drivers”
obtido no item anterior. Aqui seriam entrevistadas gerências operacionais
e áreas de TI, envolvidas com os dados mais sensíveis daquele contexto,
obtendo-se mais detalhes sobre como os dados são percebidos e gerenciados num
patamar mais tático e operacional. Os conceitos de 5W2H, vistos anteriormente ,
agora ganham desdobramentos em pontos com detalhes que irão compor uma
estratégia ou plano de dados, a ser
apresentado como elemento “driver” de um programa importante.
c)Ferramentas: Nesses trabalhos poderão ser
usados referências de modelos de gestão de dados, que ajudam na estruturação de
questões para o levantamento. Há vários modelos disponíveis na literatura, com
destaque para DMM, DMBOK e DCAM, além de outros atrelados a produtos. O
primeiro, o DMBOK-da Data Management Association-DAMA, o segundo o DMM-Data
Management Maturity Model do CMMI Institute, e o outro o DCAM-Data Management Capability
Model, do EDM-Council. Os três podem servir de referência para um trabalho
deste tipo, com as devidas adaptações. No caso deste trabalho, consideraremos o
DMBOK do DAMA-Data Management Association e o DMM do CMMI Institute. Os principais conceitos
desses dois modelos são os princípios básicos de qualquer abordagem de dados, e
poderão ser usados na forma de perguntas/discussões sobre processos/áreas de
processos de dados, criando pontuações em funções dos níveis percebidos de maturidade
e capacidade desenvolvidas na gestão dos dados.
Visão DMBOK®-Data Management
Association
As eventuais
planilhas a serem preenchidas poderão,
por exemplo, ter um conteúdo mais orientado ao DMBOK®, com questões sobre os seus corpos de
conhecimento, assuntos e práticas funcionais, acrescidos de outros temas não
incluídos ainda no modelo atual da DAMA. Poderão estar no DMBOK® 2.0, previsto
para a metade de 2017. Poderíamos ter Planejamento de Gestão de Dados, Controle
de Gestão de dados, Arquitetura de Dados, Modelagem e projetos de dados,
Segurança de dados, DW/BI, Dados Mestres e de Referências, Gestão de conteúdo e
documentos, Metadados, Qualidade de dados, Integração de dados, Big data, IoT,
Dados não estruturados e uso de NOSQL, por exemplo. A figura 09 ilustra o
diagrama DMBOK® , adaptado pelo autor. Para
cada questão, poderemos ter diferentes notas atribuídas (de 1 a 5), por
exemplo, representando graus de capacidade/maturidade observados.
Figura-09-Modelo
DMBOK®-V01-Exemplo de avaliação de maturidade-adaptado pelo autor
As notas poderiam ser dadas da seguinte forma,
considerando cada prática analisada :
1-Realiza ou
possui ações de forma pontual ou por decisões isoladas;
2-Realiza ou
possui ações em nível de projetos, com uma visão neste contexto;
3-Realiza ou
possui ações em nível organizacional, por áreas de assunto/negócios, projetos
associados, etc, com uma visão mais organizacional, por assunto, linhas de
negócios,etc ;
4-Realiza
ações no nível 3 mas também aplica controles estatísticos sobre processos e
produtos gerados;
5-Realiza
ações no nível 4 e periodicamente, via PDCA, procura o refinamento dos
processos e produtos ;
6-Não sabe
responder.
A figura 10
mostra um segmento de planilhas usadas em avaliações de Governança e Gerência
de dados, baseadas em modelo DMBOK®, CMMI e MPS, que apresenta este estilo de
ponderação.
Figura-10-Planilha
de avaliação de Gestão e Governança de dados-baseada e adaptada dos modelos DMBOK®-MPS-CMMI
Pontos importantes:
São fatores
críticos, a observar:
1-Escolha
correta dos entrevistados e envolvidos, o que deverá ser antecedido por uma
análise juntamente com os potenciais patrocinadores da estratégia de dados da
empresa;
2-Apresentação
clara sobre o que significa cada prática investigada de tal forma a coletar a
informação mais precisa possível;
3-Apresentação
clara sobre os resultados alcançados, alinhado por sugestões de ações que
poderão mitigar ou cobrir as lacunas e vulnerabilidades detectadas.
Referências:
Data Management Maturity Model(DMM)
Model.CMMI Institute August 2014-version 1.0.
DAMA-DMBOK2-Framework-Patricia
Cupoli; Susan Earley; Debora Henderson-Set. 2012.
Modelo Data Management
Maturity(DMM). CMMI Institute-Agosto de 2014-versão 1.0.
MPS-Melhoria de Processo de
Software-Guia Geral de Software:2016.
MPS- Melhoria de Processo de
Software-Guia de Avaliação:2017-Parte 1.
MPS- Melhoria de Processo de
Software-Guia de Avaliação:2017-Parte 2.
The DAMA Guide to Data Management
Body of Knowledge(Dama-DMBOK® Guide)-First Edition 2009.
Assinar:
Postagens (Atom)