Onde pára o conhecimento

Há algum tempo atrás fui contactado pelos responsáveis do sistema de informação de um organismo público. Não estavam satisfeitos com a empresa de software que desenvolveu e mantinha o seu sistema de informação e pretendiam proceder a uma reimplementação, usando outra tecnologia. A mudança de tecnologia era a escusa para a reimplementação do sistema de informação. De facto, a tecnologia alternativa que se propunha era muito semelhante, em termos das suas capacidades, com a tecnologia existente.

Após conversamos um pouco, apercebi-me que a empresa de software detinha o conhecimento do negócio do organismo público. A empresa de software tinha um melhor conhecimento do negócio do organismo público que os responsáveis do sistema de informação. Esta situação tinha levado a uma situação de dependência. Os responsáveis tinham a sua capacidade de decisão limitada.

Como se chega a este tipo de situação? Neste caso o desenvolvimento seguiu o modelo outsource. Foi desenvolvido um sistema de informação à medida. Geralmente, sempre que  se desenvolve um sistema de informação geram-se as condições para tornar explícito o conhecimento acerca da organização. Durante o processo de levantamento de requisitos, e mais tarde durante o desenvolvimento, vão-se identificar e tornar explícitas as regras de funcionamento da organização.

Um vez tornado explícito o conhecimento sofre várias transformação na forma como está representado para poder ser executado num computador. A sua representação final está incluída do programa que implementa o sistema de informação. Os engenheiros informáticos que participam neste processo ganham um conhecimento profundo sobre o negócio da organização. 

E é aqui que o problema começa. Numa situação de outsource, a organização recebe o sistema de informação mas não recebe necessariamente o conhecimento. De facto, e um pouco paradoxalmente, até perde conhecimento. A automatização trazida pelo sistema de informação faz com que o conhecimento fique transparente para as pessoas que operam a organização suportada pelo sistema. Ou seja, o conhecimento, que estava implicitamente nas pessoas da organização, é tornado explícito e incorporado no sistema de informação, onde fica de novo implicito. A manutenção do sistema de informação, efectuada pela empresa que o desenvolveu, é de facto a manutenção desse conhecimento.

Nesta situação a dependência torna o organização contratante o elemento fraco da relação contratual. E os custos poderão aumentar.

Existem diversas formas de tentar manter o conhecimento dentro da organização. A mais drástica que tive conhecimento foi uma instituição bancária que resolveu adquirir a empresa de software que desenvolveu alguns dos seus sistemas de informação. Um exemplo de passagem de desenvolvimento outsource para in-house. Mas administração pública não tem essa capacidade. Assim tem que procurar manter o conhecimento internamente através dos seus recursos humanos, mas também aí tem que contar com a competição das empresas de software na contratação desses recursos.

Como resolver este problema, no contexto da administração pública, sem voltar ao desenvolvimento in-house? É necessário que a organização não perca o conhecimento. Mais ainda, deve procurar que ele seja público. Para isso, deve ser externalizado, por exemplo participando em organizações de normalização. Por outro lado, deve procurar motivar o aparecimento de comunidades (virtuais) que estejam interessadas na manutenção desse conhecimento. Poderão ser comunidades de utilizadores interessados em discutir como o serviço pode ser melhorado, ou comunidades de cidadãos interessados em auditar o funcionamento da organização. Também se poderá usar o conhecimento na formação, interna ou externamente. Ou seja, o conhecimento deverá ser aberto um pouco por analogia com o software aberto.

A administração publica deve possuir conhecimento aberto para aumenta a sua capacidade negocial  nos concursos para o desenvolvimento e manutenção dos seus sistemas de informação.

A cadeia de valor dos impostos

