Quando a área de informática extrai as regras de negócio de um sistema legado, dizem os participantes desta mesa-redonda, ela deve tomar o cuidado de não tomar aquelas regras como a verdade inquestionável. Tudo bem que a empresa funcionou anos de acordo com aquelas regras, mas, justamente porque as regras estavam invisíveis dentro de um mainframe, talvez elas estejam erradas.
O debate foi coordenado pelo diretor editorial do Informática Hoje, Wilson Moherdaui. Participaram: Ana Lúcia de Araújo, gerente de manutenção de aplicativos da Algar Tecnologia; Denise Porcaro, diretora de projetos e negócios da Embratel; Fernando Ramos, gerente de TI do Banco BBM; José Coelho Gioia, diretor executivo do Proderj; Umberto Reis, superintendente de sistemas da SulAmérica Seguros; e Wilmar Scherrer de Amorim, gerente de projetos de TI da Petrobras Distribuidora.

IH — Como modernizar aplicativos sem sofrer demais?

Wilmar — Na Petrobras, temos o ERP da SAP, o CRM da Oracle, o portal da IBM e agora estamos escolhendo o sistema de supply chain [gestão da logística e de fornecedores e subfornecedores]. Esses três grandes sistemas trocam informações entre si por meio de serviços.
No caso do supply chain, ele vai substituir muita planilha. No caso do banco de dados, quando instalamos o novo banco, escrevemos muitas regras de negócio novas, pois o escopo desse projeto era maior do que o escopo anterior.

Gioia — O Proderj atende o Estado do Rio de Janeiro, em termos de processamento de dados, mas não somos o único CPD do Rio — algumas secretarias possuem uma capacidade razoável de processamento.
Nossa briga é trazer isso para o Proderj. Trabalhamos com cargas enormes; por exemplo, processamos a folha de pagamento de 400 mil servidores, entre ativos e inativos. Por isso usamos mainframe.
Estamos instalando agora uma nova máquina, mais poderosa, totalmente particionada, em que poderemos usar não só o sistema operacional da IBM, mas também Linux e etc.
Sobre atualizar os aplicativos: contratamos um pacote para substituir o sistema de recursos humanos do estado; esse sistema roda em Linux, e o fornecedor ficou desesperado quando soube que ele teria de instalar o sistema num mainframe.
Além disso, estamos modernizando alguns sistemas do Detran, colocando uma camada de apresentação para o usuário. Quem usa o Detran via Internet, não sabe que detrás da tela existe um sistema de uns 40 anos atrás, escrito em Natural; estamos modernizando esse sistema usando ferramentas do próprio fabricante, a Software AG.
Precisamos de uma ferramenta para descobrir regras de negócio. Algumas foram escritas há 40 anos, quem escreveu não está mais por aí, e não existe documentação nenhuma.

IH — Os usuários estão conscientes dessas mudanças? Ou será uma imposição?

Gioia — De alguma forma, eles pediram isso. Mas, quando eu colocar uma ferramenta e extrair as regras de negócio, não terei a palavra final. Terei de voltar ao usuário para conversar com ele, para ver se aquela regra não deve ser modificada, ou melhorada.

Ana — Eu estou no Grupo Algar há quase dez anos, e nos perguntamos várias vezes que caminho seguir — modernizar, reescrever, comprar um pacote.
Participei de um projeto assim, com o CRM. O jeito de ser da empresa está embutido no CRM, o sistema com o qual trabalhamos o relacionamento com os clientes. Levamos em conta vários fatores.
Um aplicativo crítico inclui investimentos em vários campos: pessoas, processos, a própria tecnologia. É importante, apesar da modernização, buscar caminhos para preservar investimentos.
Uma coisa interessante: no processo de modernização, a gente se desvincula um pouco do fornecedor; dá para voltar alguns conhecimentos, algum domínio, para dentro da nossa empresa. Além disso, conseguimos evoluir a arquitetura, o que nos dá flexibilidade, mobilidade, Internet.
No caso do CRM, optamos por manter o banco de dados central e mudar a camada de apresentação, para incluir Java, ou seja, incluir a Internet.

