De que adianta modernizar aplicativos, rever as regras de negócio, se a empresa não sabe como o usuário, lá na ponta, usa as informações que lhe caem nas mãos? Essa é uma preocupação do Exército Brasileiro, e vale para exércitos, autarquias ou empresas comuns, na busca do lucro. O líder, ao modernizar aplicativos, deve também modernizar cabeças.
A mesa-redonda foi coordenada pelo diretor editorial do Informática Hoje, Wilson Moherdaui. Participaram: Alan do Nascimento Santos, coordenador-geral de TI do INSS; Clarice Copetti, vice-presidente de TI da Caixa Econômica Federal; José Antônio Eirado Neto, gerente de TI do Banco Central; José Geraldo Loureiro Rodrigues, diretor de sistemas da informação da Controladoria Geral da União; Márcio de Carvalho Victorino, tenente-coronel do Exército Brasileiro, administrador de dados corporativos e gerente de projetos de TI; Paulo Knupp Dos Santos, secretário de TI do Ministério Público Federal; e Pedro Enéas Guimarães C. Mascarenhas, diretor da subssecretaria de infraestrutura tecnológica do Prodasen (Senado Federal).

IH — Como tem sido a gestão do portfólio de aplicativos, e sua modernização?
Clarice — Temos um portfólio muito grande: temos 600 sistemas corporativos. Acho que já expirou a validade de um porcentual grande desses sistemas, por conta da tecnologia com que foram construídos. É difícil até encontrar profissionais para mantê-los.
Primeiro de tudo, eu trabalho na sustentação dos sistemas, porque o banco precisa funcionar. O banco via Internet nunca para.
Discuto muito com a equipe quais aplicativos são mais críticos, para fazer a atualização, a migração de plataformas. Também podemos optar por megassistemas, que são mais custosos, porque temos de começar um desenvolvimento do zero.
Acho que essa coisa de transformar o legado, que o mercado chama de legacy transformation, ainda é promessa.
No caso da Caixa, eu organizo um edital, tenho de consolidar bem um edital a partir de coisas ainda duvidosas, para contratar uma empresa e dizer assim: pega aqui esse sistema e me faça uma transformação, me traga o sistema para uma plataforma mais atual.
Vamos ser francos aqui: a engenharia de software, com documentação e tudo o mais, é recente, só agora está virando regra. Mas um sistema como o do FGTS acompanha o trabalhador por toda a vida dele.
Outro assunto importante é o reuso, o reaproveitamento de código. Só para sair de um modelo, o de locação de mão de obra, para o outro modelo, de contratação de serviço entregue, eu levei dois anos, com a licitação e tudo.
Depois de publicar o edital, foi um ano e meio para chegar no momento de assinar todos os contratos e aí começar uma vida nova.
Apesar disso tudo, nossos parceiros fornecedores vêm com pouquíssima inovação. Toda empresa tem coisas em comum: a segurança, o login, mas a gente está sempre começando essas coisas do zero. Não tem reuso. Acho que o reaproveitamento dessas bibliotecas de componentes é baixo.
Eirado — Quando alguém vem com uma solução de conversão de regras de negócio, é sempre uma coisa muito localizada, sempre vista de um ponto de vista muito técnico. O que nos interessa mesmo é o processo de negócios. O cara vem e diz que converte 90% do código — ele converte telas, relatórios, mas às vezes não converte aqueles 10% essenciais, ligados aos processos de negócio.
O Banco Central existe desde 1967, e então temos sistemas desde 1967. Quando a gente trata de legado, tem sempre aquele sujeito para quem o legado é muito bom, que não dá nenhum problema. Mas a questão é outra: eu preciso de gente com talento, e fica cada vez mais difícil achar gente com talento para mexer nos sistemas legados.
Outra coisa: as tecnologias se integram cada vez mais. Quando eu pego um sistema de buscas e junto com o Office para fazer um aplicativo, só consigo fazer isso com aplicativos novos, com talentos emergentes. Outro mundo é do business intelligence [análises estatísticas dos dados], que também não se interliga bem ao legado.
E tem ainda o custo: quanto custa manter um sistema legado? Cada dia mais, e os caras vão se aposentando, e eu não posso contratar ninguém no modelo body shop, porque o governo não quer. Eu preciso de gente que conheça o meu negócio, e que tenha noção de causa e efeito.
Então, quando eu converto um legado em Java, com banco de dados DB2, eu não estou tirando um legado — na verdade, eu estou contratando gente nova. Só assim eu consigo inovar.

