No texto anterior,
analisamos as partes relativas a Why e What do Canvas-MGD. Neste, detalharemos o
Where e o Who além dos H´s , fechando o entendimento
do Canvas MGD-Melhoria de Gestão de Dados.
e)O
“Where” nos aponta para o contexto
daqueles problemas e das soluções previstas. Em outras palavras diz respeito às
áreas ou assuntos que estarão envolvidos na solução daqueles problemas de dados,
discutidos via Canvas-MGD. Os dados envolvidos já foram identificados de acordo
com suas classificações: Mestres, Referenciais ou Transacionais e colocados no
slot específico. Sugestões de áreas apareceram. Agora, aprofunda-se nos potenciais “owners” dos dados , ou seja as
áreas mais afetadas ou para cujo “business” aqueles dados são os mais críticos.
Ou quem sabe, as áreas onde os dados são definidos e criados. Também os
potenciais gestores e/ou responsáveis, normalmente surgido nas figuras dos especialistas de negócios que trabalham com
aqueles dados, começam a ser identificados. Também aqui nasce a visão de
DLCM-Ciclo de vida dos dados, dando a ideia sobre o fluxo que os dados seguem ou
seja por onde eles circulam e a quais processamentos são submetidos. Isso
facilita a identificação da linhagem dos dados, ou a sua trilha de “vida”,
desde a origem e criação até o
armazenamento final, elencando pontos de potenciais inserções de problemas.
Esses pontos serão elementos fundamentais de análise e detalhamento quando do aparecimento de problemas de dados. O elemento “Where” tem tangência com o “Who”,
porém fica mais centrado em áreas ou unidades de negócios, enquanto o “Who”
fica mais para papeis e pessoas.
Exemplo prático:
Nesse ponto, na nossa hipotética operadora, já estamos com a visão
dos problemas desenvolvida em certo estágio e conhecemos os principais dados
merecedores da atenção. Nesse espaço, busca-se a formalização das áreas principais (unidades de negócios) que
se envolvem com aqueles dados , no contexto do problema. Lembre-se que os dados
são capilares e perpassam várias unidades organizacionais da empresa. Algumas
gerências já foram mencionadas e a seguir busca-se o cruzamento de seus
processos com os dados envolvidos.
Uma matriz de Processos x Dados pode
ser útil neste momento, mostrando o fluxo dos dados por entre os processos da
área. Isso dará uma visão sobre o ciclo de vida dos dados(onde são definidos, nascem,
são modificados, são consumidos e são aposentados).
Uma matriz RACI é um outro elemento
importante que ajuda nesta abordagem, mostrando os R- responsáveis pelo processo,
os A- apontando os que tem “accountability ou responsabilidade final”, os C que são consultados, normalmente associado com os especialistas no
assunto e os que são “informados” I, ou sejam os que participam somente recebendo informações.
O “Where” facilita a identificação da organização/área
que será (ou já é) forte candidata ao papel de
“Owner ” dos dados. A palavra “owner”, evitada por muitos especialistas,
pode sugerir um retorno ao “proprietarismo” indesejável. Na realidade ele
sugere o sentido de “accountability”, ou responsabilidade final e formal sobre
aqueles elementos de dados. Por esse motivo, a palavra “Governor” pode ser usada. Caso haja duas ou mais áreas, deve-se
atribuir à área mais envolvida/sensível
, o papel de “Owner/Governor” ou “Accountable for” dos dados.
No exemplo hipotético em
desenvolvimento, vemos que há certa
afinidade de áreas com os dados Mestres e Transacionais. Por exemplo a
GOP-Gerência de operações, com os dados transacionais de consultas e
atendimentos, a GCO-Gerência de Convênio com os Convênios e seus
prestadores(Dados mestres de Prestadores de serviços), a GPM-Gerência de
Procedimentos médicos e protocolos clínicos, com controle sobre dados de
referência de códigos de atendimento, de doenças e protocolos,etc . Assim vamos
explorando o universo das inter-relações dos dados com o negócio da organização
e convertendo os dados em elementos fundamentais e conhecidos do negócio da
organização.
Isso é ponto fundamental.
f)Who:
Trabalhando o “Where”, certamente encontramos o “Who”, ou quais serão as pessoas (“Who”) envolvidas
nas estruturas (“Where”), que conhecem os dados, fazem a sua gestão(mesmo que
informal). Aqui já começamos a pensar nos potenciais papéis que comporão uma
estrutura de GD. Começamos pelo Conselho de GD, com representantes do alto
“board” para as decisões mais organizacionais, um Comitê de Gestores para no
nível tático, conduzindo essas ações de dados nas diversas áreas envolvidas, e
os Gestores de dados em si, de diferentes tipos(de negócios, de projetos, de
operação, por assunto, etc). Assim, você já vai montando as visões de quem
participará no domínio da solução dos (problemas) de dados, identificando os
potenciais SME(Subject matter experts), como denominados nas práticas de GD das
empresas americanas. Uma abordagem sugerida por Bob Seiner (KIK Consulting),
via sua GD não invasiva, é justamente observar e aproveitar os recursos já existentes,
provendo a complementação para a sua formação no tratamento dos dados. Há uma
máxima que diz que os gestores de dados já existem na sua organização. Você é
que ainda não os identificou e formalizou!!
Exemplo prático:
Nesse ponto já estamos com a visão
das áreas que tem envolvimento forte com os dados no contexto dos problemas e
já criamos possíveis participações na solução que se deseja.
Os chamados SME já podem ser
identificados nas gerências discutidas anteriormente. Esses poderão ser(se já
não são, mesmo que informalmente) os potenciais gestores de dados, responsáveis
pelo recurso naquele contexto gerencial.
Mecanismos de formalização dessas
posições deverão ser pensados e um conjunto de treinamento em conceitos de GD
serão obviamente planejados e
desenvolvidos.
Na formalização das posições de GD
poderá haver “conflito’, quando os dados são fundamentais e tratados(até com
atributos diferentes) por UO(unidades organizacionais) diferentes. Nesse
momento, as decisões sobre uma gestão de dados compartilhada, alinhavada por um
Grupo/Comitê de Gestores , no plano tático pode ser pensada, e/ou pela
definição de um Gestor de dados por Assunto, que englobaria a autoridade sobre
aquele dado, válida para todas as UO que o utilizam.
g)When:
Identificadas as principais ações, mesmo que em visão inicial, traçaremos o
conjunto das realizações na linha do tempo, estabelecendo prioridade em função
da criticidade dos dados e dos problemas circundantes. Surge assim, um
cronograma das primeiras atividades de GD para a resolução dos problemas
elencados.
Exemplo prático:
Nesse ponto já estamos com a visão
definida sobre prioridades de ação , que se transformarão em itens e
prioridades de um plano de ação de Dados. Por exemplo, em função das multas
resultantes das atuações e dos aspectos de reputação, a prioridade será sobre
“compliance” dos dados inconsistentes enviados à ANS e a resolução dos
problemas de marcação de consultas, onde os dados apoiarão nas soluções.
Os aspectos sobre possíveis ações de
monetização dos dados, serão analisados em segunda prioridade.
h)”How
much”: Nesse ponto, já poderemos ter uma ideia sobre os custos aproximados
envolvidos nas ações de implementação, ou pelo menos subsídios para procurar
por mais detalhes de investimentos necessários.
Exemplo prático:
Aqui podemos desenvolver, numa visão
inicial, aspectos de custos e prazos, em função das definições dos requisitos a
serem desenvolvidos. Isso, claro, será detalhado em planos subsequentes. O
custo parcial dos “gestores de dados”, que dedicarão parte do seu tempo às funções de GD, poderão ser
inicialmente discutidas.
i)Finalmente
chegamos no “How”: Esse ponto será detalhado e aprofundado nos diferentes
conceitos de Governança e Gestão de dados (Os P´s da GD), analisados no outro
Canvas. Nele poderemos mergulhar em cada
item fundamental da estratégia de GD, chegando a uma visão próxima de sua proposta
para implementação.
Exemplo prático:
Aqui passamos a detalhar aspectos
relacionados aos P´s da GD, alguns dos quais já identificados, a serem
detalhados no outro Canvas, em função de todos os elementos coletados e “consensados”
nesta primeira etapa.
Nenhum comentário:
Postar um comentário