terça-feira, 29 de março de 2011

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.

sábado, 19 de março de 2011

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.

domingo, 13 de março de 2011

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.

domingo, 6 de março de 2011

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.