Databook nos empreendimentos

O databook, como diz o nome, é, em tese, um livro de dados que compila todos os documentos de um serviço. Pode ser utilizado em serviços quaisquer e para todo um empreendimento. Obviamente, quanto maior a complexidade, a multidisciplinaridade e o porte do serviço ou empreendimento, maior será o databook, ou seja, mais documentos ele conterá. O databook é concluído, então, ao final do serviço, mas precisa ser preparado ao longo de todo ele, exatamente para que no final não se torne um enorme desafio.

Os processos de trabalho devem ser organizados e estruturados de forma a facilitar a produção, guarda e atualização dos documentos, para que sua compilação no databook seja simplificada. O databook, na realidade, é concluído com relativa facilidade na entrega do serviço, quando os processos já o estruturam ao longo do ciclo de vida.

Mas, o que deve constar no databook? Quais documentos devem ser reunidos nele?

Não há uma norma geral para montagem do databook, cada organização (normalmente a contratante do serviço) tem suas exigências. Seu uso é mais comum nas grandes organizações, sobretudo no setor industrial. E, claro, não se paga (ou não se deveria pagar) para reunir documentos sem utilidade. O databook serve a um propósito e sua composição está relacionada ao uso que se fará dele.

Seu viés de registro histórico é inevitável, afinal reúne dados e informações que foram reunidas ao longo do processo do serviço, mas é preciso haver uma finalidade no databook, nem que seja servir de base de dados para pesquisa futura.

Você já reparou que o databook se refere a um serviço. Logo, serviços diferentes geram databooks diferentes. Um empreendimento que reúne vários serviços pode gerar bários databooks, mas sempre será possível compila-los de forma específica que se preste a algum uso posterior. Não seria equivocado pensar no databook de um grande empreendimento como uma grande coleção de volumes (se for um databook físico), ou uma grande coleção de arquivos eletrônicos (para os databooks digitais).

Repare que não é exagero, num grande empreendimento, pensar nas técnicas de organização de grandes bibliotecas. Profissionais da Biblioteconomia e das Ciências da Informação podem ajudar bastante. Aliás, é geral a percepção, nos meios técnicos que demandam databooks, de que um dos maiores entraves na geração de bons databooks atualmente é a falta de conhecimento e metodologia adequados para gerenciá-los. Isso inclui a consideração desta entrega ao longo de todo o ciclo de vida de um serviço ou empreendimento.

Consideremos o caso da construção civil pela perspectiva do proprietário de um edifício. É certo que podem ser vários proprietários, num edifício residencial por exemplo, mas em geral são representados por uma única organização, que pode ser uma incorporadora, ou o condomínio.

Aí encontramos já uma dificuldade no caso de a incorporadora ser também a construtora, realidade comum no mercado. Os fornecedores têm a obrigação de entregar o databook ao proprietário ou empreendedor, mas a construtora (fornecedora da obra), nesses casos, é o próprio empreendedor (o incorporador). É preciso ter clareza da distinção destes papeis para que se consiga organizar processos capazes de garantir um bom databook. A incorporadora aliviar requisitos para a construtora (considerando que são a mesma organização) não ajuda na geração de um databook realmente útil.

Aqui aparece outra grande dificuldade percebida no mercado para a criação de databooks, a ausência de requisitos específicos para ele. De fato, é difícil estruturar processos para gerar um produto cuja especificação e requisitos não estão claros. E há muitos requisitos possíveis para um databook.

Os requisitos de formato ou formatação definem os padrões de apresentação, que pode ser física, ou digital. Falamos aqui de capas, dimensões, formatos de arquivos, tamanhos de arquivos etc. Parecem detalhes, mas esta padronização é condição para eficiência no posterior uso. Se cada databook entregue a um proprietário ou empreendedor tiver um formato diferente, será consumido muito tempo quando se for procurar uma informação nestes documentos, que são bem extensos e complexos.

Os requisitos de organização definem as seções e subseções necessárias ao documento. Deve haver aqui uma estratégia de hierarquização dos conteúdos sob a ótica de quem vai usá-lo posteriormente. O databook de um projeto de engenharia pode, por exemplo, organizar os documentos por especialidade ou disciplina técnica. Mas pode também os dividir em documentos gráficos e textuais. E nada disso exclui a necessidade de uma seção para documentos administrativos como contratos com seus anexos e anotações de responsabilidade técnica. E ainda fica a dúvida sobre incluir ou não, atas de reuniões, análises de trade offs, catálogos de fabricantes especificados, documentos financeiros ou fiscais etc. É possível pensar várias formas de estruturar o databook, mas, como já dito, depende do uso que o empreendedor dará a ele posteriormente.

Pode-se pensar que, se o databook é um compêndio de informações, todas elas já constam nos diversos documentos produzidos ao longo do processo e, portanto, o databook é um documento secundário, ou até desnecessário. De fato, as informações do databook foram produzidas ao longo do processo, mas o seu valor não está meramente nelas.

Para compreender isso é preciso lembrar que uma mensagem tem basicamente três fundamentos: os códigos ou repertório utilizado, uma ordem na qual seus elementos são dispostos criando as conexões e o sentido relativo entre eles, e a estrutura que, por si só, garante uma macro compreensão de seu uso e finalidade. O databook está focado na ordem e na estrutura. Ou seja, ele é uma nova mensagem, com repertório similar aos das mensagens parciais do processo, estruturada e organização de forma mais adequada que não seria possível no início ou meio do processo, exatamente porque não havia todo o seu conteúdo já produzido.

O fato é que o databook é um conjunto de documentos (mensagens e informações) cuja efetividade de uso pretende ser maior que a mera soma do que cada documento permite isoladamente. Se o uso mais eficaz do databook não é percebido por uma organização (proprietário ou empreendedor), dificilmente será possível estabelecer requisitos para a produção deste importante recurso nos empreendimentos.

E, como explicado, esta dificuldade produz não apenas um problema pontual, mas retrata possíveis falhas nos subprocessos exatamente por não permitir que o databook aconteça naturalmente no decorrer do empreendimento.