Umberto — Na SulAmérica, temos uma estrutura por unidades de negócio — uma de automóvel, uma de vida, uma de investimentos, uma de redes industriais. De quatro anos para cá, estamos modernizando os sistemas. Acho que o verdadeiro problema é alinhar os planos futuros da área de TI com os planos futuros das unidades de negócio.
No caso do sistema para automóveis, optamos por reescrever os aplicativos; estamos trocando Cobol por Java, com as regras de negócio instaladas numa solução própria para regras de negócio. Foi um trabalho cansativo, esse de ler milhares e milhares de linhas de Cobol para achar as regras de negócio, migrar para o sistema de gestão das regras de negócio, e reescrever toda a apresentação e os acessos aos bancos de dados usando Java.
Na área de sinistros, ainda dentro de automóveis, optamos por um sistema de mercado. Compramos um ERP americano, especializado.
Na área de riscos industriais, optamos por modernizar, ou seja, envolver o código Cobol com web services.
Na área de vida, vamos misturar: modernizar algumas coisas, reescrever outras coisas.
Depois virá a área de saúde.
Mas a escolha está bem atrelada à dinâmica da área. Se os negócios mudam muito, é melhor reescrever. Se mudam pouco, talvez seja melhor comprar um pacote de mercado.

IH — Como e onde surgem os principais problemas?

Umberto — Problema é sempre e não é pouco. Sempre que uma empresa usa uma ferramenta nova, ou uma tecnologia nova, leva um tempo para aprender a usá-la.
Mas, de forma geral, é mais difícil reescrever um aplicativo. Se você adota um pacote, as regras são aquelas do pacote, e ponto; a dificuldade é conseguir a aceitação dos usuários, que terão de conviver com um sistema mais engessado. Se você reescreve, demora mais para identificar o que é regra de negócio válida e o que é erro mesmo; é mais cansativo.
Contudo, adotamos uma metodologia nova, a scrum, cuja recomendação é envolver o usuário logo; técnicos e usuários trabalham juntos. Conseguimos ver logo em que pontos os técnicos e os usuários terão dificuldade de se adaptar.
No caso de envolver o legado com aplicativos novos, o principal problema tem sido reescrever o processo, redesenhá-lo, e aprová-lo junto aos usuários.

IH — De toda forma, é mais difícil reescrever?

Umberto — Sem dúvida. Seguro nada mais é do que uma sucessão de regras de aceitação: o preço varia se for mulher, se for homem até tal idade, se for picape da região sul... Isso tudo estava espalhado em linhas de código Cobol.

IH — Grosso modo, o CIO tem um problema com a tecnologia ao reescrever, e um problema com as pessoas ao comprar um pacote novo?

Umberto — Podemos generalizar assim.

Gioia — Um problema é administrar a ansiedade dos usuários, ao instalar um pacote, porque ele quer customizar tudo.

Ana — Até porque é a oportunidade dele rever mesmo os processos.

Umberto — E isso se vira contra o projeto muitas vezes, porque a gente tem prazo, tem orçamento para cumprir.

Fernando — No início de um projeto desses, de modernizar aplicações escritas há 30 anos, precisa haver uma discussão estratégica, e uma discussão estratégica não significa uma pessoa iluminada, numa sala, desenhando os novos processos e as novas regras de negócio.
Até que ponto a empresa vai substituir ou manter regras de negócio, até que ponto ela vai segurar novas mudanças para realizar o trabalho de substituição — tudo isso tem impacto na capacidade de competir.
Fechar esses acordos com todos os interessados é a chave do sucesso. A principal definição inicial é: qual área é importante, qual área faz diferença? Todas as áreas querem ser importantes, mas aí a empresa perde o foco.
Eu não acredito muito nessa história de converter código. Acho que o esforço é grande demais para os resultados. Acho complexo, difícil, trocar Cobol por Java. Se a gente converte o código, mantém os mesmos paradigmas, as mesmas divisões, a mesma modularização. A gente agiliza os problemas.
É também mais ou menos a mesma coisa envolver o legado com web services, com SOA: as telas ficam bonitas na web, mas o processo lá dentro é o processo do legado.
E se a gente pega um módulo em Cobol e reorganiza o módulo para ficar mais orientado a processos, você transforma um módulo em cinco, seis módulos diferentes.
Por isso, temos de registrar todas as premissas, registrar todas as decisões estratégicas, assim o comitê de direção consegue navegar nas ambições de cada área, nas disputas de poder, na disputa por orçamento.
Estamos discutindo isso agora, discutindo a transição para o mundo novo, discutindo quem deve fazer parte do comitê de direção. Um banco precisa estar ciente das suas escolhas.
Para os usuários, a TI é uma caixa preta e complexa, que dá problemas, e que não atende. Hoje, eu tenho um backlog [lista de projetos a entregar] com 800 pedidos declarados. Recentemente, fizemos uma conta: levaria 20 anos para atender todas as demandas.