IH — Um exemplo concreto de inovação?
Eirado — Estou instalando ferramentas de BPM, de fluxo automático de tarefas, e com isso eu mato 50% dos meus sistemas. O que eu puder resolver com workflow, com sistemas de busca, e o que eu puder resolver com sistemas de autosserviço que já existem no mercado, eu ganho.
Por exemplo: hoje eu não faço mais telas. O usuário entra num tal de reporting services e ele mesmo monta as telas dele, os relatórios dele. Assim meu analista só perde tempo com o que é essencial.
Além disso tudo, a engenharia de software está muito melhor hoje, e então a gente consegue prever as coisas melhor. Então eu prevejo que refazer um sistema legado vai levar dois anos — e o pessoal acha muito... Mas o sistema tem 30 anos! Agora, eu uso as previsões também para ver se o usuário está convicto.

Pedro — Quero ficar um pouco num âmbito mais conceitual: o legado é hardware, software, banco de dados, pessoas. Tem o aplicativo propriamente dito, o sistema propriamente dito. Tenho processos de negócio funcionando em cima desse legado. Tenho dados nesse sistema legado, e muitas vezes os dados não estão localizados em bancos de dados relacionais.
Às vezes, num sistema de 30, 40 anos, eu posso ter regras de negócio num código, e também posso ter tabelas dentro de um executável, em vez de tabelas num arquivo. Ao fazer a migração, temos de analisar: no Senado, uma vez chegamos à conclusão de que era melhor simplesmente migrar o sistema para uma plataforma mais baixa, mas sem mexer em nada. Se eu reescrevesse o sistema, a possibilidade de fracasso seria muito grande.
Nós usamos uma metodologia assim: medimos o valor para o negócio e o risco para o negócio. E aí tomamos a decisão de migrar, reescrever, modernizar — ou tolerar o sistema, e manter o sistema.
Mas tem outra coisa a respeito de modernizar os sistemas: com uma arquitetura mais flexível, os fornecedores sabem que você não depende mais só deles. Se você briga com um deles, você vai lá e espeta o sistema do concorrente, e tudo vai funcionar como estava funcionando antes.

Márcio — No Exército, temos hospitais, temos o IME, que é uma faculdade, temos a Aman, que é a academia, temos construção; a gente colabora com o PAC.
O nosso negócio é complexo. Em 2003, o general comandante de um centro de desenvolvimento de sistemas se preocupou em criar um modelo integrado. Fizemos primeiro a integração das bases de dados, depois a integração de aplicativos, e por último a fase na qual estamos agora, de integração de processos.
Para não engessar o Exército, nós classificamos os sistemas em sistemas corporativos e sistemas orgânicos. Os corporativos são aqueles que, independente da área, quando gera um dado, o dado é de interesse do Exército como um todo. O dono do dado é o Exército, mas a gente deixa o dono da área (finanças ou recursos humanos, por exemplo) como gestor do dado.
Então, se o sistema for considerado corporativo, seu modelo de dados tem de ser aprovado pela área em que eu trabalho. Se for um sistema orgânico, não é obrigatório.
Mas o que acontece? Os sistemas orgânicos usam dados do sistema corporativo, então quem desenvolve sistemas orgânicos pergunta as coisas para a gente.
Depois de integrar os dados, vimos que a gente precisava integrar os processos. Senão, a modernização viraria um perigo: quem não sabe o que quer, compra o que não precisa e ainda paga mais caro.
Mas já estamos reescrevendo coisas, encapsulando coisas com web services, comprando soluções prontas.
O comandante do Exército quer um programa de excelência gerencial, que seria a melhoria dos processos, com balanced scorecard [painéis de indicadores] para analisar a eficiência do Exército, pois ele quer o Exército trabalhando por processos.
Então nós criamos o SIG, Sistema Integrado de Gestão.
E estamos criando um banco de dados central, começando com o banco de dados de pessoal, que é a área mais crítica do Exército. Equipamentos são importantes, mas cada pessoa tem de estar habilitada, e então temos que treinar essas pessoas.
Nossa vantagem é que o IME forma 80 engenheiros por ano, dos quais uns dez são engenheiros de computação. Notamos que estamos concentrados em criar software para automatizar processos, mas não sabemos como a informação está sendo usada lá na ponta.
Por isso queremos criar uma ontologia, um consenso a respeito das definições, e aí passaremos a ver que processos mexem com essas definições. A partir daí, vamos ter repositórios com informações detalhadas e documentadas; vamos ter também uma visão consensual das coisas.
Aí poderemos usar toda a SOA, ou seja, decompor os processos em serviços reutilizáveis.
Nossos problemas são muito particulares, e eu acho que cada órgão vai ter que mergulhar internamente e aprender como a sua informação deve circular. A arquitetura da informação é independente de qualquer tecnologia: é entender como a informação flui dentro da organização.
O Exército tem problemas pelo seu tamanho, não estamos totalmente integrados. Temos mil problemas, mas pelo menos já temos o foco. E o Exército tem o poder coercitivo: quem não quer fazer, vai preso.

