TMACUL

GESTÃO DE CONHECIMENTO: Ajustando o processo na ferramenta (categorias)  09/11/2015

Blog Post created by TMACUL Champion on Jan 1, 2016
GESTÃO DE CONHECIMENTO: Ajustando o processo na ferramenta (categorias)
Depois que alguns conceitos básicos já foram explicados nos posts anteriores, nada melhor do que testar na prática a execução do processo.
E para isso, precisamos configurar minimamente nosso processo dentro da ferramenta da seguinte forma:

CATEGORIAS
Através das categorias de conhecimento é possível atribuir um proprietário, privilégios de acesso, processo de aprovação, modelo de documento ou associação de categorias de tickets aos documentos.

É bom destacar que não é aconselhável comparar categorias de conhecimento com pastas de um servidor de arquivos. É parecido, porém diferente.

Sempre tenha em mente que esta estrutura de categorias não agrega em nada na experiência dos usuários que procuram conhecimento na base. Nenhum usuário ficará navegando nas categorias criadas...

O usuário quer apenas pesquisar palavras chave, clicar em pesquisar e o documento precisa ser encontrado onde quer que ele esteja na estrutura de categorias.

Em contrapartida, uma má definição destas categorias comprometerá seriamente a experiência do usuário. Vou explicar o porquê:

Uma das configurações mais importantes que precisa ser bem definida são os privilégios de acesso da categoria. Somente desta forma será possível restringir a visibilidade de alguns documentos para que assim, os resultados da pesquisa do usuário sejam mais precisos e relevantes para suas necessidades.

Por conta disso, é uma prática comum criar uma estrutura raiz de categorias logo abaixo da categoria "SUPERIOR" vinculada à função do usuário. Ex.: Atendimento=>Analista de nível 1, Operacional=>Analista de nível 2, Cliente=>Cliente, etc.
E mesmo com esta "estrutura base" de categorias, é possível que seja necessário criar outras subcategorias para refinar ainda mais a estrutura e facilitar a manutenção.

Desta forma, também é prática comum criar categorias de conhecimento específicas para armazenar documentos específicos.
Mas essa prática só se justifica quando algumas das 05 perguntas abaixo recebe um "SIM" como resposta:

Os documentos dessa nova categoria...
1) ... terão um proprietário diferente da categoria pai?
2) ... terão privilégios de acesso diferentes da categoria pai?
3) ... utilizarão um processo de aprovação diferente?
4) ... utilizarão um modelo de documento diferente?
5) ... estarão associados a uma categoria de incidente/problema/solicitação/ocorrência diferente?

Se a resposta correta for confirmada, daí sim a nova categoria deverá ser criada. E esta atividade geralmente deve ser atribuída à função "Gerenciador de conhecimento", destinada a estruturação do processo dentro da ferramenta.
Portanto atribuir esta atividade de estruturação aos "Analistas de conhecimento" não é uma boa prática. Esta função trabalha no dia a dia e o ideal é condicionar suas atividades apenas utilizando as estruturas já criadas pelo processo.
Se isso não for feito, há sério risco da estrutura definida ficar " bagunçada" com o tempo.

Outra configuração importante definida nas categorias é a associação entre as categorias de conhecimento com as áreas de tickets.
Se isso for feito corretamente, não haverá necessidade de formar um grupo de analistas de conhecimento para fazer o redirecionamento dos documentos para os respectivos proprietários.
Isso ocorrerá de forma automática quando o conhecimento gerado for oriundo da Atividade de solução de um ticket.
Mas lembre-se que uma categoria de ticket só pode estar associada a uma única categoria de conhecimento. É interessante conversar com o gestor do respectivo processo para ajustar estas associações de categoria. Essa funcionalidade ajuda muito e elimina um eventual processo de triagem na geração de conhecimento.

Amanhã falarei sobre a definição dos processos de aprovação que podem estar associados as categorias.
Até lá.

 

Publicado Originalmente: 03 de dezembro de 2015 às 01:15

Em: CA SDM Brasil - facebook

Por: daniel-bighelini

Outcomes