por Alexandre Pesserl e Pablo de Camargo Cerdeira
Os programas de computador, nos dias atuais, já podem ser considerados como parte indissociável do patrimônio e do capital de empresas dos mais diversos portes. Assim, quando de uma auditoria sobre o chamado “legado de software”, aquele conjunto de programas que a empresa se utiliza, é titular ou licenciada, é muito comum encontrar as mais diversas conjunturas. Segundo estudo divulgado recentemente, 70% das empresas têm software obsoleto.
As situações mais complexas costumam ser encontradas em empresas que iniciaram seu processo de informatização há mais tempo. Nestas, o legado de softwares em geral é muito grande, e suas documentações jurídicas e técnicas costumam ser muito escassas ou inexistentes.
Como agravante, também não é raro que os softwares originais, principalmente os desenvolvidos há mais de 15 anos, estejam vinculados aos seus hardwares, grandes computadores que praticamente ninguém mais sabe como funciona e nem o que se passa dentro daquela “caixa-preta”.
Outra situação considerada complexa é aquela em que os programas originais, licenciados de determinada forma, foram sendo alterados ou complementados por outros softwares, por vezes internamente, ou com sua terceirização. Depois de algum tempo torna-se difícil determinar o que é software original (sujeito à licença original), o que é software novo e quais são os direitos e obrigações da empresa que utiliza tais sistemas.
Nestas hipóteses, em que não se conhece mais o ativo informático pertencente à empresa, a terceiros e nem o que ainda deve ser pago a título de licenciamento, contrato de suporte técnico, etc, os prejuízos podem ser significativos.
Podemos detectar claramente os seguintes pontos fracos oriundos deste cenário:
1. Determinação de ativos: softwares podem ser considerados ativos no patrimônio de seus titulares, já que programas de computador são considerados bens móveis pela legislação brasileira em vigor. Entretanto, isso não ocorre quando ele é apenas licenciado; para que um software integre o ativo é preciso que haja a transferência da sua titularidade. Para que gere efeitos contra terceiros, a transferência de titularidade demanda certas formalidades, como o registro junto ao INPI. Assim, a ausência de um rígido controle de inventário de softwares poderá representar uma perda significativa de ativos.
2. Custos de licenciamento e dificuldade de renegociação: muitos softwares, principalmente os corporativos mais antigos, são licenciados mediante um contrato que prevê pagamentos sucessivos, mensalmente ou com certa freqüência pré-determinada. Muitos desses softwares, entretanto, não são mais utilizados, ou têm importância muito reduzida, o que permitiria à empresa renegociar os contratos de licenciamento. Deste modo, a ausência de informações a respeito desses softwares pode prejudicar a listagem de argumentos para a negociação junto aos desenvolvedores ou titulares.
3. Sobreposição de sistemas e adição de valor: os softwares têm uma peculiaridade se comparados aos bens móveis propriamente ditos: podem facilmente ser reproduzidos, alterados (se estiverem com o fonte disponível) ou serem agregados a, ou terem a eles agregados, outros softwares. Isso faz com que as fronteiras delimitadoras de onde se inicia e termina um programa tornem-se mais tênues com o passar dos anos. Mais uma vez, a ausência de um rígido controle técnico e jurídico sobre o legado de softwares pode ensejar uma perda de divisas considerável.
4. Implantação e manutenção de padrões de qualidade e gestão de projetos: segundo pesquisa do Ministério da Ciência e Tecnologia, mais da metade das empresas estava desenvolvendo um plano de gestão estratégica de qualidade do software. É preciso que essas metodologias sejam não apenas implantadas, mas também mantidas e atualizadas. Assim, a ausência de relação com a contabilidade pode ser uma das falhas mais sérias nas empresas que buscam sistematização da gestão de projetos de software. Apenas 6% das empresas mantém contabilidade sistemática dos custos da qualidade.
5. Ausência dos benefícios de uma certificação: as empresas que não organizam e estruturam sua gestão e produção de softwares, além dos problemas já citados, deixam de se beneficiar das diversas e positivas certificações existentes no mercado. Por exemplo os padrões ISO 9001 e ISO 9002. Se a empresa possui porte suficientemente grande para internalizar a produção de softwares, poderá almejar certificações específicas de produção e modelagem, como as CMM – Capability Maturity Model (dividido em níveis) e o SPICE – Software Process Improvement and Capability Determination, desconhecidos, respectivamente, para 71% e 81% das empresas, segundo a mesma pesquisa do MCT. A utilização de modelos externos para gestão e avaliação da qualidade dos softwares é importante porque permite plena auditoria e melhor avaliação dos ativos da empresa.
Para uma correta estruturação do legado de softwares é fundamental que, além da adoção de padrões amplamente aceitos, como os citados, se tenha um real e efetivo conhecimento desse legado. É preciso um estudo jurídico sobre as licenças utilizadas, a validade das mesmas, a necessidade de se utilizar certos softwares e um profundo estudo de catalogação dos sistemas, respondendo às seguintes perguntas: o que pertence à empresa? O que está licenciado corretamente? O que pode ser renegociado? Existem softwares que pertencem à empresa e que estão classificados como pertencentes a terceiros?
Portanto, toda empresa que já possui um legado insuficientemente mapeado deveria, antes de iniciar uma das certificações internacionais, realizar um estudo interno aprofundado, buscando separar e catalogar cada um dos softwares. Após tal trabalho, a busca por uma certificação de qualidade será muito mais simples e menos dispendiosa.
Os resultados, se comparados desde o início com os departamentos financeiro e de contabilidade poderão ser sentidos em muito pouco tempo.
Revista Consultor Jurídico, 20 de Dezembro de 2004
24 de dezembro
24 de dezembro
24 de dezembro
24 de dezembro