Se o aplicativo foi bem escrito, e se o computador em que ele está alojado funciona, o aplicativo funciona — não importa quantos anos ele tenha. Esse é um dos problemas de quem precisa modernizar aplicativos: descobrir que o aplicativo está velho. Depois vem outro problema: convencer os usuários a gastar dinheiro substituindo algo que, há anos, funciona.
A mesa-redonda foi coordenada pelo diretor editorial do Informática Hoje, Wilson Moherdaui. Participaram: Alexandre Junqueira Franco, CIO da EDP Energias do Brasil; Fátima Baptista Marques, gerente de TI da Camicado; Gustavo Tadao, gerente de arquitetura da Serasa Experian; Luiz Alves dos Santos, diretor departamental do Bradesco; Marco Perez, gerente de TI da Drogaria Onofre; Miguel Alcântara, diretor de sistemas da NET; Paulo Renato Fabiano Franco, CIO da Liberty Seguros; Ralf L. de Paiva, gerente de relacionamento da Prodam; Roberto Newton Carneiro, CIO da Comgás.

IH — Qual tem sido a experiência de vocês com a modernização de aplicativos?

Alexandre — Comecei na Energias do Brasil em 2001, justamente com a modernização de aplicativos. Na Bandeirante Energia, uma das distribuidoras do grupo, trocamos o sistema do mainframe pelo SAP R/3, pelo Small World, um sistema da GE Network Solutions, e pelo Power On, um sistema de gestão de ocorrências da distribuição. Fomos os primeiros a instalar o SAP CCS, e foi uma instalação complicada; fiquei sem dormir direito uns seis meses.
Só acabamos a modernização do último sistema legado, o sistema comercial, agora em junho. Então, nos últimos oito anos, tudo o que fizemos foi instalar aplicativos novos no lugar dos aplicativos legados.
Tivemos problemas para selecionar parceiros, sanear os dados, migrar os dados. São milhões de faturas todo mês, em três estados: São Paulo, Espírito Santo e Mato Grosso do Sul.
Nossa principal falha, em 2004, foi calcular errado o prazo de instalação do sistema comercial, e calcular errado o custo. Foi o preço do pioneirismo. Hoje a SAP instala esse módulo em 24, 30 meses; nós tentamos instalar em 18 meses — não era possível.
Até hoje o sistema alemão não está preparado para tratar milhões de faturas por mês. Na Alemanha, o faturamento é feito a cada seis meses, ou a cada ano. A gente ainda tem de buscar fraudadores, lidar com perdas, revisar faturas por conta de erros dos leituristas ou de funcionários de escritório...
Então, algumas regras de negócio dos sistemas legados não existem nos pacotes. O R/3 está bem tropicalizado, mas não os sistemas comerciais. Com uma mudança no PIS/Cofins, nós perdemos R$ 3,5 milhões num mês, porque não conseguimos mudar o sistema em tempo.
Eu nem posso responsabilizar a SAP, porque ela fez das tripas coração, trouxe engenheiros da Alemanha.
O problema é que a gente abapou demais a primeira solução [personalizou demais, usando a linguagem Abap], e quando alguém abapa demais um sistema SAP, ele se torna instável, porque o suporte fica mais difícil.
Outra dificuldade: nos sistemas legados, cada instalação é um cliente. No SAP, existe um único cliente e várias instalações associadas. Migrar esses dados foi muito difícil: no sistema legado, o mesmo cliente tinha dois CPFs, dois nomes. Para usar o SAP, precisávamos de dados mais íntegros, e limpar os dados para a migração foi difícil.
Erramos ao contratar a empresa que nos ajudou a sanear os dados. Buscamos o melhor preço. Eles chegaram a encher um prédio inteiro com um tal de Marcelo Silva.
Mas aprendemos. Depois dessa primeira migração, erramos muito menos.

Roberto — Nossa história é parecida com a do pessoal das elétricas: fomos privatizados, e hoje somos das empresas inglesas BG e Shell. Em 1999, às vésperas do bug do milênio, nós também mudamos os aplicativos com pressa. Trocamos um punhado de sistemas legados por um ERP da SAP. Escolhemos SAP também porque os legados não nos permitiriam crescer: queríamos crescer nas indústrias, mas principalmente nas residências. Precisávamos de um ERP, de um CRM, o coração do relacionamento com os clientes, e de um sistema de faturamento — tudo junto. E decidimos instalar tudo em 18 meses. Conseguimos, mas mexemos no sistema o mínimo possível. Foi rápido, ficou barato, mas instalamos um sistema quadradão. O desafio agora é construir em cima disso.

IH — É a modernização da modernização?

