A linguagem da informação

O desenvolvimento do sistema de informação para o registo electrónico de pacientes no Reino Unido, Public procurement: Only the bare bones, é mais um caso sintomático das dificuldades de desenvolvimento de sistemas de informação. Lançado com pompa e circunstância, arrasta-se agora carregando o seu manto de dinheiro.

O caso tem algumas semelhanças com o descrito em Do público e Do privado. Mas, há uma questão interessante que é levantada na notícia. O registo electrónico de pacientes é um objectivo inquestionável, que todos concordam ser necessário, mas parece não ter solução. A abordagem centralizada falhou, mas a delegação nas unidades de saúde também não parece trazer, refere um responsável, os resultados desejados.

Stephen Pinker, no seu livro How the Mind Works, defende que a linguagem é inata, é um órgão. Existe um período no crescimento humano em que esse órgão se modela para criar a linguagem. Num exemplo, adultos que têm contacto tardio, embora prolongado, com outra língua têm dificuldade em construir frases que não tenham ambiguidades, enquanto que os seus filhos criam uma língua própria (crioulo), ainda que possuindo simplificações gramaticais, por junção de elementos da língua materna e da língua exógena, e com a qual constroem frases sem ambiguidades.

A actividade dos profissionais de saúde implica uma grande responsabilidade pois das suas acções pode depender a vida humana. Frequentemente essa responsabilidade é a título individual e resulta das interacções directas e pessoais entre o profissional e o paciente. Nestas interacções a linguagem é um elemento importante e pode ganhar um carácter único, quer associado ao profissional, quer associado à sua interacção com o paciente. A tentativa de normalizar essa linguagem entre os profissionais não é uma tarefa fácil.

A definição de normas em sistema de informação também não tem sido uma tarefa fácil, embora seja percebida por todos como necessária. Tem havido duas abordagens, a abordagem centralizadora e a abordagem de consenso. A abordagem de centralizadora acontece quando uma tecnologia se torna hegemónica e fica a norma de facto. A vantagem desta abordagem é que não necessita de criar compromissos tecnológicos, pelo que frequentemente a tecnologia é mais simples. Por consenso acontecem duas situações, por um lado a tecnologia vai ter de integrar muitos compromissos, pelo que ficará mais complexa, e por si só não assegura que irá ser adoptada. O comité de normalização pode ser o local onde os vários interessados medem forças (disputa de memes).

A tecnologia existe para satisfazer as necessidades das pessoas e o seu uso, e muito em particular o uso da tecnologia da informação, está intimamente ligado à sua linguagem. Um dos aspectos centrais do desenvolvimento de um sistema de informação é a criação, ou alteração, de uma linguagem.

O cavaleiro branco do mercado

Quando era garoto havia um anúncio na televisão que me impressionava. Era o cavaleiro branco do Ajax! Impressionava-me pela sua brancura imaculada, cavalo branco, armadura branca e lança resplandecente. Talvez também fosse por causa da televisão ser a preto e branco e o cavaleiro sobressair no meio de todos aqueles cinzentos.

Desde a queda do comunismo, que o meme do mercado se tornou dominante na "pool" de memes (Da democracia e Dos genes). Tornou-se de tal forma dominante que muitas vezes o dito "mas isso é o mercado a funcionar" acaba com qualquer tentativa de argumentação.

Contudo, o mercado para funcionar pressupõe algum equilíbrio nas relações entre os agentes. Da mesma forma que quando uma planta, ou um animal, se torna dominante no seu ecossistema o acaba por destruir, e a prazo destrói-se a si mesma, também as relações de desequilíbrio entre os agentes do mercado podem levar a situações de ruptura, como por exemplo os problemas resultantes de acentuados desequilíbrios sociais.

Infelizmente, a administração pública é um agente fraco na relação de mercado. De facto, esse tem sido o tema de alguns dos posts deste blogue. A administração pública tem dificuldade em concorrer com as empresas privadas para a contratação dos melhores recursos humanos (Virar o problema do avesso), não consegue manter conhecimento acerca dos seus próprios processos (Onde pára o conhecimento), tem dificuldade em auditar a aplicação do dinheiro dos impostos (A cadeia de valor dos impostos), não consegue criar mecanismos de avaliação interna focados em objectivos que sejam percebidos pelas pessoas (Onde começa a avaliação), etc.

Recentemente, tem aumentado o número de defensores de uma solução de mercado para aquilo que tradicionalmente era público. Uma parte significativa da economia Portuguesa está ligada ao dinheiro público, aquele que resulta dos impostos, mas sendo a administração pública um agente fraco da relação de mercado temo que a sua prestação na gestão do dinheiro público não venha a ser muito diferente da actual. Poderá mesmo piorar, pois algumas situações que se venham a criar, especialmente as de desequilíbrio social, serão justificadas com "é o mercado a funcionar".

Mas será mesmo "o mercado a funcionar"? 

Para o mercado funcionar de facto a administração pública tem que ser um agente forte. Mas, como isso não se tem verificado até agora, não é por abrirmos as portas e "deixarmos entrar o mercado" que a administração pública se vai tornar num agente forte. O mercado terá dificuldade em funcionar pois o problema actual com a gestão do dinheiro público não é mais ou menos mercado.