No livro Colapso: Ascensão e queda das sociedades humanas, Jared Diamond discute como as pessoas podem influenciar as atitudes ambientais das empresas que exploram os recursos naturais do planeta. Para isso, compara o sector petrolífero com o sector mineiro. É de algum modo surpreendente que os impactos ambientais do sector mineiro sejam bastante superiores aos do sector petrolífero, mas as preocupações ambientais do primeiro, por exemplo nos gasto com segurança, são muito inferiores às do segundo. Diamond aponta várias razões, como seja as superiores margens de lucro das empresas petrolíferas, mas aquela que vou abordar é o impacto que as pessoas podem ter nas decisões das empresas sobre questões ambientais.

Uma diferença entre o sector mineiro e o sector petrolífero está na capacidade das pessoas identificarem a cadeia de valor das empresas petrolíferas. A informação sobre um derrame de crude da responsabilidade de uma empresa petrolífera pode influenciar a nossa decisão acerca de abastecermos o nosso automóvel numa estação de combustível dessa empresa. Ou seja, as pessoas possuem algum conhecimento sobre a cadeia de valor da empresa pelo que podem decidir se participam nela como clientes.

Por outro lado, quando adquirimos um automóvel não sabemos de que mina, e empresa mineira, é proveniente o cobre utilizado no fabrico do automóvel. A cadeia de valor de produção do cobre não possui uma identidade que permita a sua identificação pelos clientes finais. A produção de cobre desvanece-se nas cadeias de valor dos produtos em que é utilizado. Desta forma, a pressão sobre as companhias mineiras para terem preocupações ambientais é menor.

Um outro caso em que as cadeias de valor perdem a sua identidade é a do chocolate. Crianças trabalham nas explorações agrícolas de cacau, algumas das quais numa situação de quase escravatura. O problema é idêntico ao do sector mineiro. Quando estou a comer um delicioso chocolate negro não tenho forma de saber em que condições foi produzido o cacau usado no seu fabrico.

No caso do cacau existem iniciativas de certificação do cacau produzido sem a utilização de trabalho escravo, mas há notícias de armazéns certificados receberem a produção de explorações agrícolas não certificadas. Como será possível tornar os processos de certificação mais credíveis e auditáveis pelos consumidores finais?

Um problema semelhante passa-se na cadeia de valor dos impostos. Neste caso as pessoas estão em ambas as pontas da cadeia de valor, como contribuintes e como cidadãos. Mas também aqui lhes é difícil perceber como cidadãos se as suas contribuições foram devidamente aplicadas. Nos últimos anos, os sistemas de informação têm-se mostrado eficazes em garantir que todos os cidadãos contribuem. Mas também deveriam permitir a sua participação na certificação de todo o processo de aplicação das suas contribuições.

Virar o problema do avesso

Há alguns anos atrás, participei num projecto de desenvolvimento de um sistema de informação para a minha escola. O sistema que se encontrava a funcionar na altura tinha sido desenvolvido nos anos 80 e já não suportava com facilidade alterações. O sistema foi a inovador para a época em que tinha sido desenvolvido. Contudo, a tecnologia utilizada tinha-se tornado obsoleta, e estava-se a atingir a situação crítica em que o conhecimento acerca do sistema estava em uma ou duas pessoas. 

Quando procurámos perceber como se tinha chegado a esta situação foram-nos apontadas diversas razões. O projecto foi um sucesso, tendo contado com o apoio da gestão que se tinha envolvido directamente nele, mas o seu envolvimento foi progressivamente diminuindo. Os utilizadores faziam constantes pedidos de alterações dado não haver custos associados, tendo-se tornado um projecto com uma significativa vertente de manutenção. Haver poucas pessoas no mercado de trabalho que dominassem as tecnologias usadas. A incapacidade da escola concorrer com as empresas de software para a contratação dos melhores recursos humanos, quer em termos salariais quer em termos de perspectiva de carreira.

Estávamos portanto perante uma situação típica dos problemas resultantes do desenvolvimento de um sistema in-house. As receitas para este problema são conhecidas: comprar feito (off-the-shelf) ou mandar fazer (outsource). 