Roberto — É a flexibilização da modernização. Estamos desenvolvendo muita coisa com a arquitetura orientada a serviços [SOA], usando o sistema SAP como um barramento de serviços, e estamos ligando soluções mais flexíveis nesse barramento.
É difícil lutar contra a obsolescência da tecnologia: software não fica podre, não tem data de validade. A gente percebe que o software ficou velho porque a manutenção fica mais cara, porque fica mais difícil achar técnicos no mercado.

IH — O que deu certo e errado nessa primeira fase de instalação, a do sistema quadradão?

Roberto — A gente subestimou a complexidade. Num projeto longo, de 24 meses, tem sempre quem pressiona: ah, se demorar tudo isso, a gente não faz. Então, prometemos 18 meses.
Quando olhamos o sistema que implementamos e a lista de coisas que deixamos de fora, o projeto terminou com um passivo de novas instalações pela frente. O custo desse passivo deve ser incluído no custo do projeto. Então, não posso dizer que o projeto custou tantos milhões em 18 meses. Dizer isso seria um erro de avaliação.

IH — E no governo, como é atualizar os aplicativos?

Ralf — Alguns dos nossos sistemas são dos anos 70 — estou falando de sistemas de 40 anos já. E tudo em São Paulo é ão, a máquina de São Paulo é gigantesca.
Um projeto de migração na área pública leva um tempo danado, porque os sistemas são muito especializados, e todos são gigantescos, por conta do tamanho da cidade.
O pior é que, trabalhando no dia a dia, não nos damos conta da quantidade de regras de negócio embutidas no nosso sistema. Todas as nossas experiências com modernização foram dolorosas. Mas a população cobra serviços disponíveis na web. Os candidatos prometem isso e, assim que assumem, a promessa passa a ser problema nosso.
Aí, falta dinheiro. Pois modernização exige investimentos em arquitetura de software, em computadores e tudo o mais. E nossas experiências com parceiros nem sempre foram boas. Se eu pudesse escolher o parceiro, seria mais fácil, mas não posso: sou obrigado a fazer licitações.
Às vezes somos obrigados a subestimar os prazos, porque o político tem lá os prazos dele. Nós fizemos um inventário do legado, e descobrimos 14 mil programas na nossa biblioteca, para tudo quanto é computador, de tudo quanto é fornecedor. Para integrar tudo isso, fazendo as contas, chegamos a preços impossíveis.
Não dá: meu orçamento é na verdade o orçamento dos meus clientes, que têm lá o planejamento deles. E depois das reuniões com eles, ainda tenho várias limitações legais. Nós, da área de TI, no fim das contas ficamos sempre em terceiro plano.
Eu não posso demitir ou contratar pessoal, e o orçamento é aprovado em outras instâncias, fora da Prodam; fica difícil fazer contas como a de ROI, por exemplo. Toda diretoria, quando chega, fica preocupada com isso, e aí fazemos grandes planos. Mas minha experiência me diz: só dá para modernizar aos pouquinhos.

Marco — Trabalhei 18 anos numa empresa de varejo. Depois de reconstruir vários aplicativos legados, analisamos e vimos que o pessoal não usa 20%, às vezes 30% das regras de negócio, ou das funcionalidades. Gastamos tempo e dinheiro com aquilo, mas depois ninguém usa. Mas usamos a programação orientada a objetos, e vemos que, se mexemos numa parte do aplicativo, mexemos também em outras. Precisamos tomar cuidado.
Também enfrentamos problemas com os bancos de dados, os índices, as tabelas. Foi difícil remontar todas as tabelas.
E aí vieram os ERPs. Instalamos JD Edwards, com bastante customização. Quem customiza muito, como fomos obrigados a fazer, depois sofre com as atualizações do sistema. Para integrar o ERP aos outros sistemas, nós descaracterizamos o ERP. Toda vez que atualizávamos alguma coisa, perdíamos uma parte das atualizações anteriores, e tínhamos de fazer tudo de novo.
Hoje, eu faria diferente: faria a customização fora do pacote, protegendo os aplicativos centrais.

Fátima — Temos um sistema central, que atende nossas sete lojas, e que atende as listas de casamento, um negócio muito importante para nós. Mas é um sistema muito flexível — é a cara da Camicado. Tem um lado ruim: a gente cria alguma coisa, tipo uma coluna com informações na Internet, e isso atrapalha uma outra função do sistema. Nosso erro foi flexibilizar demais. Quando flexibilizamos demais, criamos coisas que acabam atrapalhando as coisas que já temos.
Estamos numa fase de voltar atrás. Estamos em busca de um ERP que não seja tão flexível.
Antes disso, por causa do novo ERP, fizemos uma reengenharia de processos; esses processos vão entrar num ERP mais engessado, e vamos trabalhar com pouquíssimas customizações.
Vamos desprezar as regras antigas de negócio, e vamos criar novas. É uma mudança considerável na estrutura da empresa, mas é a melhor opção, em termos de custo-benefício.

