Como gerir o conhecimento de emails - IV

Continuamos nossa série de gestão de conhecimento de emails, por serem a matéria-prima mais usual de troca de informações vigente, apesar de não ser a mais apropriada.

Falamos de idéias, tríades de idéias, etc. Isto mostra como é necessária a existência de um profissional na empresa com facilidade linguística e de um profissional especializado em bancos de dados linguísticos.

Emails de pedidos

Muitas corporações recebem seus pedidos via email. Isto é inapropriado, pois já existem grandes sistemas ERP (Enterprise Resource Planning - Planejamento de Recursos para Empresas) ou SIGE que fazem esta gestão. São sistemas caríssimos que podem ser "emulados" por pequenas aplicações de formulários que descarregam em bancos de dados as informações postadas.

Mas sendo assim, vamos gerir os pedidos. Os emails deverão ter, no mínimo, as seguintes informações:

Cliente:

Devido ao fato do email ser o meio inapropriado, e as contas poderem ser invadidas, não se deve utilizar nem a Razão Social, nem o nome fantasia de domínio público, nem o CNPJ, mas um codinome convencionado pela empresa com o cliente (um apelido).

Tipo de item:

Como já existem muitas divisões já consolidadas nos catálogos, e apesar dos códigos de itens, esta informação é necessária para tipificação e categorização, molas mestras da Gestão do Conhecimento. Assim o cliente também ganha na hora de produzir estatísticas e analisar tendências.

Descrição do item:

Serve para dirimir dúvidas com o código (a seguir), pois errar é humano. Campos de descrição tem grande valor para a Gestão de Conhecimento. O ser humano pode digitar um código pequeno errado, mas errar na descrição do que quer é realmente incompetência.

Número de parte ou código:

Este código está nos catálogos de produtos e evita erros de interpretação. No entanto, tem valor somente contábil. Para Gestão de Conhecimento ele é um código frio, pois não carrega em si o porquê de ter sido pedido (não porque está esgotado ou quase acabado, mas sua razão na cadeia de produção e consumo).

Quantidade pedida:

É a quantidade "fria" pedida. É um número e só tem valor contábil.

Data limite do pedido:

É a data em que o cliente deseja que a quantidade do item esteja em suas mãos. É também "fria" pois só funciona como um referencial para a transação.

Motivo do pedido:

Apesar de parecer uma intromissão do fornecedor na vida do cliente e de suas estratégias, este campo é como um selo de importância e prioridade. Valores possíveis:

Reposição
Preparação para evento chave (Dia das mães, dia dos pais, natal, dia das crianças)
Sazonalidade: coleção de inverno, coleção de verão, férias

Para o cliente é um importante campo de Gestão e para o fornecedor é um selo de compromisso, pois a medida da gravidade do não cumprimento do pedido se dará através deste campo.

Local da entrega:

É um campo importante para a logística, e não significa muito para a Gestão do Conhecimento.

Campo de assunto do email


As pessoas e as empresas não tem normas para emails, e isto acaba lhes trazendo grande dor de cabeça. Coisas simples podem ajudar na classificação e no uso das regras de email disponíveis em quase todos os softwares que os manipulam.

No início do campo de assunto deve-se convencionar com os clientes a colocação de palavras chave entre colchetes. Alguns exemplos:

[Pedido][nnnn]
Utilizado para emails com os pedidos conforme explicado. [nnnn] é o número do pedido.
[Aviso]
Utilizado para uma comunicação qualquer de mudanças de rotina
[Reiteração][nnnn][1]
Utilizado para reiteração de pedido. O segundo conteúdo entre colchetes representa o número da reiteração.
[Entrega][nnnn]
Utilizado para avisar que a entrega vai ser feita
[Pagamento][nnnn]
Usado para frisar que a data de pagamento está chegando
[Recebido][nnnn]
Usado para confirmar que o pagamento foi recebido.


Conclusões

Constatamos que este tipo de email deve ser substituído por um sistema, pois tem tipos de informações repetidas e provavelmente vai ser um num universo de milhares. O mais apropriado seria um banco de dados. Mas como a cabeça da maioria dos negociantes prefere soluções imediatistas, procuramos tornar este tipo de email o mais apropriado para ser matéria-prima de gestão de conhecimento.

Idéias primitivas e idéias derivadas

Já fizemos digressões sobre a fraca classificação que os conteúdos do conhecimento recebem, devido ao desconhecimento das primitivas tanto de um assunto afeto a um ramo da atividade empresarial quanto da nossa própria língua citadina.

Dentro de uma assunto, de um ramo do conhecimento, existem idéias primitivas e idéias derivadas. Vamos logo a um exemplo, que poderia estar sendo estudado durante a implantação (séria) da Gestão de Conhecimento em uma empresa de telefonia. Sua idéia mestra já é derivada, como mostra o diagrama a seguir:

Aqui existem duas primitivas envolvidas: Distância (representada pelo prefixo grego "Tele") e falar (representada pelo sufixo "fonia").

Este é um dos melhores exemplos para mostrar como é necessário o conhecimento profundo do negócio sobre o qual será feita a Gestão de Conhecimento. É preciso identificar as idéias primitivas envolvidas. Nossa língua portuguesa jé é tão erudita e misturada, tendo recebido tantas influências de outras línguas, que a identificação das raízes exige uma parada intelectual.

Na língua inglesa, existem diversas "partículas" que possibilitam a construção de idéias derivadas. São elas:

get, set, in, out, over, under, up, down

Agregando estas "partículas" aos verbos, produz-se novo significado para estes verbos. Na língua inglesa isto fica mais fácil pelo fato de ser uma língua de origem bárbara, e me desculpem, primitiva.