O sistema de informação iria focar sobre o core business da escola, a gestão dos planos curriculares, a gestão dos semestres, etc. Por exemplo, pretendia-se vir a ter a capacidade de adaptar facilmente os planos curriculares, curso a curso e ao longo dos anos. Esta situação tornava a solução de comprar feito menos interessante pois o sistema a adquirir seria idêntico ao usados por outras escolas que adquirissem o mesmo sistema, reduzindo a capacidade de o sistema de informação ser um instrumento da estratégia de diferenciação da escola relativamente às restantes. A solução de mandar fazer resolve o problema do suporte informático à diferenciação estratégia dado que sistema será feito à medida. Contudo, requer uma maior competência da escola em termos de informática. É necessário ter profissionais que trabalhem no levantamento de requisitos e que tenham as competências necessárias para gerir o contrato com a empresa de software durante um longo período de tempo. Ou seja, no caso de mandar fazer, a escola terá que ter recursos humanos com conhecimentos na área da informática, enquanto que na opção de comprar feito essa capacidade não será tão relevante.

Em ambas as situações, comprar feito e mandar fazer, embora os custos iniciais sejam menores eles tendem a aumentar com a manutenção que pode durar muitos anos. Uma outra situação que se verifica é que as organizações que seguem estas estratégias ficam dependentes das empresas de software. Relativamente ao desenvolvimento in-house, passa-se da dependência de uma equipa interna para a dependência de uma organização externa.

Este era o problema que tínhamos entre mãos e, dado que já tínhamos identificado as vantagens e desvantagens de cada uma das possíveis soluções, agora era altura de decidir. Este problema é de facto ubíquo a todas as organizações que necessitam de sistemas de informação para o seu funcionamento, espero futuramente voltar a esta questão.

A solução que na altura parecia mais indicada, um pouco influenciada pelo resultado do desenvolvimento in-house, seria de procurar ter o desenvolvimento fora. Contudo nós resolvemos olhar de novo para o problema e reformulá-lo da seguinte forma:

• O problema tem a ver com o facto das actividades associadas ao desenvolvimento do sistema de informação não contribuírem para a missão da escola, embora o sistema de informação dê suporte ao core business da escola.

Tendo reformulado o problema, procurámos perceber qual era a missão da escola e como é que o desenvolvimento do sistema de informação poderia ser colocado nesse contexto:

• Transmissão de conhecimento - dado que uma das missões da escola é o ensino porque não usar o sistema de informação e o seu processo de desenvolvimento como material pedagógico.
• Criação de conhecimento - dado que uma outra missão da escola é a investigação porque não fazer investigação sobre problemas identificados no projecto e aplicar os resultados da investigação no sistema.
• Transferência de tecnologia - dado que a escola tem a responsabilidade de transferir para a sociedade os resultados do seu trabalho porque não fazer o desenvolvimento open-source e motivar outras escolas a usar o sistema e empresas a fazer a sua distribuição e adaptação.

Seguindo esta estratégia, o sistema passa a ter um valor próprio para a missão da escola deixando de ser secundário, embora necessário. Para além disso permitiu-nos resolver alguns dos problemas que identificámos, ou foram pelo menos colocados numa nova perspectiva que permite outras soluções:

• Dado que o sistema é usado no ensino, o número de recursos humanos que conhecem o sistema é maior, evitando que o conhecimento fique reduzido a um reduzido grupo de pessoas. Por outro lado, o custo dos recursos humanos será menor dada a oferta.
• O facto de haver investigação sobre o sistema evita que a tecnologia que usa se torne obsoleta, sendo motivante para as pessoas que nele trabalham, pois sentem que estão a trabalhar com tecnologia de ponta. Por outro lado, os trabalhos de investigação evitarão que o desenvolvimento seja apenas de manutenção.
• A partilha do desenvolvimento e do conhecimento seguindo o modelo open-source permite resistir às flutuações do envolvimento da gestão, o projecto é independente das decisões da gestão de uma particular escola, e de financiamento, as escolas que tiverem mais recursos num determinado momento serão aquelas que "puxarão" o projecto. Adicionalmente, o conhecimento sobre os sistema deixa de ficar limitado a uma única organização.