Alan — Na previdência, temos dois problemas: a legislação muda toda hora; é difícil um mês em que não saia alguma lei que nos obrigue a mudar as regras de negócio. E temos benefícios que duram mais de 100 anos: um sujeito se aposenta, chega aos 99 anos, se casa com a enfermeira e depois lhe deixa pensão. Então, a atualização dos nossos sistemas é complexa.
Estamos agora num processo de reengenharia de software bastante pesado. Estamos seguindo dois caminhos: um deles é redesenhar processos e trabalhar com os legados, porque reescrever nossos legados seria uma novela muito longa. O outro é se aproximar mais das pessoas, e assim melhorar a qualidade do nosso cadastro.
Nós atendemos cerca de 3,5 milhões de pessoas por mês, mas conseguimos instalar alguns atendimentos remotos, e isso em cima de sistemas muito frágeis, porque foram concebidos para uma outra realidade.
Em paralelo a tudo isso, começamos um processo de mudança do portfólio de aplicativos. Uma das iniciativas é converter uma parte das nossas bases de dados, pelo menos a menos sujeita a mudanças, como a folha de pagamento.
Nossa folha é complicada, com 27 milhões de pessoas, mas ela não representa nenhuma grande mudança conceitual.
Mas temos muitos problemas para comprar tecnologia e para contratar pessoal. Num caso extremo, levamos quase dois anos para contratar uma fábrica de software, quase quatro anos para o serviço começar a fluir bem, o que aconteceu por dois anos, até que percebemos que essa fábrica de software não conseguiria trazer tudo o que a gente precisava.
Estamos agora colocando o cadastro à disposição do público, em parceria com o Banco do Brasil e com a Caixa, para que no caixa eletrônico as pessoas possam consultar o histórico delas com a previdência, ou seja, o extrato previdenciário.

Clarice — No Internet banking.

Alan — Na Internet e nos caixas eletrônicos. Isso vai gerar uma nova onda de consultas e de atendimentos, para corrigir os erros que cada pessoa identificar. Isso gera mais acessos aos nossos sistemas.
Por exemplo, a aposentadoria em 30 minutos, que foi lançada no início do ano, aumentou em quase 20% a demanda por aposentadoria.

IH — O governo decide oferecer aposentadoria em 30 minutos, mas ele dá orçamento para a mudança?

Alan — Passamos a primeira fase desse projeto com muitas dificuldades de orçamento. Inclusive financiamos a primeira etapa com recursos internacionais, porque o nosso orçamento mal dava para a água e a luz.
Mas há quatro anos o governo resolveu lançar alguns programas para acabar com as filas, e com os resultados desses programas nós conseguimos pleitear mais recursos.
Só nos últimos dois anos, contudo, nós tivemos recursos mais ou menos compatíveis com o que deveríamos fazer.

