Diferença entre CDE e GED

Qual a diferença prática de um GED e um CDE?

Vamos primeiro para os termos em si:

GED: gestor eletrônico de documentos

CDE: Common Data Environment (Ambiente Comum de Dados).

Aqui gostaria de deixar claro que eu não vou escrever de forma a traduzir o que as normas dizem, especialmente a 19650. Eu quero produzir uma explicação e ensinamento sobre esse conceito de forma mais tangível a realidade de algumas organizações e tentando dar exemplos que aproximem essas definições da realidade de como as pessoas produzem e coordenam projetos. 

Ainda enxergo a norma como o objetivo de muitos mas a realidade de poucos.

O GED sempre terá por natureza apenas a gestão de documentos em si, um grande repositório para controlar o que é cadastrado e disponibilizado aos participantes de um projeto. Como diria o Rafael Evangelista, um cartório para as entregas. 

O CDE é um ambiente em que os dados são acessíveis pelos interessados no projeto de forma que todos tenham acesso ao mesmo dado de forma comum e sincronizada ao contexto do projeto. Note que isso é diferente de produzir o projeto em simultaneidade.

O GED pode as vezes ser confundido com CDE pois existem organizações que modelam seu processo para ser orientado a arquivos e aprovação de arquivos.

O próprio IFC e o uso de BCF sem um servidor BCF que siga por base a BCF REST API que a buildingSmart são assim, GED de processos orientados a arquivos.

Topologia 1 - Colaboração de modelos é gerenciada por meio de um servidor de arquivos compartilhado ou um serviço de compartilhamento de arquivos em rede. O BCF-Server lida com a autenticação e as BCF-Issues (tópicos BCF)

Topologia 2 - O servidor BCF e o servidor de modelos estão localizados nos mesmos hosts

As imagens mostram como seria a topologia idealizada de 2 formas para um OpenCDE que a buildingSmart considera que é orientado a arquivos, mas eu considero isso ainda distante de ser atingido pela vasta maioria das organizações e o mais comum é o GED num processo orientado completamente a arquivos.

Desta forma, a publicação e aprovação de um arquivo representa o andamento e a passagem formal de informações, e sobre este arquivo, podem existir interações de demais participantes do projeto, então o processo fica totalmente ou em partes orientado a arquivos. Alguns exemplos são:

• Cronograma publicado e comentado sobre o arquivo

• Relatório de compatilização publicado, então é baixado, respondido pelos envolvidos e publicado revisado. A passagem de informação se dá pela progressão de revisões do arquivo

• Arquivos de projeto publicados, baixados por envolvidos e sobre ele são feitos comentários dentro do próprio arquivo e o arquivo é republicado em nova versão

• Comunicação de eventos do projeto através de publicação de arquivos com as informações

Estes processos não são errados, não há errado aqui, mas essa mistura de função de GED com processo orientado a arquivos faz com que os GEDs absorvam “responsabilidades” para as quais normalmente não foram projetados.

Essa prática faz com que o GED seja o núcleo de obtenção de informações do projeto, o problema é que isso é DIFERENTE de ambiente comum de dados.

Se duas pessoas estiverem trabalhando sobre uma mesma versão R00 do mesmo arquivo e cada uma está fazendo seus próprios comentários eu seu ambiente local sobre um assunto igual, então NÃO SE CARACTERIZA um processo num ambiente comum de dados, mas sim um trabalho simultâneo que produzirá duas versões posteriores do mesmo arquivo mas diferentes entre si. 

Para que isso funcione, é obrigatório que haja uma sincronia de ações entre todos os intervenientes que estariam praticando essas ações, o que na prática é muito difícil e abre muito espaço para erros. Para que essa orientação a arquivos tenha a capacidade de representar dados sincronizados ao contexto do projeto, seria necessário o uso de ferramentas que permitem trabalho simultâneo, que ainda são raras as que de fato funcionam.

Aqui é onde o CDE entra em cena entregando mais valor ao processo de forma diferente do GED num processo orientado a arquivos.

O CDE estará sempre orientado a containers de informação. Os containers de informação podem ter definições diferentes segundo a organização. Algumas enxergam como pacotes de entrega (ver artigo sobre a metologia PEI - Pacotes e Entrega Integrados) que abstraem um conjunto de informações ou mesmo um conjunto de arquivos, outras podem tratar como isso e ainda incluir tópicos BCF do projeto como parte de seus containers.

Aqui o importante é entender que cada organização delimitará uma linha que vai dividir toda informação produzida no contexto do projeto em containeres, sendo que esses containeres servirão a propósitos distintos durante o ciclo de vida do projeto. Isso está acima de fases e revisões de arquivos.

Perceba através desse exemplo: o estudo de viabilidade de um empreendimento determina algumas premissas básicas que devem ser um drive importante para tomadas de decisões e balizamento do trabalho no projeto até o seu fim. As premissas de um estudo de viabilidade não tem nenhuma obrigatoriedade de estarem caracterizadas num único arquivo ou num conjunto deles, podem nem estar de fato documentadas de forma estruturada, mas sem dúvida caracterizam um container de informação que alimentará containers de informação subsequentes dentro do projeto. Essas premissas inclusive nunca irão para um GED por motivos de segredos de negócios e mesmo assim são um container de informação relevante para todo o projeto.

Toda essa abstração trás dificuldades para enxergar como isso se materializa na prática. Isso acontece muito. O CDE em que um projeto decorre poderá ser limitado a 1 ferramenta ou ser um conjunto de várias: GED, modelo federado, relatórios, cronograma, tópicos BCF, anotações, checklists dentre tantos outros. Se todos esses dados e informações estiverem dentro de um ambiente ou sistema que permite aos interessados envolvidos acesso a informação certa na hora certa, contextualizada ao estado atual do projeto, isso começa a se materializar como um CDE de verdade. Note que neste cenário o GED é apenas UM COMPONENTE DO CDE.

Veja a imagem abaixo do PR 1015 que materializa a estrutura que expliquei acima:

Agora você pode estar se perguntando: 

Como eu posso implementar um CDE em sua plenitude no meu projeto ou na minha organização?

Nos próximos artigos eu vou explicar como estamos resolvendo esse problema na prática, ferramentas envolvidas e metodologia utilizada, inclusive como vamos selecionar alguns interessados para que possam ser os primeiros a adotar a nossa metodologia, o Método PEI em suas empresas.

Comente "Método PEI" para registrar seu interesse!