Apresentei este caso durante um painel da SINFO sobre Sistemas de Informação na Administração Pública pois acredito que muitos dos problemas são iguais àqueles que tivemos que enfrentar. Contudo, não creio que a solução possa ser a mesma pois nestas coisas a "cópia" não funciona. Ainda assim, o espectro das variações sobre as 3 alternativas standard está sempre lá - in-house, off-the-shelf e outsource - a não ser que se vire o problema do avesso.

Da desordem à ordem natural das coisas

"Segundo as teorias mais recentes, a Terra na sua origem seria um pequeno corpo frio que aumentaria depois englobando meteoritos e poeiras meteoríticas.

Ao princípio iludíamos-nos de que conseguiríamos mantê-la limpa -- contou o velho Qfwqf -- ..."

Durante o desenvolvimento de sistemas de informação existe a preocupação que incluam o conhecimento sobre o negócio a que se pretende dar suporte. Este conhecimento, normalmente referido como a lógica de negócio, é determinante no impacto que o sistema de informação vai ter na organização onde será instalado. Passa-se de uma organização onde o conhecimento se encontra nas pessoas, e que depende delas para o seu funcionamento, para uma situação em que o sistema de informação orienta as acções das pessoas de acordo com a lógica de negócio que implementa.

São inúmeras as vantagens do sistema de informação incluir a lógica de negócio. Para além da normalização do funcionamento do negócio, permite automatizar muitas acções reduzindo custos, e assegurar que as regras definidas são seguidas.

Antes da instalação do sistema de informação, é frequente que a organização possua um reduzido nível de controlo, a eficiência seja baixa, aconteçam muitas situações de erro, haja dados incoerentes e não seja possível obter-se a informação que se necessita com facilidade. Neste contexto, o impacto da instalação do sistema de informação é o de arrumar a organização.

"...A Terra começava a ficar tão grande que já nem todos os dias Xha conseguia ter tempo para a correr toda..."

Contudo, mesmo que se deseje, não é possível incluir todo o conhecimento acerca do negócio no sistema de informação, e mesmo se isso fosse possível a sua utilização faz surgir novas situações que não estavam abrangidas pelo corpo de conhecimento inicial.

Por outro lado, quando o conhecimento passa das pessoas para o sistema de informação acontece um fenómeno de desresponsabilização. Sendo o sistema detentor do conhecimento, as pessoas que o utilizam passam a delegar toda a responsabilidade do que acontece, positivo ou negativo, no sistema.

Contrariamente ao que ocorria antes, em que não obstante a desordem, as pessoas assumiam os problemas como seus e eram pró-activas para a sua solução, agora, tudo o que o sistema não resolve é uma impossibilidade, não tem solução: O sistema não deixa!

"...Assim, qualquer objecto novo que caísse sobre o nosso planeta acabava por encontrar o seu lugar como se sempre ali estivesse estado, a sua relação de interdependência com os outros objectos, e a irracional presença de um achava a sua razão na irracional presença dos outros, a ponto de a geral desordem começar a poder ser considerada a ordem natural das coisas..."

Existem tecnologias que ajudam as pessoas a fazer o seu trabalho sem orientar as suas acções, como o correio electrónico ou os wikis. Mas estas tecnologias não suportam lógica de negócio, são tecnologias genéricas de suporte à colaboração entre as pessoas.

Um dos actuais desafios da engenharia de software é criar as ferramentas que orientem as acções das pessoas mas não as desresponsabilizem. Que a lógica de negócio não iniba a reacção e o tratamento do imprevisto. Que o que não foi considerado no desenho inicial do sistema possa ser relacionado com o que foi tomado em consideração. Os sistemas de informação, e as tecnologias sobre os quais são desenvolvidos, deverão passar a ter embutidos de raíz funcionalidades semelhantes às do correio electrónico e dos wikis.

O texto entre aspas foi transcrito do conto Meteoritos de Italo Calvino, publicado pela Editorial Teorema, no livro Novas Cosmicómicas, numa tradução de José Colaço Barreiros.

