Parecer nº 100/2016
Processo nº 1144/2015
TID 14229434
Ref.: Contratação – Software DRS Plenário– Inexigibilidade de Licitação
À Sra. Procuradora Legislativa Supervisora
O presente processo foi encaminhado por SGA a fls. 50 para análise referente à possibilidade de contratação por inexigibilidade de licitação da atual contratada xxxxxxxxxxx ou caso não seja possível verificar a possibilidade da prorrogação excepcional por 90 dias. Deste modo, esta Procuradoria passará a análise da possibilidade da presente contratação se atentando apenas aos aspectos jurídicos do caso.
É importante que seja feito um histórico da presente contratação para que se vislumbre o panorama atual e possibilitar a análise da questão do ponto de vista jurídico, conforme se verifica a seguir.
Em reunião ocorrida em janeiro de 2007 com a Mesa Diretora, o Secretário à época, ao tratar da precariedade dos recursos tecnológicos à disposição da Unidade de SGP.4- Secretaria de Registro Parlamentar e Revisão, recebeu autorização para apresentar proposta de modernização dos serviços de Taquigrafia.
Além disso, a Unidade informa que com o advento do Concurso nº 01/2007 haveria, ainda, em 2007, a nomeação de 10 novos taquígrafos e 02 taquígrafos-revisores, além de mais técnicos administrativos para o setor, o que ocasionaria o aumento do quadro efetivo do setor supramencionado cf. se observa justificativa encontra a fls. 05 do PA nº 936/2007.
A Unidade buscava superar a situação precária e provisória em que se realizava o processo de elaboração das notas taquigráficas na CMSP. A Unidade entendia que seria urgente e necessária a informatização dos processos e fluxos de trabalho dando-lhes mais eficiência, produtividade e qualidade cf. Memo. SGP.4 nº 024/07 a fls. 09/13 do mesmo PA.
Este memorando apresentou a proposta de modernização, apresentando o Sistema Integrado do Registro Taquigráfico que descreveu as características gerais do workflow informatizado de gerenciamento da elaboração, armazenamento, controle, publicação e consultas das notas taquigráficas, constituído de módulos operacionais, autônomos e interdependentes (PA 936/2007 a fls. 11).
Este sistema integrado teve os seguintes módulos: módulo registro e revisão, módulo apoio operacional, módulo áudio, módulo publicação e módulo administração.
A Unidade solicitou no memorando que de forma pioneira se realizasse a integração e a plena compatibilidade do módulo registro e revisão com software de reconhecimento de voz para permitir a substituição gradual da digitação pelo ditado na elaboração das notas taquigráficas.
Outra questão abordada no mesmo memorando é a possibilidade de publicação da íntegra das atas das sessões plenárias, conforme já realizado pela Câmara dos Deputados, Senado Federal e Assembleia Legislativa do Estado de São Paulo.
Em 16/08/2007 houve a manifestação do sr. Coordenador do CTI a fls. 15 do (PA nº 936/2007) esta informou que com a descrição fornecida seria possível iniciar a prospecção do mercado em busca de propostas compatíveis, e em seguida apresentam algumas sugestões de empresas para realização da pesquisa de mercado.
Em 04 de outubro de 2007 SGA. 22 a fls. 47 apresentou a pesquisa de preços com as empresas xxxxxxxxxx, xxxxxxxxxxxxxxx e xxxxxxxxxxxx com o preço médio no valor de R$ 290.756,00.
Por meio da Decisão nº 63/2007, a Mesa Diretora da CMSP em 17/10/2007 autorizou a abertura de procedimento licitatório na modalidade Pregão, visando à contratação de empresa para execução de serviços especializados na elaboração de software para modelagem do processo de trabalho de registro de notas taquigráficas (fls. 52 PA nº 936/2007).
Conforme informação do Anexo I- do Termo de Referência – Especificações Técnicas a folhas 278 e seguintes do PA nº 936/2007 o objeto licitado foi o seguinte:
1. Desenvolvimento de software, passível de constante atualização e expansão das funcionalidades, para automação do fluxo de trabalho da Secretaria, a ser operado por todos os usuários do Sistema de Registro Taquigráfico, que será constituído de módulos operacionais, autônomos e interdependentes, com interface visual padronizada, com menus no idioma Português, com níveis de permissão de acesso de acordo com a estrutura hierárquica e natureza do fluxo automatizado e com as funcionalidades mínimas abaixo descritas.
2. Módulo Taquigrafia e Revisão: Interface para automação das notas taquigráficas na modalidade apanhamento taquigráfico presencial das sessões ordinária e extraordinária, operada pela Equipe de Taquigrafia e Revisão – SGP.41, contendo:
• Integração com processador de texto Word;
• Integração com software de reconhecimento de voz;
• Cadastro, pelo taquígrafo, das informações identificadoras de cada texto parcial (rodízio) e do status de cada discurso taquigrafado (início, fim, ambos ou continuação), possibilitando montagem automática pelo sistema e rápida localização;
• Redação e primeira revisão do texto de rodízio de apanhamento (taquigrafo);
• Concatenação e revisão dos textos de rodízio, transformando-os em texto final, (taquígrafo-revisor),
• Elaboração do resumo das sessões a partir do respectivo texto final (taquígrafo-revisor);
• Armazenamento automático de todos os textos elaborados;
• Controle gerencial de pendências.
3. Módulo Transcrição:
Interface para automação das rotinas de elaboração e finalização do texto das notas taquigráficas, na modalidade transcrição taquigráfica de reuniões e eventos gravados, operada pela Equipe de Taquigrafia e Revisão- SGP.41, contendo:
• Integração com processador de texto Word;
• Integração com software de reconhecimento de voz;
• Cadastro, pelo taquígrafo, das informações identificadoras de cada tarefa de transcrição;
• Redação e primeira revisão do texto de tarefa de transcrição (taquígrafo);
• Concatenação e conferência do texto de tarefa transcritos, transformando-os em texto conferido (taquígrafo revisor);
• Armazenamento automático de todos os textos elaborados;
• Controle gerencial de pendências.
4. Módulo Apoio
Interface para automação das rotinas complementares de apoio ao apanhamento taquigráfico e à transcrição, operada pela Unidade Administrativa de Apoio ‘Operacional – SGA. 43, contendo:
• Integração com processador de texto Word;
• Cadastro das sessões e das reuniões e eventos, conforme agenda diária;
• Cadastro da tabela dos taquígrafos e taquígrafos-revisores, da escala de apanhamento taquigráfico e da escala de distribuição de reuniões e eventos gravados;
• Elaboração de capas para os textos conferidos das reuniões e eventos transcritos;
• Montagem de arquivos eletrônicos de discursos, dos textos finais e dos textos conferidos;
• Controle dos parâmetros de montagem automática de discursos, dos textos finais e dos textos conferidos;
• Armazenamento automático de todos os textos elaborados;
• Impressão de arquivos eletrônicos armazenados;
• Controle gerencial de pendências.
5. Módulo Banco de Dados
Interface para gerenciar o armazenamento e a pesquisa, em servidor de rede, de todos textos produzidos no sistema, operada pela Equipe de Publicação – SGA -42 e pela Unidade Administrativa de Apoio Operacional
• Armazenamento dos arquivos eletrônicos, entre outros, das bases:
• Texto fiel dos apanhamentos
• Texto finais dos apanhamentos com e sem alterações controladas,
• Texto fiel das transcrições,
• Texto conferido das transcrições com e sem alterações controladas,
• Texto fiel das transcrições
• Texto conferido das transcrições com e sem alterações controladas,
• Texto do resumo e respectivos índices,
• Texto editado da ata provisória,
• Texto editado da ata definitiva,
• Texto dos anais e respectivos índices,
• Texto dos projetos publicados e dos projetos aguardando publicação,
• Texto dos ofícios e documentos digitados,
• Texto dos relatórios gerados,
• Arquivos eletrônicos de áudio gravados e/ou editados;
• Elaboração de relatórios estatísticos das bases armazenadas;
• Elaboração de relatórios gerenciais da produção textual por funcionário, setor, tipo de texto ou período, ou consolidados,
• Elaboração de índice das bases resumo e anais,
• Pesquisa e localização imediata, mediante palavra-chave ou outros parâmetros, de conteúdo nos arquivos eletrônicos dos textos finais e dos resumos armazenados;
• Disponibilização, via intranet, das atas (provisória e definitiva), dos anais, do resumo das sessões e dos projetos publicados,
• Backup automático em servidor local,
• Impressão de arquivos eletrônicos armazenados.
6. Módulo Áudio
Interface para automação da operação do áudio de suporte, em servidor local, operada pela Unidade Administrativa de Apoio Operacional – SGP.43, contendo:
• Gravação e particionamento com sobreposição em tempo real, por período de tempo, de arquivos de áudio a partir do sinal de áudio disponível na Secretaria,
• Edição digital (recorte, volume, redução de ruído, etc) e particionamento com sobreposição, por período de tempo ou por partes iguais, de arquivos de áudio das reuniões e eventos,
• Disponibilização e distribuição on-line, conforme escala, dos arquivos de áudio,
• Acesso on-line aos arquivos de áudio apenas pelos usuários autorizados,
• Operação das funções básica de áudio (reproduzir, parar, avanço, retrocesso, autobackstep, etc) simultaneamente com a operação dos módulos Taquigrafia e Revisão e Transcrição,
• Controle gerencial de pendências.
7. Módulo Publicação
Interface para automação das rotinas de publicação e edição, operada pela Equipe de Publicação – SGP.42, contendo:
• Integração com processador de texto Word;
• Integração com o sistema de envio de arquivos eletrônicos para Imesp (PUBNET),
• Edição dos textos finais em atas e anais
• Armazenamento automático de todos os textos elaborados,
• Impressão de arquivos eletrônicos armazenados
• Controle gerencial de pendências.
8. Módulo Administração
Interface integrada a todo o sistema para supervisão e intervenção, em tempo real e de acordo com os níveis de permissão de acesso, na operação dos módulos, permitindo rápida identificação de problemas e todas de decisão quanto à:
• Tabela dos taquígrafos e taquígrafos-revisores,
• Escala de distribuição dos arquivos de áudio das sessões plenárias,
• Escala de distribuição dos arquivos de áudio das reuniões e eventos,
• Definição de prioridades de transcrição,
• Disponibilização de textos armazenados no banco de dados,
• Disponibilização, via intranet, das atas (provisória e definitiva), dos anais, do resumo das sessões e dos projetos publicados.
9. Dos Padrões de Compatibilidade
• Quanto ao sistema operacional, o sistema deverá ser compatível com o ambiente Active Diretory do Windows server 2003.
• Quanto aos arquivos de texto, todos os módulos do sistema deverão ser compatíveis com os formatos MS Office XP/2003, Adobe PDF/A, XML e OpenDoc.
• Quanto ao armazenamento, o sistema deverá ser compatível com o banco de dados SGBD MS-SQL Server 2005 para servidor de rede, programa em uso na Contratante. Caberá à Contratada a criação e o suporte de manutenção das respectivas tabelas do sistema.
• Quanto aos arquivos de áudio, o sistema deverá ser compatível com formato MP3.
10. Das aplicações não desenvolvidas pela Contratada.
As aplicações e respectivas funcionalidades incorporadas ao software pela Contratada, de natureza Software Development Kit, são parte integrante do Sistema de Registro Taquigráfico, dele sendo inseparáveis, e estão sujeitas às mesmas condições desta licitação.
A sessão do Pregão nº 02/2008 que teve por objeto a contração dos serviços supramencionados se deu em 04 de março de 2008, sendo que a empresa xxxxxxxxxxxx, sagrou-se vencedora do certame cf. Ata de Reunião nº 41/2008 a fls. 509 a 511 do Volume III do Processo nº 936/2007.
O contrato nº 19/2008 proveniente do Pregão nº 02/2008 a fls. 540 a 551 do Vol III do Processo nº 936/2007 foi assinado pela Egrégia Mesa Diretora da Câmara Municipal de São Paulo em 26 de março de 2008, iniciando os serviços em 02 de abril de 2008, cf. ordem de início a fls. 557 do volume III.
Verifica-se que foi apresentado um Relatório de Acompanhamento – Etapa-2 pela Contratada a fls. 563/564 do volume III do processo nº 936/2007 que apresentou o cronograma Físico- Financeiro, bem como a descrição das atividades a qual se retira a seguinte observação importante:
“(…)
A tarefa de desenvolvimento de software engloba uma série de fases e atividades que independentemente da metodologia escolhida, ocorrem para realização do seu objetivo maior: entregar software funcionando de acordo com as necessidades do cliente.
Para atingir os objetivos do projeto, todas as atividades de desenvolvimento têm que ser criteriosamente elaboradas e desenvolvidas, usando uma abordagem de desenvolvimento rica em detalhes. Assim sendo, encontraremos com maior ou menor rigor e formalização, atividades de análise de requisitos, definição de arquitetura, codificação e outras. Um trabalho consistente de análise dos requisitos, ou seja, identificar, quantificar, definir, priorizar e classificar os principais problemas que o futuro software deve resolver é a base de um projeto de software de sucesso”.
(…) ”.
Em seguida foi apresentado o Projeto xxxxxxxxxxxx – CM – SP com a Especificação de Requisitos de Software MPS.BR/PDK 3.1. Versão 1.0 a fls. 573 a 592 do Vol. III do Processo 936/2007.
Em 29 de agosto de 2008 a Contratada fez a solicitação de Aditivo afls. 624 a 627, juntamente com o Reposicionamento do Cronograma Físico-Financeiro alegando que:
” Em comum acordo com o Gestor do projeto , xxxxxxxxxxxxxxxxxxxxxxxxxxxx, foi privilegiada a atividade Levantamento de Requisitos, da etapa 2 do cronograma físico-financeiro, que é necessária para a geração de documento ERS (Especificação de Requisitos de Software), ocasionado um incremento de mais de 60 dias nesta análise. Esta atividade estava prevista para menos de 30 dias no cronograma físico-financeiro firmado entre as partes
(…)
A atividade de levantamento de requisitos é de fundamental importância para que se construa o software certo, ou seja, é necessário antes de mais nada que os envolvidos no projeto de software saibam, exatamente o que é esperado do aplicativo a ser construído. É muito importante também que todos os envolvidos saibam igualmente o que o software não fará. (…)
(…)
Diante do prolongamento dos prazos da análise de requisitos e do incremento dos requisitos aprovados nos documentos ERS, e consequente ampliação quantitativa do objeto contratado, solicito baseado nos artigos nº 57 § 1º e nº 65, §1º da Lei nº 8.666, de 21 de junho de 1993, prorrogação do prazo de execução conforme marcos do projeto abaixo especificados e acréscimo de 25% do valor do contrato firmado entre as partes, totalizando acréscimo de R$37.500,00 (trinta e sete mil e quinhentos reais), com a contratada ficando responsável pela absorção de 6,2% do custo adicional, que somados aos 25% solicitados totalizam os 31,2% de acréscimo no custo de desenvolvimento do sistema, conforme Anexo I”.
(…)
Em seguida SGA encaminhou o presente pedido para análise da Procuradoria para análise viabilidade jurídica do Aditamento. O Parecer Jurídico a fls. 640/641 da lavra da Dra. Maria Nazaré Lins Barbosa na qual se separou trechos relevantes:
“(…) Nesse sentido, vê oportuna a realização de termo de aditamento ao contrato, com a finalidade de acrescer o objeto e o prazo de execução, tendo em conta ajustes técnicos que se estimaram convenientes durante a execução do projeto.
(…)
Observo, todavia, que o prazo final de execução dos serviços, conforme reposicionamento do cronograma físico-financeiro proposto pela Contratada expira em 31.03.2009. Todavia, o prazo de vigência contratual, conforme cláusula 8.1, encerra-se em 26.03.2009.
Deste modo, parece-me oportuno – se tecnicamente viável – prorrogar o prazo de execução dos serviços tão somente até o prazo de vigência do ajuste, a fim de prevenir eventual solução de continuidade ou necessidade de novo aditamento em função de poucos dias. Solicitei para tanto o aval do setor competente, que não viu óbice a esta solução. Como a cláusula 3.1.1. do contrato prevê a obrigação de a contratante apresentar cronograma físico-financeiro em até 5 dias úteis após a assinatura do contrato, sugeri cláusula análoga em relação à assinatura do termo de que ora se cogita
(…)
Assim foi assinado o 1º Termo de Aditamento ao Contrato nº 19/2008 em 29 de outubro de 2008, para alterar o Cronograma Físico-Financeiro dos serviços e alterar o valor do contrato original acrescendo o valor em R$ 37.500,00 (trinta e sete mil, e quinhentos reais) que representa 25% do valor total a fls. 658/659 do Vol. III do Processo nº 936/2008.
Em 22 de janeiro de 2009 o senhor gestor xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx solicitou “a prorrogação da vigência deste Contrato, conforme cláusula 8.1., por novo período de 12 meses, em especial para atender, durante sua vigência, o período de garantia do SISTEMA” cf. fls. 672. Tal solicitação foi analisada no Parecer nº36/2009 da lavra Dr. Manoel José Anido Filho, em 03 de fevereiro de 2009 a fls. 674, a qual foi assinado em 05 de março de 2009 a fls. 690/691 do Vol. IV do Processo 936/2007, prorrogando o prazo de vigência por mais 12 meses,
Após houve questionamento de SGA.24 a fls. 693, referente ao prazo de vigência do Contrato nº19/2008, bem como se há necessidade de prorrogação do seu prazo da execução. Em resposta, no Parecer nº 104/2009 da lavra do mesmo Procurador, a fls. 695 essa Procuradoria entendeu que a vigência máxima deve se dar por 48 meses, já quanto ao prazo da execução, a resposta foi que havia necessidade de novo TA para prorrogar a execução contratual.
Desse modo, depois de consultada a Contratada assentiu a fls. 707 do Vol. IV do Processo nº 936/2007 na prorrogação não onerosa do contrato a título de garantia, pelo período de 12 meses. O Gestor, a fls. 708 do mesmo processo, manifesta interesse na continuidade dos serviços prestados pela Contratada, tendo em vista a continuidade do desenvolvimento e fornecimento das atualizações corretivas do Sistema. Em seguida, a fls. 710, se encontra o parecer nº 936/07 da lavra da Dra. Maria Nazaré Lins Barbosa quanto à legalidade da prorrogação. Em 25 de fevereiro de 2010 foi assinado o 3º Termo de Aditamento ao Contrato nº 19/2008 com objeto supramencionado.
Em 19/11/2010 foi aberto um novo PA de nº 1192/2010 com objetivo de contratação de empresa especializada para execução de serviços de manutenção, suporte técnico, atualização de versões e desenvolvimento de novas funcionalidades do software DRS Plenário, sistema utilizado pela Secretaria de Registro Parlamentar e Revisão – SGP.4 .
Foi apresentada como justificativa por SGP.4 a fls. 02/03 do Vol. I do PA nº 1192/2010 desta nova contratação o fato de ser necessário que a operação do sistema não sofresse solução de continuidade como também acompanhasse as evoluções dos sistemas operacionais e a implantação de novas tecnologias na estrutura do Centro de Tecnologia de Informação. Além disso, a Unidade Gestora entendia que era imprescindível que na nova contratação os serviços de manutenção, atualização de versões e suporte técnico deveriam ser realizados presencialmente, por telefone, por email ou conexão remota.
O novo contrato deveria permitir a execução de serviços adicionais de desenvolvimento de novas funcionalidades decorrentes da evolução dos serviços prestados incluindo assessoria e consultoria, e de assessoria técnica operacional, contratados em sistema de banco de horas, sem compromisso mínimo de utilização. Observa-se que existia solicitação de que houvesse previsão no Contrato de alocar um técnico nas dependências de SGP.4 para realizar atividades operacionais relacionadas ao sistema, mas não cobertas pelo suporte técnico. Esse técnico permaneceria presente por um período de 03 horas nos dias de sessão plenária.
Na pesquisa de mercado, verificou-se que é comum que as empresas realizem o desenvolvimento e a implantação, operem e deem manutenção nos sistemas desenvolvidos por elas próprias, cf informações a fls. 43/48, fato já verificado no processo 42/2010.
Em 21/02/2011 foi autorizada pela Mesa Diretora por meio da Decisão de Mesa nº 1023/2011 a fls. 63 a abertura de procedimento licitatório, na modalidade Pregão para contratação do objeto supramencionado. A sessão de pregão nº 06/2011 foi realizada em 31/03/2011 em que a única empresa presente foi xxxxxxxxxxxxxx, cf. fls. 158 que se sagrou vencedora, foi habilitada, tendo o objeto adjudicado pelo valor de R$ 170.715,00 cf. fls. 190 e 208, firmando o TC nº 17/2011.
O Termo de Referência da nova contratação a fls. 133/137 do volume I do processo nº 1192/2010, que é a contratação atualmente vigente, continha a seguinte descrição dos serviços:
1. Manutenção, Atualização de Versões e Suporte Técnico.
1.1 Atividades mensais de manutenção, atualização de versões e suporte técnico do software DRS – Plenário, incluindo serviço de help-desk. Estão incluídos todos os custos de testes e adequações.
1.1.1. Os serviços de manutenção e de suporte técnico serão prestados por meio de telefone, software e assistência remota e, sempre que necessário, visita de técnicos à sede da Contratante.
1.1.2. Os serviços de manutenção e atualização de versões compreendem:
1.1.2.1. Verificação de problemas na operação do software e desenvolvimento e instalação de atualizações corretivas;
1.1.2.2. Desenvolvimento, instalação, configuração e treinamento na implantação de releases, upgrades, updates e novas versões relacionadas à evolução do software;
1.1.2.3. Desenvolvimento e instalação de atualizações necessárias à adaptação do software a mudanças do processo de trabalho da Secretaria parlamentar de Registro e Revisão decorrentes de alteração legal;
1.1.2.4. Treinamento, capacitação e reciclagem dos usuários dos softwares em relação às atualizações implantadas;
1.1.2.5. Levantamento e validação de requisitos das atualizações, analistas de negócios, DBA, gerente de projetos, analistas de sistemas, equipe de programação, ambiente de teste e homologação e ferramentas de apoio, bem como todas as despesas indiretas, inclusive deslocamentos de técnicos para levantamentos presenciais, trabalhos de apoio ou operação assistida, e de instrutores.
.
1.1.3 Os serviços de suporte técnico e help-desk compreendem:
1.1.3.1 Atendimento telefônico ou por e-mail em até 2 (duas) horas após a abertura de chamado;
1.1.3.2 Atendimento no local em até 24 (vinte quatro) horas após a abertura de chamado, com solução do problema em até 3 (três) dias úteis, salvo justificativa aceita pela Contratante.
1.1.3.3 Estrutura de suporte técnico disponível por telefone, com serviço 0800, e-mail e visita presencial de técnicos da contratada, das 8h às 18h, de segunda a sexta-feira.
2. Desenvolvimento de Novas Funcionalidades
2.1. Atividades adicionais de: (1) desenvolvimento de novas funcionalidades, incluindo assessoria e consultoria e (2) assessoria técnica operacional para o software DRS- Plenário, limitas respectivamente a 450 e 180 horas anuais, realizadas em regime de banco de horas, sem compromisso mínimo de utilização, prestadas mediante solicitação, avaliação e autorização prévia da Contratante. Estão incluídos todos os custos de testes e adequações.
2.1.1. A Atividade de desenvolvimento de novas funcionalidades, incluindo assessoria e consultoria, compreende os serviços de levantamento e validação de requisitos das novas funcionalidades, analistas de negócios, DBA, gerente de projetos, analistas de sistemas, equipe de programação, ambiente de teste e homologação, ferramentas de apoio, instalação, configuração e treinamento, bem como de todas as despesas indiretas, inclusive deslocamentos de técnicos para levantamentos presencias, trabalhos de apoio ou operação assistida, e de instrutores.
2.1.2. A atividade de assessoria técnica operacional compreende serviços operacionais relacionados à operação do software não cobertas pelo suporte técnico e realizados localmente por funcionário da Contratada.
2.1.3. A atividade de assessoria técnica operacional compreende, ainda, disponibilização de 01 (um) técnico nas dependências de SGP-4 por um período mínimo de 03 (três) horas, nos dias de sessão plenária de acordo com planejamento realizado por SGP-4 previamente autorizado pela Câmara Municipal de São Paulo.
3. Documentação Técnica
3.1. A contratada fica obrigada, no interesse público, a depositar documentação técnica, em formato digital gravados em mídia ótica, que inclua o código-fonte, descrição de funcionalidades e procedures do banco de dados, modelagem lógica e física de dados de desenvolvimento das novas funcionalidades para o software DRS – Plenário junta à autoridade brasileira que controla a propriedade intelectual de software, cedendo à Câmara Municipal de São Paulo o direito de, unicamente nas hipóteses de desconstituição da Contratada ou descontinuidade imprevista de prestação de serviços de manutenção e suporte técnico em que fique demonstrado o descumprimento das obrigações contratuais por omissão ou culpa desta, fazer uso de tais itens para garantir a continuidade de suas atividades com a utilização do referido software.
4. Software DRS – Plenário
4.1. Para correta compreensão dos serviços, o sistema em referência corresponde ao desenvolvimento de software DRS – Plenário, elaborado pela empresa xxxxxxxxxxxx. Que foi contratada através do Pregão 02/08, para automação do fluxo de trabalho da Secretaria de Registro e Revisão – SGP.4, instalado e em pleno uso na Câmara Municipal de São Paulo
Em 21/03/2012 foi solicitada pela Secretaria SGP 4 a fls. 262 do Vol. II do Processo nº 1192/2010. Isto se faz necessário em virtude de terem sido consumidas todas as horas previstas para o serviço de assessoria técnica operacional. Assim, o setor solicitou que fosse incluída cláusula contratual por meio de Termo Aditivo ao Contrato que permitisse a conversão das horas de desenvolvimento em manutenção e vice-versa, o que passou por análise jurídica no Parecer nº 75/2012 a fls. 267 da lavra da Dra. Conceição Faria da Silva , sendo firmado novo TA em 09 de abril de 2011 cf. fls. 289/290 do mesmo PA.
Verifica-se, ainda, por meio de análise do PA nº 1144/2015, que foram firmados mais quatro TA com intuito de aumentar o quantitativo contratual no que tange aos valores referentes aos serviços prestados como assessoria técnica operacional e saldo de desenvolvimento de novas funcionalidades, cf. se vislumbra no 2º TA (25/04/2012) a fls. 10/12, no 3º TA (19/04/2013)a fls. 13 /14, 4º TA (09/04/2014) a fls. 15/16, 1º Apostilamento ao 4º TA (14/10/2014) a fls. 17 e 5º TA a fls. 18/20 (14/04/2015) todas do PA nº 1144/2015.
Verifica-se que a contratação atual TC nº 17/2011 foi realizada em 28 de abril de 2011 e alcançará o período de 60 (sessenta meses) em 28 de abril de 2016, conforme informações contidas no PA nº1144/2015 a fls. 21.
Consultado sobre a contratação SGP. 4 a fls. 30 e 30 v. a Unidade informou que há necessidade de continuidade da prestação de serviços porque o software DRS- Plenário é um sistema informatizado complexo que realiza de maneira personalizada as necessidades da CMSP o fluxo do registro taquigráfico da SGP.4, devendo evitar soluções de continuidade na sua utilização. Além disso, são solicitadas outras alterações na atual contratação, permitindo que sejam realizados serviços para todos os dias úteis, com execução de ao menos 03 horas diárias, em dias úteis, e aumento de 50% na carga horária para desenvolvimento de novas funcionalidades. Informa, ainda, que a empresa presta serviço a contento e que não houve aplicação de penalidade à Contratada.
A fls. 46/48, o CTI -3 se manifesta referente à atual contratação, verificando as seguintes vantagens:
a) O sistema foi customizado para atender ao fluxo de trabalho específico de SGP-4;
b) Os cerca de 40 usuários se encontram adequadamente treinados;
c) O software já atingiu bom grau de maturidade (software sem vícios – debugado);
d) Os custos de desenvolvimento de funcionalidades específicas (customização), implantação e treinamento já foram realizados;
e) Pesquisa realizada pelo CTI-3 apontou que os principais órgãos legislativos de estrutura semelhante ao da CMSP usam solução própria ou utilizam software da atual Contratada.
Ainda informa que a atual Contratada é a única detentora dos direito autorais sobre o código-fonte do software DRS-Plenário cf. protocolo BR 5120130007739 no INPI. A empresa, após questionada, informou que não tem interesse em possibilitar a manutenção do software DRS-Plenário por terceiros, mas é possível a negociação quanto à venda do código-fonte.
Em continuação, pondera que a solução mais adequada seria a “dispensa de licitação nos termos da lei nº 8.666/93”. A segunda melhor alternativa seria licitar novamente a contratação de um sistema completo, de maneira semelhante ao que se deu no PA nº 936/2007, incluindo cláusulas contratuais tratando de licenciamento permanente, da cessão de direitos de uso de código-fonte por parte da CMSP.
Outrossim, sugere que caso seja adotada a segunda opção que seja feita uma prorrogação por 90 dias para elaboração em conjunto pelo CTI e SGP.4 do novo termo de referência atualizado para esta alternativa a fls. 30/30 v.
Informa, ainda, que, a base de dados do sistema está hospedada nos servidores da CMSP. Quanto ao Termo de Referência foram feitos ajustes no banco de horas, conforme solicitação de SGP.4 referente à assessoria técnica operacional, considerando ao menos 03 horas por dia útil, totalizando 780 horas anuais aproximadamente. O CTI sugere que seja ampliado para 1140 horas anuais, tendo em vista que não há compromisso em utilizar estas horas.
E finalmente, sugere que devam ser feitos aperfeiçoamentos no módulo de publicação, na internet e intranet do sistema, as quais objetivam melhorar a experiência de uso em dispositivos móveis, estatísticas detalhadas de acesso, promover dados em formato aberto e melhorar os serviços de sincronia das transcrições na intranet e na internet e com isto sugere o aumento do banco horas para desenvolvimento de novas funcionalidades para 1040 horas. Não devendo ser alterada a cláusula de penalidades e mantendo a fiscalização no CTI e SGP-4.
Em complemento o sr. Coordenador do CTI a fls. 48 v. informa que seguindo orientação E. Mesa no sentido de ampliar a autonomia decisória concernente a utilização de softwares cuja propriedade intelectual pertença a terceiros, entende que devam ser efetivadas as ações no sentido de celebrar um contrato por inexigibilidade de licitação pelo prazo de 12 (doze) meses e paralelamente seja iniciado um novo procedimento licitatório para contratação de solução de maior independência. Não obstante, pondera que caso não seja este o interesse da Administração, que seja realizada uma prorrogação excepcional por 90 (noventa) dias para elaboração da descrição minuciosa do objeto a licitar, visando à preservação da segurança operacional de SGP-4.
Diante disso, SGA. 4 encaminhou o presente processo a SGA para que sejam consideradas as alternativas expostas a fls. 49, para avaliar qual solução deva ser adotada pela Edilidade, e solicitou posterior devolução a SGA.4 para entendimentos junto às Unidades para elaboração do Termo de Referência mais adequado à contratação pretendida. Após SGA encaminhou o presente processo para análise e manifestação, informando que a atual contratação completará 60 meses em 28/04/2016.
Este é o relatório. Passa-se a análise da questão apresentada.
Inicialmente, são importantes as soluções apontadas pelo CTI para deslinde da causa.
a) Opção por dispensa (inexigibilidade) de licitação, tendo em vista que já foram gastos aproximadamente R$ 2.000.000,00 (dois) milhões de reais nos contratos referentes ao sistema, bem como não demandaria nova capacitação da equipe interna do setor, que já se encontra adaptada com a utilização do software DRS- Plenário.
Apesar de trazer argumentos relevantes, e que devam ser ponderados, acredito que esta solução deve ser afastada. Isso porque, observa-se que não é possível utilizar o instituto da Inexigibilidade de Licitação no caso em tela, tendo em vista que a disputa inicial realizada no PA nº 936/2007 apresentou várias empresas interessadas no desenvolvimento da solução por meio do modelo Fábrica de Software, cf. se verifica no email enviado pela empresa xxxxxxxxxx a fls. 317, e xxxxxxxxxxxxxxxx. a fls. 321, bem como a lista de presença da sessão de pregão nº 02/2008 a fls.328 em que compareceram 09 (nove) empresas.
Deste modo, observa-se que não se trata de um mercado restrito, e sim um mercado em que existem empresas com capacidade para realização do objeto, fato este que por si só afastaria aplicação do art. 25 da Lei nº 8.666/93. Este é o entendimento do TCU, conforme parte de acórdão que trata de questão análoga:
(…)
Análise
8.2.12. O que é determinante para a caracterização da inexigibilidade é a inviabilidade de competição, sendo de aceitação pacífica na doutrina, consoante Márcio dos Santos Barros em Comentários sobre Licitações e Contratos Administrativo, p. 115, que a inviabilidade de competição caracteriza-se pela ausência de confronto, pela inexistência de, ao menos, dois possíveis licitantes (limitações de mercado), ou pela impraticabilidade de competição, por não ser viável ou objetiva a escolha da melhor proposta para a Administração (limitações relativas às características do objeto pretendido). Tal não se observa no caso em análise, visto que, conforme justificativa apresentada, outras empresas, além da xxxxxxxxxxxxx, cotaram preços.
8.2.13. Vale esclarecer, outrossim, que a justificativa de preço exigida no inciso III do parágrafo único do art. 26 da Lei nº 8.666/93 tem como objetivo garantir à Administração Pública, nas contratações diretas, condições de pagamento semelhantes às alcançadas pela iniciativa privada. Por diversos meios poderia a Administração obter a justificativa do preço sem desqualificar o fundamento legal adotado (art. 25, I, Lei 8.666/93): publicações em jornais (diários oficiais), recibos relativos a fornecimentos anteriores, preços registrados (comprasnet), etc. Diante do exposto, concluímos que a justificativa apresentada pelo gestor não o socorre quanto ao fato a ele imputado.
TC-020.493/2006-8 MARCOS BEMQUERER COSTA RELATOR
(…)
Destarte, no que tange a questão da economicidade, apesar de ser uma questão relevante, e sempre deva ser observada, pois algo antieconômico, em tese não atende ao interesse público, não pode ser o único argumento, em detrimento dos requisitos legais para inexigibilidade. Até mesmo porque, não é seguro que a presente contratação se for mantida a contratação nos moldes atuais represente real economia. Pois, apesar de no curto prazo representar sim uma economia, no longo prazo por ser uma contratação por prazo indefinido pode ser muito mais onerosa.
Sobre a questão é interessante a leitura de outro trecho do acórdão em questão, aplicável ao caso:
(…)
Razões de justificativa
8.2.14. Em síntese, o responsável afirma que os órgãos que adquiriram o software Extra utilizando-se do instituto do pregão e da tomada de preços (fls. 67/69, Anexo 2) foram ineficientes e antieconômicos e que o procedimento adotado pelo MTE, inexigibilidade de licitação, resultou em economia para os cofres públicos de R$ 1.650.060,00 (fl. 100), o que por si já justificaria os atos de gestão reclamados. Além disso, em termos comparativos, o preço de aquisição alcançado pelo MTE (R$ 295,80) foi 278,91 % inferior ao pago pelo TCU (R$ 1.120,83).
Análise
8.2.15. O argumento apresentado não prospera, pois que não se encontra na esfera de discricionariedade do gestor decidir pela contratação direta de fornecimento fora das hipóteses previstas na legislação e sob a alegação de que essa seria economicamente mais vantajosa para a Administração. Quem assim procede causa ofensa ao Princípio da Legalidade, sujeitando-se às sanções previstas em Lei e nos regulamentos próprios, sem prejuízo das responsabilidades civil e criminal que seu ato enseja, conforme estabelecido no art. 82 da Lei nº 8.666/93 (Acórdão 1.613/2004 – 2ª Câmara). O administrador não é o dono dos bens que administra, exercendo apenas uma função administrativa delimitada pela sua competência funcional. Não é lícito ao administrador dispor dos bens ou fazer atuar a Administração segundo seu interesse.
A considerar verdadeira a suposição do gestor quanto à economicidade da contratação procedida com a empresa xxxxxxxxxxxxx, vale ressalvar que de igual modo poderia ela ser alcançada por meio da realização do devido procedimento licitatório, visto que o mesmo não excluiria, por si só, a participação da referida empresa.
8.2.16. Vale ressaltar ainda que os preços mencionados pelo gestor tratam de objetos distintos, vez que a licitação do TCU compreendia a contratação de aquisição de licenças e serviço de suporte técnico e atualização de versões (fl. 9) e a licitação do MTE somente a aquisição de licenças, sem manutenção e suporte técnico (f. 138). Diante do exposto, refutamos o argumento apresentado pelo responsável.
(…)
TC-020.493/2006-8 MARCOS BEMQUERER COSTA RELATOR
Deste modo, s.m.j,, afastada a primeira solução apresentada, passa-se à outra opção apresentado pelo Sr. Coordenador do CTI:
b) Contrato por meio de Inexigibilidade de licitação pelo prazo de 12 (doze) meses e paralelamente seja iniciado um processo para nova contratação para contratar solução de maior independência.
Começa-se a análise pelo fim. Realmente, o caminho é se buscar uma solução de informática que contemple maior independência perante os seus desenvolvedores, e para tanto há necessidade premente de que seja elaborado um Termo de Referência que tenha o escopo de garantir que esta Edilidade seja detentora do código-fonte.
Código-fonte (source code em inglês) é o conjunto de palavras ou símbolos escritos de forma ordenada, contendo instruções em uma das linguagens de programação existentes, de maneira lógica. Existem linguagens que são compiladas e as que são interpretadas. As linguagens compiladas, após ser compilado o código fonte, transformam-se em software, ou seja, programas executáveis. Este conjunto de palavras que formam linhas de comandos deverá estar dentro da padronização da linguagem escolhida, obedecendo critérios de execução. Atualmente, com a diversificação de linguagens, o código pode ser escrito de forma totalmente modular, podendo um mesmo conjunto de códigos ser compartilhado por diversos programas e, até mesmo, linguagens. (fonte: Wikipedia: https://pt.wikipedia.org/wiki/Código-fonte)
E ainda por sua importância, o “código-fonte” é o objeto central da proteção da legislação que disciplina a propriedade intelectual dos softwares em geral. Empresas de softwares comerciais guardam com muito cuidado o “código-fonte” de seus programas, pois se os seus rivais tiverem acesso a ele poderiam copiá-lo facilmente.
O código-fonte é vital para as organizações, sendo o responsável pelo atendimento das regras de operação e funcionamento dos sistemas. Apesar do constante esforço em melhoria de processos (ISO, CMM, ITIL, COBIT), a construção do código-fonte normalmente é artesanal. Deste modo, a empresa que o realiza tem grande interesse em que sua realização seja mantida acobertada pela proteção do direito autoral.
Contudo é importante verificar que na primeira contratação, não houve ressalva que a CMSP não seria detentora do programa desenvolvido pela contratada nos termos do art. 4º da Lei 9609/98:
Art. 4º Salvo estipulação em contrário, pertencerão exclusivamente ao empregador, contratante de serviços ou órgão público, os direitos relativos ao programa de computador, desenvolvido e elaborado durante a vigência de contrato ou de vínculo estatutário, expressamente destinado à pesquisa e desenvolvimento, ou em que a atividade do empregado, contratado de serviço ou servidor seja prevista, ou ainda, que decorra da própria natureza dos encargos concernentes a esses vínculos.
Conforme conceito extraído do site Wikipedia, o termo “fábrica de software” nasceu da adoção do conceito de fábrica tradicional ao processo de desenvolvimento de sistemas e aplicações, ou seja, fábrica de software é a estrutura formada pelo conjunto de profissionais, recursos materiais, processos e metodologias para o desenvolvimento de softwares, sistemas e aplicações, englobando desde a análise de requisitos até a fase de manutenção.
O modelo “fábrica de software” é o previsto no art. 4º da Lei federal nº 9609/98 em que o contratante, após o pagamento do valor pela elaboração do software, fica detentor do seu código-fonte, podendo fazer as alterações que entenda necessárias ou autorizar que terceiros as façam, sem que sejam devidos valores pela licença de uso do direito autoral após o pagamento integral da contraprestação referente ao serviço intelectual de desenvolvimento.
Inclusive, sobre esta questão a Procuradoria questionou o CTI a fls. 51, referente a não existência de ressalva ou estipulação em contrário à propriedade dos direitos relativos ao software desenvolvido no curso do contrato nº 19/2008 proveniente do Pregão nº 02/2008 a fls. 540 a 551 do Vol. III do Processo nº 936/2007.
Em resposta, o CTI apresentou a sua resposta juntamente com a manifestação da empresa com documentação de Registro no Processo: BR 51 2013 000773-9 a fls. 59/63 v.
É importante verificar que a argumentação da empresa a fls. 59 v., ” informa que o software pelo tempo e o orçamento disposto no edital tornam claro a impossibilidade da criação de uma solução tecnológica nova, (…), e mais além (…) “ que a estipulação em contrário disposta no início do artigo (4º da lei nº 9.609/98) se refere a programas elaborados durante a vigência do contrato, não sendo o caso posto em análise, pois cabalmente demonstrado que o programa já existia (…).
Não obstante, a indignação da contratada, que se entende compreensível, observa-se que se encontra documentado nos autos do processo que demonstra que, apesar de ser plausível a existência de um software anterior, este fato não pode afastar o que dispõe o edital que contratou o desenvolvimento da funcionalidade. A pré-existência de um software que parcialmente atendia às necessidades da Edilidade é uma circunstância que beneficiou a contratada que queimou etapas no desenvolvimento da solução, bem como possibilitou que a Contratada realizasse uma proposta mais vantajosa à Administração. Contudo, isto não possibilita que seja afastado o que previa o edital que contratou expressamente o desenvolvimento de um software cf. se lê no item 2.1 do Termo de Referência – Anexo I do Edital.
O edital faz lei entre as partes, e não pode ser afastado pois se trata de uma segurança para o licitante e para o interesse público, extraída do princípio do procedimento formal, que determina à Administração que observe as regras por ela própria lançadas no instrumento que convoca e rege a licitação.
Segundo Lucas Rocha Furtado, Procurador-Geral do Ministério Público junto ao Tribunal de Contas da União, o instrumento convocatório:
“é a lei do caso, aquela que irá regular a atuação tanto da administração pública quanto dos licitantes. Esse princípio é mencionado no art. 3º da Lei de Licitações, e enfatizado pelo art. 41 da mesma lei que dispõe que “a Administração não pode descumprir as normas e condições do edital, ao qual se acha estritamente vinculada”. (Curso de Direito Administrativo, 2007, p.416)”
Assim, mesmo que o software já estivesse pronto, o que não é o caso, não seria possível afastar a aplicação do art. 4º da lei nº 9.609/98, pelo princípio supramencionado. Até mesmo porque, outras empresas eventualmente deixaram de participar da licitação em virtude de ser desenvolvimento e poderiam ter interesse em participar caso se tratasse de utilização de software desenvolvido ou parcialmente desenvolvido.
Com isso, a utilização de software pronto realmente não é o caso em tela, tendo em vista, que na leitura do processo se verifica que a solução foi desenvolvida e aperfeiçoada com diversas funcionalidades no curso da contratação, conforme apresentado no Relatório de Acompanhamento – Etapa-2 pela Contratada a fls. 563/564 do volume III do processo nº 936/2007 que apresentou o cronograma Físico- Financeiro, bem como a descrição das atividades, a qual se retira a seguinte observação importante:
“(…)
A tarefa de desenvolvimento de software engloba uma série de fases e atividades que independentemente da metodologia escolhida, ocorrem para realização do seu objetivo maior: entregar software funcionando de acordo com as necessidades do cliente.
Para atingir os objetivos do projeto, todas as atividades de desenvolvimento têm que ser criteriosamente elaboradas e desenvolvidas, usando uma abordagem de desenvolvimento rica em detalhes. Assim sendo, encontraremos com maior ou menor rigor e formalização, atividades de análise de requisitos, definição de arquitetura, codificação e outras. Um trabalho consistente de análise dos requisitos, ou seja, identificar, quantificar, definir, priorizar e classificar os principais problemas que o futuro software deve resolver é a base de um projeto de software de sucesso”.
(…) ”.
Além disso, a fls. 624 a 627, juntamente com o Reposicionamento do Cronograma Físico-Financeiro alegou-se que:
” Em comum acordo com o Gestor do projeto , xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, foi privilegiada a atividade Levantamento de Requisitos, da etapa 2 do cronograma físico-financeiro, que é necessária para a geração de documento ERS (Especificação de Requisitos de Software), ocasionado um incremento de mais de 60 dias nesta análise. Esta atividade estava prevista para menos de 30 dias no cronograma físico-financeiro firmado entre as partes
(…)
A atividade de levantamento de requisitos é de fundamental importância para que se construa o software certo, ou seja, é necessário antes de mais nada que os envolvidos no projeto de software saibam, exatamente o que é esperado do aplicativo a ser construído.. (…)
(…)
Diante do prolongamento dos prazos da análise de requisitos e do incremento dos requisitos aprovados nos documentos ERS, e consequente ampliação quantitativa do objeto contratado, solicito baseado nos artigos nº 57 § 1º e nº 65, §1º da Lei nº 8.666, de 21 de junho de 1993, prorrogação do prazo de execução conforme marcos do projeto abaixo especificados e acréscimo de 25% do valor do contrato firmado entre as partes, totalizando acréscimo de R$37.500,00 (trinta e sete mil e quinhentos reais), com a contratada ficando responsável pela absorção de 6,2% do custo adicional, que somados aos 25% solicitados totalizam os 31,2% de acréscimo no custo de desenvolvimento do sistema, conforme Anexo I”.
(…)
Desse modo, entende-se que as atividades desenvolvidas na primeira contratação são de propriedade da CMSP. Fato este que possibilitará que o Termo de Referência da nova contratação, que não precisará realizar novamente às atividades já desenvolvidas na 1ª contratação, mantendo o foco nas atividades que foram desenvolvidas na 2ª Contratação e do novo Termo de Referência a fls. 30/30v.
Isso porque, na 2ª Contratação, diferentemente do 1ª Contratação, houve a ressalva expressa de que seriam de propriedade da Contratada as novas funcionalidades desenvolvidas durante o contrato cf. item 3.1 do Termo de Referência da atual Contratação:
3.1. A contratada fica obrigada, no interesse público, a depositar documentação técnica, em formato digital gravados em mídia ótica, que inclua o código-fonte, descrição de funcionalidades e procedures do banco de dados, modelagem lógica e física de dados de desenvolvimento das novas funcionalidades para o software DRS – Plenário junta à autoridade brasileira que controla a propriedade intelectual de software, cedendo à Câmara Municipal de São Paulo o direito de, unicamente nas hipóteses de desconstituição da Contratada ou descontinuidade imprevista de prestação de serviços de manutenção e suporte técnico em que fique demonstrado o descumprimento das obrigações contratuais por omissão ou culpa desta, fazer uso de tais itens para garantir a continuidade de suas atividades com a utilização do referido software.
Dessa maneira, é importante que a nova contratação, não tenha esta disposição, exigindo que a nova contratação seja no modelo open source, conforme manifestação do TCU exarado no voto a seguir:
“(omissis)
Para os órgãos e entidades visitados “in loco” e que tiveram seus contratos de sistemas SMP analisados a unidade técnica sugeriu, além da medida que descrevi no item precedente, outra recomendação, no sentido de que essas organizações públicas envidassem esforços para:
‘(…) celebrar termo aditivo a contrato vigente com a empresa xxxxxxxxxxxxx cujo objeto seja de serviços relativos ao sistema Asi, de modo a obter as funcionalidades, as informações e as providências que forem necessárias para a eventual exportação dos dados de propriedade do órgão para um formato de dados de padrão aberto, possível de ser reconhecido por outros softwares ou sistemas.” (item 247 do relatório de auditoria)
Em vez de adotar a recomendação supratranscrita, conforme sugestão da unidade técnica, entendo que o TCU deve agir de forma mais rigorosa, por meio de determinação, com a mesma linha de atuação que norteou a prolação do acórdão 2.615/2007 – Plenário. Ademais, verifico que a situação caracterizada pelo alto risco de dependência tecnológica quanto a contratos de sistema SMP atinge uma quantidade muito maior de órgãos e entidades federais que não apenas aqueles que foram visitados pela equipe de auditoria da Sefti.
Assim, proponho ao colegiado que seja autuado apartado para investigação dessa questão no âmbito de toda a APF, no qual deve ser adotada a seguinte forma de atuação:
Preliminarmente, o levantamento, via diligência, junto à SLTI/MPOG, ao CNJ e ao CNMP, de quais órgãos e entidades da APF têm contratos de SMP com cláusulas que não permitem a exportação dos dados de propriedade do órgão ou entidade para um formato de dados de padrão aberto (a exemplo daqueles que foram identificados na presente auditoria);
Em seguida, com a possibilidade do exercício do contraditório e da ampla defesa por parte das empresas cujos sistemas incorram na limitação expressa na letra “a” supra (que podem ser reconhecidas como interessadas no novo processo), determinação às organizações públicas contratantes para que exijam das contratadas, via termos aditivos aos contratos em vigor, as funcionalidades e as informações necessárias para a eventual exportação dos dados de propriedade dessas organizações para um formato de dados de padrão aberto, possível de ser reconhecido por outros softwares ou sistemas.
Desse modo, poderá o TCU contribuir para o combate à dependência tecnológica em toda a APF e não apenas nos sete órgãos e entidades que tiveram seus contratos de sistemas SMP avaliados pela Sefti).
Ademais, tal medida implica em respeito ao princípio da isonomia, pois, caso fosse adotada a recomendação sugerida pela equipe de auditoria, poderia haver tratamento mais rigoroso, sem justificativas e amparo legal, em relação à xxxxxxxxxx, que é a principal, mas não a única fornecedora de sistemas SMP para os órgãos e entidades da APF.’
(…)
A última questão de auditoria (questão 3) teve como objeto a análise da viabilidade de a Administração Pública Federal adquirir ou contratar o desenvolvimento de sistema SMP de forma centralizada e disponibilizá-lo para os órgãos e entidades interessados.
Na verdade, tratar-se-ia da aquisição ou contratação de uma solução completa de tecnologia da informação, pois, junto ao sistema SMP, passaria a ser necessária a execução de muitas outras tarefas, como o cadastramento de bens móveis (e seu emplaquetamento), imóveis e contratos; o treinamento dos atores envolvidos (gestor global da solução, responsáveis pela gestão de material e patrimônio nos órgãos e entidades, técnicos que viriam a dar suporte à solução, bem como os usuários finais), a manutenção corretiva e evolutiva, entre outras.
Após explicitar as vantagens (em maior número) e as desvantagens (em menor número, mas não menos expressivas que as vantagens) da aquisição/contratação centralizada, a unidade técnica vislumbrou diferentes possibilidades para que essa opção fosse levada a efeito (item 256 do relatório de auditoria):
Contratação de entidade pública, por dispensa/inexigibilidade, para desenvolvimento de sistema padrão de SMP e provimento dos demais serviços que componham essa solução;
Contratação de entidade privada por licitação para desenvolvimento de software padrão de SMP e provimento dos demais serviços que comporiam essa solução;
Contratação de solução de SMP do mercado que atenda às necessidades dos diversos órgãos e entidades da APF, provavelmente por licitação.
A Sefti também teceu considerações sobre as possíveis formas de execução de um sistema SMP centralizado e, em seguida, concluiu que a “adoção de uma solução de TI de forma centralizada (…) trata-se de um desafio bastante expressivo com diversos riscos” (item 259 do relatório de auditoria). Os riscos podem ser percebidos pelas diversas possibilidades de obtenção do sistema SMP e da subsequente forma de execução da solução de TI que viesse a ser adotada, sem que seja possível atestar, de antemão, se o objetivo da boa e eficiente gestão dos materiais e do patrimônio da APF seria alcançado.
Concordo com a Sefti, em outra vertente de conclusão, quando reconhece a complexidade do assunto tratado na questão 3 de auditoria e sugere que a respectiva resposta passe pela “condução de estudos técnicos preliminares, de acordo com o inciso IX do art. 6º a Lei nº 8.666/1993 e à luz da IN SLTI nº 4/2008, caso o gestor global da solução considere oportuno e conveniente conduzir esses estudos, em função das prioridades e disponibilidade de recursos daquele órgão [referindo-se à SLTI/MPOG]” (item 262 do relatório de auditoria – grifo nosso).
De fato, cabe aos órgãos competentes de cada Poder (Executivo e Judiciário, bem como o Ministério Público da União) definir se a aquisição/contratação de uma única solução de TI para desempenhar o papel de um grande sistema SMP é conveniente e oportuna, considerando suas prioridades de gestão e limitações de recursos humanos e materiais.
Pode-se cogitar, também, como alternativa à adoção de um grande sistema único e centralizado, a possibilidade de coexistirem sistemas diversos – mais flexíveis, portanto, ao atendimento de especificidades de cada órgão ou entidade contratante -, mas com supervisão centralizada e observância de protocolos de interoperabilidade.
Assim, sistemas desenvolvidos por fornecedores distintos deveriam ser capazes de compartilhar suas bases de dados (a partir de um modelo de dados previamente definido pelo gestor global da solução) e fornecer ao administrador público, especialmente o de nível decisório, uma visão ampla e precisa sobre os bens e materiais de consumo que compõem o patrimônio da União.
Preserva-se, a partir dessa alternativa, a possibilidade de a APF não ficar restrita e dependente de um fornecedor e de uma única solução de TI e, ainda, de lidar com os sistemas legados, que poderiam se integrar às novas soluções interoperáveis.
Mesmo para a realização dos estudos técnicos preliminares vislumbra-se o investimento considerável de tempo e de recursos, a fim de mobilizar os órgãos e entidades da APF na busca pela resposta requerida pela pergunta constante da parte final do item 9.3 do Acórdão nº 1.100/2008 – Plenário, que originou esta fiscalização.
De qualquer modo, caso, por hipótese, seja a adoção de uma solução centralizada de TI para SMP (ou de mais de uma solução descentralizada, desde que interoperáveis) considerada prioritária pelo governo federal (Poder Executivo e outros Poderes), há que se reconhecer a grande possibilidade de ocorrência de ganhos efetivos para a gestão e a tomada de decisão, o que justifica o aprofundamento das investigações suscitadas na questão 3 da auditoria. Ademais, poderiam os órgãos e entidades federais não mais ficar dependentes da tecnologia que hoje detêm as poucas empresas que fornecem sistemas SMP para a APF (especialmente a xxxxxxxxxxxxx).
Sistemas centralizados, como o Siafi, o Siasg e o Comprasnet, mas que permitem a entrada de dados de modo descentralizado, são bons exemplos de sistemas que se tornaram indispensáveis à gestão da contabilidade, administração e compras/contratações públicas, o que reforça a possibilidade de concretização dos ganhos que mencionei. Para a implementação inicial desses sistemas, incorreu o Estado brasileiro em riscos, esforços e gastos expressivos, com a clara expectativa de obtenção de ganhos de eficiência e economicidade futuros, que se esperam, também, para a área de sistemas SMP.
(omissis)
TCU, Sala das Sessões, em 18 de janeiro de 2012.
ACÓRDÃO Nº 54/2012 – TCU – PLENÁRIO – Relatora: ANA ARRAES”
Conclusão
Diante disso, s.m.j., entende-se que deva seguir a recomendação de licitar novamente a contratação, porém não de um sistema completo, tendo em vista que os decorrentes da contratação original de 2007-2008 (PA 936/2007; pregão 02/2008), são de propriedade da Edilidade, por força do art. 4º da lei nº 9609/98, bem como pelo Princípio da Vinculação ao Edital Convocatório, e sim apenas as funcionalidades e aperfeiçoamentos etc. surgidos ao término daquele contrato.
Há que ressaltar que, conforme orientação exarada no PA. Nº 42/2010, a nova contratação deve trazer um objeto que contemple licenciamento permanente, da cessão de direito de uso do código-fonte por parte da CMSP (possivelmente vetando a cessão para terceiros) e de trabalhos necessários à transferência tecnológica (documentação workshops etc.), como forma de preservar o investimento feito em customizações para garantir a independência de fornecedor, conforme exposto pelo Sr. Coordenador do CTI a fls. 48.v.
Finalmente, para se evitar a solução de continuidade se recomenda no período em que é elaborado o Termo de Referência para definição do objeto a ser licitado, que sejam procedidas as medidas para prorrogação por 90 dias, lembrando que a contratação deva ser concluída neste período.
Este é o Parecer que submeto à apreciação superior de V. Sa.
São Paulo, 31 de março de 2016.
Carlos Benedito Vieira Micelli
Procurador Legislativo
Setor de Contratos e Licitações
OAB/SP nº 260.308