Denise — Temos quase 400 sistemas em produção na Embratel, 40% em plataforma alta. Hoje, temos 5 milhões de clientes residenciais. A modernização dos sistemas é discutida na minha área, a de novos negócios.
Desde 2007 temos uma arquitetura-alvo e um caminho até a arquitetura-alvo, e isso lá dentro é lei.
Conseguimos fazer com que os usuários apoiassem o projeto de modernização; eles entenderam que o crescimento da empresa está atrelado aos sistemas. Eles batem na porta do presidente.
Só para dar uma ideia, participamos de um comitê internacional de arquitetura, que se reúne toda semana.
Em três anos, pretendemos ter uma arquitetura nova; usamos uma fábrica de software em Tijuana, no México, e minha equipe é mista, parte aqui, parte lá.
Amarramos a esse programa a entrega dos principais produtos; os produtos mais críticos a gente entrega logo no início desse programa, assim eles trazem ganhos para a empresa.

IH — Ainda existem regras de negócio criadas antes da privatização do Sistema Telebrás?

Denise — O faturamento do cliente residencial, por exemplo, está inteiramente no sistema legado. Alguns serviços, como o NET Phone, funcionam de acordo com uma colcha de retalhos de aplicativos.
Vamos investir em SOA, em documentação. É complicado, esse tipo de mudança, diante de milhões de chamadas que completamos todo dia.
Mas o nosso sistema de portabilidade, por exemplo, já foi todo orientado a serviços, com um grau de reutilização muito forte.

IH — Qual é o papel da TI ao conversar com a diretoria da empresa sobre a modernização de aplicativos?

Ana — O desafio é mostrar os resultados, porque só dá para mostrar os resultados com a cooperação dos usuários. A área de TI não consegue fazer isso sozinha.

Wilmar — Muitas vezes, o usuário vai fornecendo informações ao longo do projeto, e o escopo do projeto vai crescendo. Chega a hora de tirar algumas coisas do escopo, para manter o prazo, para manter o custo. Mas aí o que colocamos de fato em produção fica diferente do que combinamos no início, e temos de passar o que combinamos no início para uma segunda fase.
Nós sempre tentamos manter no escopo dos projetos aquilo que dá mais retorno, e tentamos passar para a segunda ou terceira fase aquilo que dá menos retorno. É assim que tentamos tratar a complexidade.
Mas sempre ocorre o seguinte: depois que a primeira fase do projeto entra em produção, o usuário enxerga as possibilidades do sistema, e a gente tem de confrontar essas novas possibilidades com o que a gente tinha combinado no início do projeto.
E aí o que deveria ser a segunda fase do projeto vira a terceira ou a quarta, porque os usuários incluem coisas nas quais eles não tinham pensado antes.
Isso aconteceu no nosso projeto de CRM. E isso deve acontecer com um projeto de hoje: nós temos de criar um sistema chamado de inteligência fiscal, ou seja, de análise das informações fornecidas ao Sped [Sistema Público de Escrituração Digital, do qual a nota fiscal eletrônica faz parte], pois assim a gente não paga impostos indevidamente. Esse projeto dá um bom retorno, mas se o escopo se desviar para outras coisas, não temos como garantir o retorno do projeto.