Miguel — A NET já tem 90 e poucas operações e hoje a gente tem um único sistema que atende todo mundo, mas não foi assim sempre. Em 2003, a NET tinha sete sistemas, alguns atendiam algumas operações, outros uma operação específica, como é o caso de São Paulo. De 2003 para 2007, migramos quase todos os aplicativos para dentro de um sistema nosso, chamado NET SMS. E sempre que comprávamos uma nova empresa, fazíamos todo o processo de migração de dados para o nosso sistema.
Cada cliente no nosso sistema está num lugar só; a consistência dos dados é muito grande.
Mas abrimos duas grandes frentes. Estamos estudando a arquitetura dessa indústria, e estudamos como será a evolução dessa indústria. É uma indústria nova, e então estamos descobrindo muitas funcionalidades.
Outra frente é a governança da TI: essas coisas ficam mais fáceis, ou talvez menos difíceis, se a governança é boa. Depois de sete migrações difíceis, e com a governança, migração virou quase um lazer para nós. Na primeira delas, paramos a empresa por quatro dias. Hoje, a gente vira uma migração em três etapas — três noitezinhas. Ninguém percebe direito o que está acontecendo.
Com isso, conseguimos evoluir. Esses combos, por exemplo, de TV, banda larga e telefone, não tinham sido imaginados por ninguém.
Agora estamos numa segunda onda. Vamos trocar o sistema de billing [tarifação e cobrança], e o de provisionamento, ou processo de instalar a caixinha na casa do cliente, e de ativar ou desativar serviços.
Tendo integridade de dados, conseguimos visualizar uma mudança de sistemas muito radical. O nosso problema é: como essa indústria está em transformação, precisamos prever quais serão as regras de negócio daqui a cinco anos.
Tomamos o cuidado de não escrever mais requerimentos com base no que usamos hoje, pois em três anos isso virou passado. A gente procura imaginar como será o produto, o serviço, visto que temos uma relação com o consumidor: nós entramos na casa dele, instalamos coisas na sala, no quarto. Temos de dar a capacidade, por exemplo, de o instalador fazer uma nova venda, com base no que ele está vendo, e de instalar ali mesmo, na hora.
Agora, para os funcionários, que estão ali recebendo as novas regras de negócio, muita coisa desceu goela abaixo mesmo; mas era uma decisão corporativa.

IH — Alguma coisa deu errado?

Miguel — Nas primeiras migrações, decidimos trazer todo o histórico. Foi uma decisão ruim. Fazer uma nova venda com um sistema novo é fácil: eu pego o CPF, o telefone, o endereço, tudo direito. Mas, quando eu trago o histórico do cliente, e vou fazer uma nova venda, é diferente. O desempenho do aplicativo, por exemplo, fica ruim. Gastamos um bom dinheiro com ferramentas de diagnóstico de desempenho por causa dessa decisão, a de trazer o histórico.
Com o crescimento que tivemos, de cento e poucas mil vendas por mês, o tempo de resposta dos aplicativos fica sempre aquém dos SLAs. As matrizes ficaram muito pesadas.
E colocamos muitas regras de negócio em Java, dentro do banco de dados. A manutenção disso é difícil. Eu preciso dos caras que vieram junto quando eu comprei a ferramenta. Sem eles, fica difícil. A demanda da empresa é muito grande, e só nós conseguimos mexer no código.
Tenho dificuldade com o faturamento. Tenho três janelas de manutenção por mês — tudo o que é novo eu preciso fazer durante essas três janelas. Se tiver muita demanda, posso até criar a regra de negócio ou o aplicativo, mas não tenho janela para colocá-los no ar.

Tadao — Agora, os nossos clientes exigem de nós que façamos parte do processo de negócio deles. Temos experimentado alguns negócios assim: em vez de entregar uma análise de crédito, fazemos a terceirização completa do processo de crédito.
Por exemplo, propostas de cartões de crédito: a gente pega o formulário preenchido, passa pela análise de dados, enriquecimento de dados, análise de crédito, um processo de revalidação. até a entrega para uma outra empresa que imprime os cartões.
Isso gerou uma segunda fase na modernização da nossa área de TI.
Ser moderno, para nós, é alinhar o que o cliente precisa com a infraestrutura, servidores, segurança, aplicativos. Por isso, internamente, conduzimos dois grandes projetos. Estamos construindo um sistema de entrega de serviços com SOA, e estamos modernizando o nosso processo de desenvolvimento de software. O objetivo final é entregar serviços em menos tempo.
Nosso núcleo de informações está em mainframe, com um banco de dados moderno, o DB2; é um núcleo estável. O que muda daqui para a frente são os serviços que oferecemos com esse núcleo: relatórios, cruzamento de dados, etc. Fazemos isso com plataforma baixa, com Java e .Net.
Sou novo na área de TI, não participei da criação dos sistemas em Cobol, mas tem muita inteligência nessas regras de negócio criadas lá atrás. Acho que devemos colocar no mainframe o que deve ser colocado no mainframe, ou seja, o que deve ser entregue em tempo real; e que devemos tirar do mainframe o resto.

