Teoria dos quebra-cabeças: Uma Abordagem do uso Automação

Teoria dos quebra-cabeças: Uma Abordagem do uso Automação de Documentos Aplicada aos Documentos Textuais de Engenharia.

Resumo

Este artigo traz uma abordagem do uso de softwares e técnicas já utilizadas no ramo de contratos em aplicações de engenharia. Trata-se do que é conhecido como “document assembly”, onde documentos com textos repetitivos são padronizados de modo que o usuário obtenha mais produtividade e qualidade nos resultados. Embora o artigo não apresente resultados práticos, são apresentados exemplos que poderiam ser usados como base para estudos específicos ou projetos pilotos.

Palavras-chave: Montagem de Documentos, Automação de Documentos.

Abstract

This article presents an approach about the use of softwares and reknown technics concerning contracts and legal documents in engineering applications. It is about what is known as “document assembly”, a technique in which documents with repetitive text are patterned in a such way the users can develop more productivity and quality in their works. Despite this article do not present practical results, there are some examples which can be used for specific studies or even in pilot projects.

Keywords: document assembly, document automation.

Introdução

Em diversas aplicações, nas mais diversas áreas do trabalho, muitas vezes nos deparamos com a necessidade de criar documentos específicos para cada aplicação, que porém, contém os mesmos textos padrões, onde o que se muda é por exemplo, no caso de um contrato de aluguel de um imóvel, as informações do imóvel, do inquilino, do proprietário, fiadores, datas, valores monetários e percentuais. Para este tipo de aplicação existem documentos denominados formulários, com espaços em branco para preenchimento dos campos específicos e de pleno conhecimento de todos. Suponhamos, entretanto, que determinadas cláusulas contratuais não sejam aplicáveis a todos os contratos e que quiséssemos flexibilizar um determinado contrato. O formulário já não seria mais tão eficiente, pois geraria exceções e provavelmente embaraços jurídicos para alguma das partes.  Solução seria ter em mãos, um documento editável em que se poderiam alterar manualmente as cláusulas. Neste caso, existe risco de se excluir ou inserir cláusulas permanentemente, o que levaria aos mesmos problemas do uso de formulários.  Além disso o uso do “copiar e colar” seria incentivado, e dados inconsistentes poderiam ser facilmente transitados de um documento para outro. Para se evitar estes inconvenientes, os profissionais da área de direito e contratos, utilizam uma solução conhecida como “document assembly”, onde softwares específicos são alimentados com as informações e padrões e o usuário apenas informa os campos específicos para cada documento. Exemplos destes softwares são: Hotdocs, Pathagoras e Smoothdocs.

O leitor pode então se perguntar o que isto tem a ver com documentos de um projeto de engenharia? – a resposta se dá pelo o que chamo de teoria dos quebra cabeças. Para iniciar a minha teoria usarei um exemplo bem simples: Álgebra. Quando estivemos no ensino fundamental, os problemas de álgebra que nos eram apresentados consistiam sempre no mesmo: uma condição ou relação conhecida, um número de variáveis conhecidas e uma variável incógnita. Com o desenvolvimento das habilidades matemáticas, os problemas se tornavam um pouco mais complexos, tomando elementos reais em vez de puramente numéricos, alternando entre bananas e laranjas ou mesmo uma salada de frutas – mas a idéia continuava a mesma. No segundo grau ou mesmo no ensino superior surge a necessidade da utilização de artifícios matemáticos onde se “disfarça” x como x²/x ou (x²-1) como (x+1)*(x-1). Após alguns anos trabalhando com engenharia, percebo que a idéia continua a mesma, mas diferentemente da escola, onde as relações e variáveis eram de domínio público, cada profissional cria seus conceitos e seu método de realizar suas tarefas e não há uma uniformidade de resultados. Eu não me restrinjo somente a relações “calculáveis” como por exemplo a carga térmica de um escritório, a potencia do motor de uma bomba ou qualquer outra grandeza física, mas também à execução de documentos de engenharia.

Se imaginarmos que um automóvel é um equipamento bastante complexo, mas que é montado por profissionais de um grau médio de conhecimento, com rapidez, segurança e qualidade, fica evidente os benefícios da padronização de métodos produtivos. Esta teoria vem questionar porque não utilizar estes mesmo conceitos para a produção de produtos intelectuais.

De uma maneira bem direta, a ideia é tratar documentos textuais como uma equação ou algoritmos, de maneira que sejam definidos padrões de entradas e saídas, variáveis e incógnitas, que visem à produção rápida, uniforme e confiável de documentos. Não me refiro a criar modelos de referência, mas sim criar um sistema onde o executor do documento atue conscientemente sobre os resultados. Não raras vezes nos deparamos com profissionais que não sabem explicar certas exigências inconsistentes em seus documentos, a não ser pelo fato de que o documento foi copiado de um modelo de referência. Copiar e colar gera rapidez, mas não confiabilidade e uniformidade de resultados. Esta teoria visa gerar atividades instrutivas e confiáveis para a elaboração de documentos ou para alcançar resultados intelectuais, de uma maneira simples, como montar um quebra-cabeça.

