Uma abordagem prática às premissas do KCS – Knowledge Centered Support

Em artigo anterior apresentamos de forma introdutória o KCS, seus conceitos, premissas e objetivos. Recebemos vários feedbacks positivos com interesse sobre o tema, e vamos portanto evoluir um pouco mais no assunto. Veja o artigo aqui.

Neste tópico, vamos discutir de que forma as principais premissas do KCS aplicam-se na prática procurando traduzir os conceitos para o chamado ‘mundo real’.

Antes de mais nada, relembrando, as principais premissas do KCS são:

– Criação de conteúdo ‘just-in-time’ como um resultado colateral da solução de problemas

– Evolução de conteúdo com base em demanda e uso

– Desenvolvimento de base de conhecimento a partir do conhecimento coletivo (colaboração)

Vamos, então, ao mundo real.

Premissa 1: Criação de conteúdo just-in-time

Just-in-time é um termo oriundo de um sistema japonês de administração de produção que pode ser definido como “o que é necessário para produzir-se algo deve estar disponível na hora exata, ou quando for necessário”.

A interpretação de just-in-time para a criação de conteúdo de conhecimento pode ser compreendida como a capacidade de documentar-se conteúdo no momento em que o atendimento é realizado, ou quando um problema é solucionado. Na prática, deve ser possível criar-se conteúdo de base de conhecimento durante o atendimento a um incidente, chamado ou requisição, durante o atendimento a um cliente ou consumidor. Por que? Porque o contexto e a situação de momento são fundamentais. No tópico a seguir falamos mais disso.

Premissa 2: Evolução de conteúdo com base em demanda e uso

FUNDAMENTAL. Palavra colocada desta forma, em letras maiúsculas. A grande dificuldade, ou o grande desafio – como muitos preferem chamar – é a atualização dos conteúdos. Uma base de conhecimento só tem valor se seus conteúdos forem constantemente revisados e atualizados. Esta premissa do KCS tem a ver exatamente com este fator, a atualização de conteúdo. Esta atualização deve ser feita à medida que os atendimentos se realizem. Por exemplo, quando alguém realiza um atendimento, ele pesquisa conteúdos relacionados ao problema e os consulta. Essa pesquisa pode resultar em 3 possíveis resultados:

– A) A informação que ele precisava para resolver o problema foi encontrada e foi útil
– B) A informação necessária até foi encontrada, mas estava incompleta e desatualizada. Ajudou parcialmente
– C) Não havia informação nenhuma que ajudasse a resolver o problema

Na primeira situação, a ideal, é desejável que o atendente indique que a informação foi útil, pois essa informação tem muito valor em se tratando de gestão, avaliação de eficácia e recompensa, um outro ponto do KCS (que não será tratado neste tópico).
No caso da alternativa B, em que a informação existe, mas está incompleta, o atendente deveria ter uma forma de indicar sistematicamente que isso ocorreu, e ainda atualizar esta informação ou solicitar uma revisão no conteúdo de forma rápida e ágil.

Afinal, foi ele, naquele momento, que percebeu o que estava faltando ou o que estava incompleto. O verdadeiro valor do just-in-time, aqui, está exatamente nisso. No contexto e no momento da necessidade. É o momento que vai fazer com que se saiba exatamente o que precisa ser atualizado. Então, é natural que naquele momento o atendente possa atualizar o conteúdo ou indicar o que precisa ser atualizado (em muitos casos o especialista em documentação pode ser outra pessoa, que mais tarde irá realizar esta atualização, mas a indicação do que atualizar precisa do momento). Os processos tradicionais pecam por perderem este elo. O tradicional “temos que gerar documentação”, de forma aleatória ou não vinculada a esta percepção, perde boa parte deste momento de oportunidade.

Este cenário do parágrafo acima é igualmente válido para a terceira situação (C), da documentação inexistente. O momento e a percepção do atendente é que agregam valor ao conteúdo que será criado, seja pelo próprio atendente, na hora, ou por uma solicitação feita por ele indicando-se exatamente o que precisa ser documentado.

Premissa 3: Desenvolvimento de conhecimento por colaboração

Os cenários 2 e 3 exemplificados representam, por si só, um exemplo de colaboração. Os atendentes, ao detectarem oportunidades de melhoria em documentação, realizam tais documentações ou indicam que as mesmas precisam ser feitas. Alguém com atribuição específica (revisor técnico, por exemplo) vai monitorar estas solicitações e realizar as atualizações. Este processo passa a ser cíclico.

Um gestor de conhecimento, por sua vez, pode monitorar estatísticas de eficácia de documentação juntamente com as solicitações de revisão, tudo isso por tipo de atendimento, e gerar ações proativas de documentação (a partir da análise dos gaps de documentação). O importante é que a sistemática usada seja ágil, permita que sejam solicitadas as revisões, que conteúdo seja criado e revisado e ainda que tudo isso seja monitorado.