Ou seja, é necessário criar as condições para a administração pública seja forte e defenda os interesses daqueles que pagam os impostos. Quando isso acontecer, pode-se abrir sem medo as portas ao mercado. De facto os outros agentes terão muito a temer desse agente forte, dado o volume de negócio que ele gera.

Mas, para tornar a administração pública mais forte é necessário aproximar os seus stakeholders, aqueles que pagam impostos, dos processos e decisões de gestão, quer como observadores/auditores quer como participantes activos. Os sistemas de informação poderão ter um contributo importante, pois permitem esbater as distâncias geográficas, políticas, de poder, de acesso à informação, de decisão e de comunicação. Contudo, o desafio é saber como isso pode ser conseguido através da conjugação adequada dos aspectos técnicos dos sistemas com as características sociais de quem os usa.

Onde começa a avaliação

A avaliação dos professores do ensino básico e secundário tem sido prolongadamente discutida. São inúmeros os parâmetros de avaliação, desde o progresso escolar dos alunos, até à assiduidade dos docentes e à organização de actividades extracurriculares.

Não obstante longamente discutida, a questão continua em aberto e prevê-se que venha a ser de novo discutida. Contudo, creio que existe um outra questão que tem que ser respondida primeiro. E é relativa aos alunos.

Como avaliar o percurso escolar dos alunos de uma forma imparcial e levando em consideração as especificidades sociais e económicas de cada aluno?

Para se responder a esta questão é necessário desenhar um sistema de informação que armazene os resultados escolares de cada aluno. Contudo isso não é suficiente. A progressão escolar do aluno deve ser ponderada pelo seu contexto social e económico.

É necessário escolher quais os aspectos sociais e económicos a considerar e os pesos para ponderar cada um deles. E eles poderão inclusivamente variar ao longo do tempo. Essa variação pode ocorrer por duas razões. Quer porque os tipos de condição social e económica dos alunos se alteram, ou porque os dados que vão sendo acumulados no sistema de informação permitem novas perspectivas sobre as realidades sociais e económicas dos alunos.

Esta é um dos exemplos de metamorfose entre a tecnologia e as organizações. Por um lado, os indicadores para os aspectos sociais e económicos são definidos em função da nossa percepção da realidade social e económica, mas, por outro lado, a existência do sistema vai permitir que tenhamos novas percepções sobre a realidade social e económica. Adicionalmente, a existência de um sistema de informação como este irá provocar alterações nos comportamentos dos stakeholders, o que obrigará à evolução do próprio sistema. 

Um exemplo de como um sistema de incentivos, o qual pressupõe uma avaliação, influencia o comportamento dos stakeholders vem descrito no livro Freakonomics. Em Freakonomics os stakeholders que respondem aos incentivos são professores, mas, não é estranhar que, se por exemplo, os resultados dos exames nacionais for primeira página sensacionalista dos jornais, e não obstante a educação ser uma corrida de fundo, os responsáveis pela gestão da educação tenham os incentivos errados.

Ou seja, não basta ter um sistema de informação é também necessário criar o contexto organizacional em que ele funcione de acordo com os objectivos para que foi desenhado. Neste caso da avaliação dos alunos, é necessário que a avaliação do percurso dos alunos seja imparcial. Para isso os alunos devem ser submetidos a avaliações uniformes e o processo deve ser auditado pelos cidadãos. O sistema de informação poderá ajudar na auditoria. De facto, foi por análise de um grande conjunto de dados que os autores de Freakonomics obtiveram as suas conclusões. Os cidadãos devem poder ter acesso aos dados do sistema de informação, uma vez que estes sejam limpos de informação pessoal. Assim, haverá um importante factor de regulação do sistema. Como os grupos de cidadãos se poderão organizar está relacionado com os aspectos da cidadania virtual e das comunidades virtuais que já referi em posts anteriores.

Concluindo, ao avaliar o percurso dos alunos estamos a criar as condições para avaliar todos os stakeholders do sistema. Relativamente aos professores, será inclusivamente possível criar incentivos para premiar os professores que conseguem bons resultados com os alunos social e economicamente mais desfavorecidos.

Mas também é possível avaliar os gestores da educação, e dada a existência de dados mais objectivos os incentivos serão para se concentrarem na eficácia e eficiência. Claro que os resultados serão menos espectaculares, não haverá significativas mudanças do sucesso escolar de um ano para o outro. Mas uma vez que isso seja percebido pelas pessoas, os incentivos para os gestores da educação serão reforçados no sentido certo.

A informação disponibilizada pelo sistema de informação estará mais próxima da realidade e será um bom indicador para apoio à decisão. Ela permitirá indicar como vai ser a nossa competitividade daqui a 20 anos relativamente aos restantes países europeus, claro que para isso é necessário ter programas e avaliações uniformes a nível europeu para as algumas disciplinas. Também indicará se as zonas socialmente mais desfavorecidas se encontram em evolução para uma sociedade mais equilibrada ou em direcção à criação, ou manutenção, de uma zona de exclusão social.

E acima de tudo, os cidadãos terão acesso a esta informação e podem ter uma influência mais directa sobre as políticas educativas e sociais, a sua eficácia e eficiência, nas quais é aplicado o dinheiro dos seus impostos.

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.

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.

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.