Das comunidades virtuais

Participei num painel da semana de informática do IST (SINFO) sobre Sistemas de Informação na Administração Pública. Dos vários assuntos que foram discutidos, um é particularmente importante para a pergunta sobre como é que os sistemas de informação podem aumentar a capacidade de intervenção dos cidadãos no desenho, implementação e auditoria dos projectos públicos: as comunidades virtuais.

O tema das comunidades virtuais, ou comunidades de prática, foi referido, pelo participante da AMA no panel, numa vertente de redução de custos. Alguns casos referidos foram o Wikipedia e o Directionleesgov em que grupos de cidadãos de forma (des)interessada participaram em projectos que se revelaram tanto ou mais eficazes que projectos semelhantes mais pré-estruturados e desenvolvidos com (muito) mais recursos financeiros, respectivamente a Encyclopeadia Britannica e Directgov. Para além da redução de custos que as comunidades virtuais podem trazer, devido a uma distribuição voluntária do trabalho originada pelas mais variadas razões, um outro é o caso do Google Image Labeler, as comunidades virtuais são a base de uma nova forma de participação das pessoas que é possibilitada pela tecnologia.

O sucesso das comunidades virtuais depende da mistura acertada de aspectos tecnológicos e sociais. Por exemplo, as comunidades virtuais do Facebook, do YouTube e do Wikipedia têm características diferentes. No Facebook a identidade dos membros da comunidade é credível, ainda que possam ser forjadas identidades. Isso é possibilitado pelo conjunto de funcionalidades do Facebook que levam a que sejam associadas fotografias às pessoas, não apenas pelos próprios mas também por outros. Adicionalmente, a principal forma de criação dos grupos sociais é através do conceito de amigo, ainda que no contexto Facebook o conceito de amigo tenha ganho um significado próprio, um exemplo das metamorfoses resultantes das interacções entre a tecnologia e as pessoas. Por outro lado, no YouTube as identidades estão mais próximas do avatar, em que a metamorfose possibilitada pela tecnologia é explicitamente assumida e explorada. Já no Wikipedia a identidade não é explícita no conteúdo, o conteúdo é de facto uma construção social onde se diluem as identidades que o criaram, mas fica registada (não obstante serem permitidas participações anónimas) no processo de criação. Este registo é importante para a formação dos grupos sociais do Wikipedia que são baseados no mérito da contribuição social reconhecido pelos pares.

Em suma, diferentes comunidades têm diferentes características as quais são possibilitadas por diferentes funcionalidades da tecnologia e os objectivos das pessoas que usam a tecnologia. O Facebook é uma comunidade onde se socializa, no YouTube a comunidade é quase secundária e funciona para a difusão de emoções após a visualização de um video (audição de uma música), enquanto que no Wikipedia é uma sociedade de artífices movidos por uma ideia de bem comum.

O Orçamento Participativo da Câmara Municipal de Lisboa é uma iniciativa que promove a intervenção dos cidadãos no desenho e decisão sobre projectos municipais. A iniciativa vai no caminho certo de retirar os cidadãos da ponta das cadeias de valor onde são aplicados os seus impostos. Neste caso, os cidadãos podem participar no desenho, através da apresentação de propostas, e na atribuição de recursos, através do voto em propostas.

Contudo, este exemplo mostra que não é fácil desenvolver estes projectos e que é necessário aprender com a experiência e ir afinando a relação entre a tecnologia e as pessoas. Por exemplo, a minha participação foi inicialmente motivada pelo sms de um amigo que me incentivava ao voto num projecto que tinha ajudado a conceber. Ulteriormente recebi um email de uma outra pessoa a promover o seu projecto. Uma vez feito o acesso no sítio pude ver alguma informação sobre os projectos e votar. Senti falta da comunidade virtual. Tomei conhecimento do projecto no contexto de comunidades externas ao contexto do projecto, o município de Lisboa, e uma fez que acedi ao sistema de informação não fui cativado a aderir a uma comunidade virtual e a interagir com ela, mas apenas a votar.