Desenvolvimento

Métodos como árvore de falhas[1] ou diagrama de Ishikawa[2] (espinha de peixe) são comumente utilizadas para descobrir causas raízes de problemas ou falhas ou mesmo evitá-los preventivamente.  Uma vez que se podem utilizar estes métodos para entender eventos passados ou prevenir eventos indesejados, da mesma forma pode-se utilizá-los de maneira análoga para determinar eventos desejados. Um exemplo bem simples é o caso de uma redação qualquer: Independentemente do estilo, todo texto deveria ter uma introdução, um desenvolvimento e uma conclusão. Dificilmente uma redação será bem entendida se não passar pelas etapas apresentadas, na ordem apresentada. Fica evidente então uma equação que representa a relação necessária para se desenvolver uma redação:

Redação = Introdução + Desenvolvimento + Conclusão

A grande questão é desenvolver o conteúdo que será apresentado em cada uma destas partes. No caso dos documentos de engenharia, o grande desafio está em transformar textos complexos em textos simples, textos individuais em textos padronizados.

Fugindo do óbvio, que é o que foi apresentado até o momento, o conteúdo dos documentos deve ser desdobrado em três níveis de maneira em que os termos componentes do texto possam ser padronizados. O primeiro nível é o nível de títulos, que determina quais assuntos devem necessariamente ser tratados no documento. O segundo nível se refere a quais itens devem ser tratados dentro de cada assunto. Além destes, haveria um nível de apoio com as funções burocráticas do documento. Uma representação gráfica pode ser verificada na figura a seguir.

Figura 1. Estrutura Analítica de um Documento Textual.

A teoria dos quebra-cabeças é tão simples que se torna uma tarefa árdua tratar deste assunto sem ser enfadonho. Desta forma, o assunto será tratado através de exemplos que, espero, ativarão o interesse do leitor. Os exemplos serão sobre planos de manutenção e especificações técnicas para aquisição de equipamentos.

O Plano de Manutenção

Um plano de manutenção para um equipamento qualquer é um documento que define uma lista de atividades de manutenção (seja de ação para alteração da condição ou de monitoramento) a serem executadas em um equipamento como todo ou em um sub-grupo do mesmo, com uma determinada freqüência. Este documento é apresentado ao mantenedor em forma de “check list” com dois propósitos: servir de guia para o executor da atividade, que sem o tal poderia se esquecer de executar alguma atividade importante e para documentar/registrar que as atividades foram realizadas. Em termos desta teoria:

Plano de Manutenção[3] = Lista de Atividades + Freqüência de execução das atividades.

Sendo um pouco mais específico, vamos desenvolver um plano de manutenção para uma correia transportadora.  Embora para um leigo todas as correias transportadoras possam parecer iguais, quando apreciadas com mais atenção pode-se ver que há varias possibilidades construtivas em relação ao acionamento (redutor acoplado diretamente no tambor, transmissão por corrente, por correia, por sistema de engrenamento), tipo de tensionamento (parafuso esticador, contra-peso), absorção de impacto (mesa de impacto, roletes de impacto) dentre outros, de forma que se fosse criado um texto geral para atender à todas as combinações possíveis de construção (o que freqüentemente ocorre), 1) ou o texto não teria todo o conteúdo necessário, 2) ou teria conteúdos que necessariamente teriam de ser ignorados – o que pela minha experiência, certamente levaria à não execução de itens necessários.

Tendo explicitado estas informações, o ponto inicial para a definição do documento é realizar um desdobramento do equipamento em sub-grupos que possam abranger as possibilidades construtivas do equipamento. Neste exemplo, pode-se listar:

Figura 2. Estrutura Analítica de uma Correia Transportadora comum.

Vale ressaltar que o desdobramento da figura 2 se refere apenas aos componentes que comumente variam de acordo com o projeto da correia. Estrutura metálica, roletes de carga e retorno, tambores de acionamento e retorno e alguns outros itens sempre estarão presentes, pelo menos nos tipos de projetos que são do meu conhecimento e que assim foram considerados neste estudo.

Prosseguindo então com o procedimento proposto por este estudo:

Plano de Manutenção = Lista de Atividades + Frequência de execução das atividades.

Figura 3. Estrutura do Plano de Manutenção para correias transportadoras.

E finalmente, um documento único automatizado que abrange 270 diferentes[4] variações de correias transportadoras, sem ser exageradamente extensivo.