IH — Como é modernizar sistemas num banco grande?

Luiz — Banco de dados único é um sonho para nós, do Bradesco... Temos 250 mil programas no mainframe, e umas 150 mil tabelas.
Estamos há quatro anos trabalhando numa nova arquitetura. Nosso cliente só vê modernidade no que funciona bem, no tempo de resposta. O legado é o que faz a empresa funcionar, o futuro é o futuro, e o dia de hoje é o dia de hoje.
Nosso desafio é desempenho: quando a gente ganha uns segundos numa transação, multiplica isso por milhões de transações por dia, e os resultados são fabulosos, principalmente os resultados financeiros.
O gestor da área de negócio não quer saber do futuro. O problema dele é hoje.
Estamos reescrevendo tudo o que fizemos nos últimos 40 anos, usando a arquitetura SOA. Queremos mexer num serviço, num único lugar, e atualizar automaticamente todos os aplicativos, todos os canais. Temos 2.500 programadores fazendo isso, fora a equipe de arquitetura, mas a real modernidade é aquilo que funciona.
Mas esse trabalho vai até 2010, 2011, quando teremos 80% do trabalho realizado. Contratamos umas 15 empresas para nos ajudar. Mas não usamos pacotes, porque em geral eles não aguentam o tranco.
Nós não subestimamos a complexidade do projeto, mas o usuário de negócio tende a achar que um projeto desses é mais fácil do que ele realmente é.

Alexandre — A TI muitas vezes falha nesse ponto: ela deixa que os usuários se coloquem na posição de clientes da área de TI. A TI faz a sua parte, monta o projeto, calcula o custo do projeto, o custo da manutenção; e o usuário faz a sua parte, lista os benefícios tangíveis e intangíveis. E assim a TI e o usuário calculam o ROI, o retorno do investimento do projeto de TI.
Por isso os projetos técnicos de TI saem no custo e no prazo, mas os projetos mais comerciais, que envolvem o usuário, demoram mais: porque o usuário se põe na posição de cliente, e pede os requisitos A, B, C, D, E... Mas depois é o gestor de TI quem vai ao conselho de administração dar a cara para bater.
Por isso, na onda atual de modernização, mudamos: quem briga pelo dinheiro e pelo prazo é o gerente da área de negócio; a área de TI entra como cogestora.

Roberto — Eu disse que instalamos um pacote sem grandes customizações, o que a princípio traria um certo grau de rigidez para o negócio. Se a área de TI gerenciasse isso de forma centralizada, viraria a porta para o inferno — no dia seguinte todo mundo estaria lá dizendo que o sistema novo era uma porcaria. Mas tomamos a decisão em conjunto. Então, modernizar aplicativos é uma decisão a ser tomada em conjunto.

Alexandre — Preciso fazer um aparte: as áreas de negócio participaram intensamente de todos os projetos que a TI fez. Eu estou falando mais é dos cabeças mesmo, das lideranças. Quem deve assumir a responsabilidade pelo sistema comercial é o vice-presidente comercial, e não o vice-presidente de TI. É disso que estou falando.

Paulo — No fundo, o que é o negócio de seguros? É gestão de contratos: vigências, coberturas, condições.
O segredo da área de informática é montar uma bela fábrica de produtos, ou seja, de configuração de produtos. Os funcionários responsáveis pelos produtos devem fazer as configurações sem chamar a área de informática.
Isso funciona bem quando o número de transações é pequeno, e o valor de cada transação é alto.
Quando vamos para o varejo, para carros e residências, aí o desempenho de uma empresa de seguros depende do canal de distribuição. E todo mundo sabe que quem vende seguros no Brasil é o corretor de seguros. Por força de lei.
Para nós, é importante se modernizar sempre, porque o corretor vai usar o nosso sistema do escritório dele, com o computador dele.
É claro que não mexemos no miolo do miolo com tanta frequência: fazemos isso a cada sete anos, mais ou menos, e fazemos com muita cerimônia, para incluir todo o aprendizado dos anos anteriores. Vamos criando mosaicos de aplicativos, e de tempos em tempos precisamos transformar tudo aquilo em processos unificados.
A cada vez que alguém faz uma fraude, criamos novos critérios para lidar com aquilo. No mercado de seguros, se você for o último a mudar os sistemas, você fica com todos os fraudadores só para você.
Neste momento, estamos entrando num desses processos de reunir aprendizados; em 2011, estaremos de novo otimizados.