José Geraldo — A CGU inclui a própria controladoria, uma ouvidoria, e uma parte novíssima, de prevenção e combate à corrupção, criada em 2005. Mas a própria CGU é nova; começou em 2003, o que nos dá umas vantagens e umas desvantagens.
Também temos legado, apesar disso, porque a CGU incluiu a Secretaria Federal de Controle, um órgão antigo.
Quando fizemos o sistema da CGU, tomamos o cuidado de não fazer um sistema para cada parte, mas de fazer um sistema único, o sistema de gestão das informações da CGU, com vários módulos. Como todo mundo comprou essa ideia desde o início, a administração de dados na CGU é forte; até porque os dados de auditoria ocupam muito espaço, muita infraestrutura, então era natural que ficassem centralizados. Conseguimos evitar as replicações entre bancos de dados.
Os próprios usuários conseguem desenvolver as consultas ao módulo de BI, porque instalamos ferramentas específicas para isso, e assim diminuímos a quantidade de requisições ao departamento de informática.
E também estamos trabalhando com a migração das regras de negócio. Durante esse trabalho, nos deparamos com o problema de refazer os processos de trabalho, e patinamos nesse trabalho por um ano. O pessoal não chegava a um consenso sobre qual processo seria melhor, quais regras de negócio seriam melhores.
Então resolvemos todos migrar primeiro de plataforma, ou seja, migrar as regras de negócio do jeito que estão, e adaptá-las o mínimo necessário.
É óbvio que a gente não consegue segurar 100% das modificações, porque a plataforma nova requer um certo grau de inovação. Mas a gente mede o grau de modificações, e se a gente percebe que alguém extrapolou, e que se perdeu, aí o grupo traz essa pessoa para a realidade.
A certa altura, percebemos que não tínhamos recursos próprios para tocar a implementação de processos novos, ou de regras de negócio novas. Nós poderíamos fazer um contrato guarda-chuva com alguma fábrica de software, mas eu sou contra esse tipo de contrato; além disso, esse tipo de contrato é muito acompanhado por órgãos de controle, porque as coisas se perdem ali.
Então decidimos fazer nós mesmos a especificação, os requisitos, os casos de uso, que é a parte mais complicada — até porque a CGU é um órgão novo, e os processos e regras de negócio ainda não se estabilizaram. Quando a gente fecha os casos de uso, eu monto um pregão e a gente contrata uma fábrica de software só para converter aqueles casos de uso numa linguagem qualquer. Para 2.400 pontos de função, o que não é muito, em três meses a gente montou um pregão.
Queremos replicar esse modelo em todos os projetos, porque já estabilizamos toda a arquitetura de sistemas. Hoje, a fábrica vencedora está lá, e já implementamos 1.200 pontos de função, que estamos homologando agora. Talvez a gente não consiga implementar os 2.400 pontos de função este ano, por conta das mudanças vetadas para este ano.

Paulo — O primeiro parecer do primeiro procurador-geral da República é dos idos de 1800, embora o Ministério Público, tal como é hoje, tenha nascido com a Constituição de 1988.
O Ministério Público cresceu muito, e é uma instituição que precisa de reforma estrutural, de revisão de processos. Eu assumi a secretaria de informática em 1994, com receio; quando cheguei no ministério, me vi mais na função de exorcista. A cada dia me apresentam novas entidades para fazer exorcismo, principalmente de uma coisinha chamada Mumps [uma linguagem para computadores de grande porte], que rodava em computadores Cobra.

IH — Mas o Mumps não foi erradicado junto com a caxumba [mumps, em inglês]? [risos]

Clarice — Você que pensa.

Paulo — Essa foi uma das primeiras entidades a exorcizar. Trocamos os computadores Cobra por computadores Risc. Primeiro, simplesmente portamos o código Mumps para um computador mais confiável. Depois, contamos os sistemas — 104 sistemas diferentes, com todo aquele ciúme: esse fui eu que fiz, esse é da minha procuradoria...
Existe uma palavra muito forte dentro do MPF, que é autonomia. É um dos fundamentos da instituição. Mas, por causa da autonomia, todo mundo lá diz que a história é diferente, e quando vamos levantar os requisitos e conhecer a realidade de cada local, vemos que muitas vezes a história é a mesma, de uma forma diferente. É difícil demonstrar isso.
Desde o Mumps, nós reescrevemos os aplicativos para a arquitetura cliente-servidor, depois veio a Internet e muitos desses aplicativos nasceram mortos. Por isso até hoje temos alguns sistemas funcionando com o tal de MetaFrame, para que os sistemas cliente-servidor funcionem bem via Internet.
Muita coisa mudou em 2003, quando o procurador-geral Cláudio Fonteles apoiou as iniciativas de informática: já que tudo funciona igualzinho, vamos botar um sistema para atender todo mundo. Até hoje ele é o principal fomentador desse sistema único.
Na área de TI, nosso problema principal é mão de obra. Tudo no MPF é feito em casa; na verdade temos um ERP feito em casa. Com a rotatividade, eu não consigo dar ao pessoal uma resposta mais rápida.
Mas hoje o sistema único é uma realidade, e funciona em 27 unidades do MPF. Falando de regras de negócio, foi muito interessante ver como a instituição conhecia pouco os seus próprios processos. Sendo assim, às vezes o sistema único não vem automatizar um processo, mas vem impor um novo processo, o que gera resistência muito forte à mudança.
Por exemplo: o MPF não sabe dizer quantos grampos telefônicos ele mesmo pede, porque nem sempre o procurador registra no sistema. Ele escreve um ofício ao juiz, mas não registra no sistema. E de repente a gente tem de contabilizar o número de grampos, porque o conselho nacional do próprio MPF mandou.