Arquivo 1. Documento Modelo para Plano de Manutenção de Correias Trasnportadoras: Pode ser visualizado clicando no link a seguir: PLANO DE MANUTENÇÃO .

Baixe o arquivo para usar as funcionalidades no MS EXCEL.

O arquivo apresentado mostra uma idéia do que poderia ser desenvolvido em um sistema de banco de dados mais complexo. Se quiséssemos, por exemplo, desenvolver o plano de manutenção de um elevador de correia, que tem características do sistema de transmissão muito similares às de uma correia transportadora, poderíamos usar o mesmo banco de dados de atividades para o sistema de transmissão. Mais além, se o equipamento em questão fosse um ventilador, que geralmente possui como opções de transmissão apenas polias e correias ou acoplamento mecânico, ainda poderíamos usar o mesmo banco de dados com condicionantes, permitindo apenas os tipos possíveis de serem escolhidos, limpando a poluição visual para o usuário. Em outras palavras, é possível criar um único banco de dados para uma grande diversidade de equipamentos e aplicações.

É importante destacar que as idéias expostas aqui têm o objetivo de mostrar um método de sistematização do desenvolvimento de conteúdos técnicos e não o conteúdo em si. Em outras palavras, o conteúdo apresentado pode estar equivocado no âmbito técnico, que deve ser desenvolvido por especialistas no assunto. Uma vez criado o banco de dados, as diversas possibilidades encontradas em campo podem ser trabalhadas mais rapidamente e o seu conteúdo ser exportado para um Sistema de Gerenciamento de Manutenção Isolado ou mesmo para um ERP.

Por uma questão de simplicidade (e habilidade), o exemplo foi desenvolvido em MS Excel. Um programador mais habilidoso poderia criar um banco de dados central para uma empresa com várias unidades, por exemplo, e criar uma interface mais amigável, manter o histórico de revisões, etc. Uma das vantagens deste cenário seria em relação às lições aprendidas e melhoramentos. Uma vez desenvolvida uma melhoria, esta poderia ser atualizada no banco de dados e automaticamente estaria disponível para os usuários que venham a criar ou revisar documentos após tal atualização.

Extrapolando as barreiras da Manutenção, poder-se-ia determinar características chave dos equipamentos (critérios) durante a fase de projeto como, por exemplo, para os sistemas de acionamento ou de transmissão. Quando trabalhei com manutenção, não foram poucas as vezes em que se tinha um equipamento ou componente danificado, não havia reserva, a equipe encontrava um elemento similar de um  outro equipamento que poderia ser utilizado, mas devido ao sistema de acionamento/transmissão/montagem ser diferente, eram necessários diversas adaptações (usinagem, trabalhos de caldeiraria, soldagens, etc.) para que fosse possível utilizar tal elemento. Em novos projetos poder-se-ia por exemplo, estabelecer que todos as correias transportadoras até uma determinada potência tivessem que ter um determinado tipo de acionamento/transmissão/montagem. Em tais circunstâncias, as adaptações do exemplo dado seriam menores ou mesmo nulas.

A Especificação Técnica

Diretamente ao assunto, para exemplificar, trataremos a especificação técnica de um equipamento de processo ou sistema industrial como o seguinte:

Especificação Técnica = Escopo de Fornecimento Central + Escopo de Fornecimento Disciplinas Cooperadas (Elétrica, Instrumentação, Mecânica, Utilidades, Civil, etc.) + Requisitos Gerais + Requisitos Específicos de Disciplinas Cooperadas + Limites de Bateria.

Figura 4. Estrutura de uma Especificação Técnica.

E então, temos:

Arquivo 2. Documento Padrão para Especificação Técnica: Pode ser visualizado clicando no link a seguir:  Especificação Técnica. Baixe o arquivo para usar as funcionalidades no MS EXCEL.

Um item importante do uso desta metodologia neste caso é que seria possível criar um elo entre a especificação técnica e as folhas de dados, documentos de análise técnica de propostas e requisição de materiais, para certificar que todos os documentos estejam coerentes conforme o escopo da especificação técnica.

Novamente, evidencio que o conteúdo do documento em si não é o foco deste trabalho e tal conteúdo deve ser discutido em cada organização.

Conclusão

 O apresentado neste trabalho mostrou as possibilidades de se utilizar um sistema de padronização da informação em forma de banco de dados em vez de usar modelos padrão para serem alterados manualmente.

De maneira mais estruturada seguem as possibilidades de vantagens do uso deste método:

1. Confiabilidade: O método de produção é ao mesmo tempo uma lista de verificação. A falta de algum conteúdo seria um evento deliberadamente intencional em vez de acidental. Em outras palavras, se algum conteúdo não foi apresentado, é porque o executor marcou tal item como não aplicável e não porque copiou de um modelo em que o item não foi mencionado.
2. Uniformidade: Em um sistema integrado, o resultado seria o bastante similar para qualquer profissional, em qualquer projeto, em qualquer unidade da empresa.
3. Produtividade: Trabalhos de formatação (fontes, parágrafos, cores, estilos, símbolos, logos e imagens, paginação e etc.) seriam realizados apenas durante a criação do banco de dados e não exigiriam nova verificação durante a emissão do documento.
4. Rastreabilidade e referenciação cruzada: A citação de números de documentos dentro de outros documentos poderia ser indexada, filtrada e pesquisada no banco de dados para tomar as ações de comunicação cabíveis no caso de revisão ou cancelamento de documentos.
5. Disseminação do conhecimento: O fato do conteúdo ser apresentado em forma de opções de múltipla escolha apresentaria as possibilidades discutidas por profissionais veteranos para os profissionais menos experientes.
6. Lições aprendidas: Nos casos de melhorias ou correções nos conteúdos, a sua atualização nos bancos de dados poderia ser automaticamente disponibilizada para os novos documentos e novas revisões de documentos antigos.
7. Multilinguagem: Os textos poderiam ser desenvolvidos uma única vez em diversas línguas, mantendo a interface com o usuário em sua língua materna. Com isto, o trabalho da tradução seria limitado aos textos dos bancos de dados e não aos textos finais dos documentos, uma vez que toda a verificação de linguagem e ortográfica seria feita na etapa de desenvolvimento do banco de dados.
8. Desdobramento: O método leva a necessidade de desdobramento de equipamentos em sub-grupos: Equipamentos diferentes podem ter sub-grupos bastante similares, que se tratados de maneira adequada podem levar a benefícios para o projeto, manutenção e suprimentos.

Em adição, deve-se considerar que o trabalho para criar tal banco de dados e para o desenvolvimento do sistema em si para gerenciar todas as informações e fazer interface amigável com o usuário seria considerável e uma análise de viabilidade é necessária. Embora existam softwares específicos para automação de documentos, eles são de aplicação para área contratual e um estudo específico para o uso em engenharia deve ser levado em consideração também.

Enfim, este foi um assunto puramente teórico e espero que este texto crie uma necessidade de ultrapassar os limites da teoria e alcançar a prática através de um projeto piloto para comprovar a aplicabilidade deste assunto. Caso comprovado, vejo possibilidades de, por exemplo, integrar planilhas de cálculo para que seus resultados alimentem automaticamente os campos específicos das folhas de dados e memórias de cálculos.

Mais profundamente, o método de desdobramento pode ter sua aplicabilidade não só para a engenharia, como para qualquer ramo da ciência, mas vamos passo a passo.

Referências

https://en.wikipedia.org/wiki/Fault_tree_analysis , acessado em 26/05/2013.

http://en.wikipedia.org/wiki/Ishikawa_diagram , acessado em 26/05/2013.

www.smoothdocs.com, acessado em 17/09/2013.

www.pathagoras.com, acessado em 17/09/2013.

www.hotdocs.com , acessado em 17/09/2013.

Notas:

[1] Árvore de falhas é um método de análise de falhas dedutivo, que analisa o evento da falha através de relações lógicas entre os eventos que podem levar ao estado de falha.

[2] Diagrama de ishikawa é uma representação gráfica causal que representa as causas para um determinado efeito.

[3] Dependendo do Sistema de Gestão de Manutenção empregado na empresa, o plano de manutenção poderia conter informações como a quantidade e tipo de mão-de-obra a ser envolvida, ferramentas a serem utilizadas, materiais a serem consumidos, dentre outros. Por questões de simplificação dos exemplos, estes dados foram omitidos.

[4] 270 diferentes tipos de correias, se referem a 3 tipos de acionamento, vezes 5 tipos de transmissão, vezes 2 tipos de tensionamento, vezes 3 tipos de limpeza da  correia, vezes 3 tipos de absorção de impacto.

Sobre o autor: Heitor Belfort S. Gama, Engenheiro Industrial Mecânico pelo CEFET-MG, com especialização em Engenharia de Planejamento pelo IETEC e pós-graduação em Engenharia de Tubulações pela PUC-RIO. Atualmente trabalha com Manutenção de rede de Gás Natural e experiente com Projetos de Engenharia na área de utilidades para mineração. Possui experiência com Diligenciamento e Inspeções em fornecedores de equipamentos em geral e componentes de tubulações, além de experiências com Manutenção Industrial em fábricas de cimento e industria automobilística e também trabalhos anteriores na área Térmica e com Biodiesel.

E-mail de contato: heitorbelfort@yahoo.com.br

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.