Não é fácil desenvolver estes projectos, se o fosse a Google já teria transformado a comunidade YouTube numa concorrente séria da comunidade Facebook. É necessário caracterizar a comunidade que se pretende ter, quais os seus objectivos e como é que tudo poderá ser possibilitado por um conjunto de funcionalidades da tecnologia, as quais terão que ser afinadas de acordo com a caracterização da comunidade pretendida.

Do público e Do privado

Há algum tempo fiz uma apresentação, numa sessão organizada pela ComputerWorld dedicada à engenharia de software, em que descrevi um caso de desenvolvimento e instalação de um sistema de informação para a administração pública.  Como muito frequentemente acontece, o projecto teve um atraso de 18 meses e o custo foi 3 vezes superior ao inicialmente orçamentado. Para além disso, quando entrou em funcionamento, originou um conjunto de situações que ficaram fora de controlo, onde aspectos sociais e tecnológicos se entrelaçaram e se tornou difícil destrinçar as causas dos efeitos.

Em traços gerais, após um custo de valor equivalente a cerca de 18 milhões de euros, o sistema foi para produção tendo como resultado que um elevado número de funcionários tiveram problemas com o pagamento dos seus vencimentos. O que se seguiu foi o envolvimento de técnicos e políticos, governo e oposição, sindicatos e media. O caso foi primeira página dos jornais, notícia nas televisões e tornou-se alvo das conversas de rua. O projecto era o primeiro, e era visto como o demonstrador, de uma nova estratégia para os sistemas de informação da administração pública, a de ter serviços partilhados.

Após a minha apresentação, perguntaram-me se os resultados teriam sido os mesmo caso o projecto tivesse ocorrido numa empresa privada. A pergunta tem uma resposta "óbvia": os resultados não teriam sido os mesmos. O projecto teria sido cancelado mais cedo, teria sido mais fácil apurar as responsabilidades, etc, etc, etc. Contudo, a resposta "óbvia" peca por dar uma visão redutora do problema, uma vez que não é trivial "privatizar o público".

Senão vejamos. O que distingue um projecto privado de um projecto público é o conjunto de stakeholders envolvidos. Em particular, um projecto público é financiado com o dinheiro dos contribuintes, o que os torna em intervenientes interessados nos resultados do desenvolvimento do sistema, em tudo semelhante ao interesse dos accionistas da empresa privada no resultado dos projectos da empresa. Contudo, existem diferenças na forma como eles, os accionistas e os contribuintes, podem intervir.

A intervenção dos contribuintes nos projectos públicos é mais indirecta que a intervenção dos accionistas nos projectos privados. Quando votam não estão a avaliar o sucesso ou insucesso de um particular projecto, ou de um conjunto de projectos, em última instância o lucro da empresa, mas sim um vasto conjunto de resultados económicos e sociais. Por outro lado, os contribuintes não podem vender as suas participações no capital público.

A solução de transformar os projectos públicos em privados, latente na pergunta, é falaciosa pois pressupõe que é possível criar projectos do interesse público em que os contribuintes não são stakeholders.

Ou seja, não é possível "privatizar o público".

É claro que este problema não se aplica apenas a projectos de desenvolvimento de sistemas de informação. Mas tem uma especial incidência no desenvolvimento de sistemas de informação pois nestes as fases de desenho, implementação e manutenção intercalam-se, dificultando a gestão e controlo do projecto. Assim, uma questão importante, que tem que ser levantada, é como desenvolver sistemas de informação onde existe financiamento público, de uma forma eficaz, e tirando partido da própria orgânica dos stakeholders envolvidos, em vez de os negar. Por outro lado, e relacionado com a questão anterior, é importante perceber como é que as tecnologias de informação podem ajudar os stakeholders localizados na ponta de uma longa cadeia de valor onde são aplicadas as suas contribuições, a ser mais intervenientes no desenho, implementação e auditoria dos projectos públicos.

É necessário fazer estas perguntas para encontrar respostas que vão ao cerne do problema.