Total de visualizações de página

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. 




               Figura 11-Visão geral do modelo DMM-Data Management Maturity Model- DMM



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.