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).
Nenhum comentário:
Postar um comentário