Denise — O retorno do investimento é importantíssimo num projeto de modernização — mas o usuário tem de usar o sistema. Dois anos atrás, a área de TI entendeu que seria excelente construir um sistema para automatizar um processo muito manual, baseado em planilhas Excel, um processo muito usado pela Embratel nos últimos 30 anos. O que aconteceu? O usuário não quis. Ele estava há 30 anos conduzindo aquele processo, ele não quis, e ele não quer. Qual foi o nosso erro? Nós não pusemos o usuário na liderança dessa transformação. Nós não soubemos fazer o marketing da TI, fazer a venda, escolher direito o patrocinador do projeto.

Umberto — Na SulAmérica, nós envolvemos o usuário, mas não deixamos o usuário criar um novo silo de tecnologia, porque às vezes ele quer comprar uma tecnologia barata agora, mas que não combina com a arquitetura. Se eu permito, daqui a cinco anos eu vou pagar pela manutenção daquilo, e ninguém vai me deixar pôr o custo na área usuária, e aí a TI volta a ficar muito cara.

Fernando — Quem escolhe isso é a empresa. Se ela quer uma arquitetura rígida, é uma decisão estratégica. Se ela quer uma arquitetura mais flexível, que possa encaixar um pacote de mercado rapidamente, é outra decisão. A nossa função na TI é mostrar como, ao longo do tempo, uma dessas escolhas vai ficando cada vez mais cara.

Ana — Tínhamos um projeto de dez anos, em duas fases de cinco anos, para levar tanto os sistemas de informática quanto os de telecom para a NGN [uma rede de pacotes totalmente controlada por software, nos moldes da Internet].
Vieram as crises, e o orçamento desse projeto sofreu cortes enormes.
No fim, teremos aplicativos novos e velhos convivendo juntos por muito mais tempo do que prevíamos antes, e talvez por isso a modernização de aplicativos tenha se tornado uma alternativa tão interessante.

Denise — Por isso é tão importante planejar entregas rápidas. Por melhor que seja um projeto, se ele ainda não entregou nada, ele é cortado na hora da crise. A gente deve ter um alvo, mas deve pensar sempre a curto prazo. Este ano, por exemplo, tivermos um corte muito alto nos investimentos. Fizemos uma série de reuniões para dar prioridade aos projetos com entregas mais rápidas, e que ao mesmo tempo representassem uma modernização.

IH — Quais são as melhores métricas para acompanhar um projeto de modernização de aplicativos?

Fernando — É errado avaliar os benefícios de cada projeto de forma isolada, porque tem sobreposição, intersecção de benefícios. Tem de avaliar os benefícios do portfólio inteiro de projetos, porque o povo exagera.
Por exemplo: a gente mantém alguns sistemas distribuídos. Para manter um sistema num outro lugar, temos de pagar o link de comunicação de dados, mais o servidor, mais o hosting [o aluguel de espaço num CPD]. Então vamos colocando na conta tudo o que está relacionado com aquele sistema lá, e que é acessado uma vez por ano por alguém da controladoria ou por algum fiscal do governo. O preço bate centenas de milhares de reais. Isso se justifica, ou é melhor fazer alguma coisa diferente? Se a gente não olha isso, e não faz nada, o nosso custo total aumenta.

Ana — Quando alguém vai vender um projeto para o meu diretor financeiro, e diz que vai reduzir custos, ele já corta aqueles custos do orçamento. Se diz que vai gerar receita, ele já coloca na previsão de vendas. O sujeito não tem saída, senão entregar o que prometeu.

Denise — Na Embratel, quem preenche os benefícios financeiros de um projeto qualquer é o diretor financeiro e sua equipe, muitas vezes depois de discussões prolongadas. É uma responsabilidade centralizada, e vale para toda a corporação.

Ana — No Grupo Algar, por exemplo, nós optamos por manter no ar o BSS, o sistema velho de faturamento para celular, durante os cinco anos de exigência do fisco, porque ficava mais caro desmobilizar o sistema do que mantê-lo funcionando. Eu migrei só as faturas em aberto para o sistema novo, e mantive as faturas fechadas no BSS durante o tempo exigido pela regulamentação.

Gioia — Depende muito da situação: alguns dados eu preciso guardar por 30 anos. É melhor gastar toda a energia possível na migração para o sistema novo do que guardar uma máquina velha por 30 anos.