Como transformar o conhecimento tácito sobre o GUEPARDO Tax em um manual da empresa?

Discordo do esqueleto como ponto de partida. Então, o risco é o manual descrever o produto padrão e esquecer o que é da casa. Nas notas de projeto que li, as extensões próprias em torno do fiscal são a parte que mais quebra na atualização, e quase ninguém sabe dizer qual existe, quem escreveu e o que assume do produto. Isso é julgamento de consultoria, não medição.

Se o manual só tiver um capítulo, que seja o inventário dessas extensões, com dono e objetivo.

No ambiente de qualidade, pois é, a gente aprendeu uma coisa parecida: o manual precisa dizer quem valida. Quem valida o resultado é o cliente, e o teste técnico da consultoria não prova que a apuração do mês está certa. Então escreva no manual, para cada rotina, quem confere o resultado e com que evidência.

Sem isso, o manual ensina a apertar os botões e deixa de fora o que importa no fechamento.

Escreva por regra, não por tela: cada regra com um dono, uma data e o vínculo com o que ela decide. Vale registrar, viu, o teste de aceite do manual: peça a alguém que nunca fez o procedimento para executar um fechamento seguindo só o texto, com o dono apenas observando. Cada vez que ele perguntar algo, o manual tem um buraco.

Isso responde sua segunda pergunta com um critério que dá para medir: quantas perguntas apareceram.

Agora, antes de mais nada, outro caminho: em vez de escrever do zero, use a estrutura que a própria documentação do produto adota para cada módulo, como esqueleto do manual interno. Aqui o contador e o key user sentam juntos e preenchem cada parte com o que é específico da empresa.

Fica mais rápido que folha em branco e padroniza entre obrigações. O conteúdo de cada campo continua sendo o conhecimento do seu usuário-chave.