Nesta mesa-redonda, realizada em São Paulo, sete executivos de informática chegam juntos a uma definição interessante de legado: se a área de informática não consegue terceirizar o sistema para algum fornecedor, então esse sistema é legado, pois é problema da área de informática. Logo, existem dois tipos de legado: o sistema fundamental para a empresa, que a área de informática não terceiriza porque ele é fundamental; e o sistema feito sem metodologia e sem documentação, que a área de informática não terceiriza porque ele é desconhecido.

Coordenaram a mesa-redonda: Wilson Moherdaui, diretor editorial do Informática Hoje, e Márcio Simões, diretor de redação. Participaram: Carlos de Almeida, gerente de tecnologia e sistemas do Banco Alfa; Fernando Augusto Martins, gerente de desenvolvimento de sistemas do Banco Cacique; Hélio A. Silva, gerente de sistemas e serviços da informação na GM do Brasil; José Augusto Pereira Brito, gerente de informática do Instituto Presbiteriano Mackenzie; Luiz Alves dos Santos, diretor de desenvolvimento de sistemas do Banco Bradesco; Walter Acras Júnior, consultor da NeoGrid; e Walter Sanches, gerente de TI do Tenda Atacado.

IH — Existe sistema velho numa indústria moderna como a de carros?
Hélio — Temos legados na GM de 30 anos. Produzimos mil veículos por dia [no Brasil], então eu preciso de um aplicativo de controle da produção robusto, com detalhes sobre o meu negócio. Esse é o legado, porque nenhum ERP cobre processos pouco comuns no mercado. Temos SAP em operações menos complexas de alguns países, mas há mais de dez anos a SAP e nós trabalhamos para construir um ERP que possa substituir o legado numa empresa que fabrica 12 milhões de veículos por ano [no mundo]. Ainda não chegamos lá.
Ou seja: o legado inclui os segredos da nossa empresa, o que torna difícil substituí-lo. A oportunidade de negócio nessa troca tem de ser muito boa.

IH — Existe alguma coisa obscura para vocês dentro do legado?
Hélio — Existe. Mas nem sempre esses pontos obscuros justificam substituir o legado. Quando fomos alterar o aplicativo que usamos para faturar veículos, por causa da nota fiscal eletrônica, achamos funcionalidades esquecidas; achamos um módulo que valorizava determinado índice, isso dos tempos da inflação. Era um módulo grande, que não estava mais sendo usado, e que substituímos por um módulo menor.
Então, num sistema legado muito grande, existem cantos obscuros, que consomem processamento ou consomem as interfaces. Mas não podemos substituir um legado só por causa disso.
Nós temos uma lista de TI, uma lista de aplicativos e de tecnologias que compõem os processos da GM. A matriz criou essa lista, mas nós fizemos o projeto piloto no Brasil, com dois sistemas importantes: o SAP e o módulo de replanejamento de inventário das concessionárias.
Essa lista nos dá o norte, a estratégia, em cada processo; eu sei quando devo usar um aplicativo do tipo Hyperion, por exemplo, em vez de usar o BW da SAP: porque está na lista. Mas o caso é que, na administração dessa lista da TI, incluímos metas de redução do legado.
Quando surge uma tecnologia que pode substituir um legado, eu tenho prazo para mudar. Caso contrário, sou cobrado pela matriz.

IH — E como é a linha de montagem no Mackenzie?
Brito — O setor da educação está sempre uns sete anos atrasado em relação aos setores mais modernos. Quando entrei no Mackenzie, em 1998, trabalhei num plano diretor de informática para deixá-lo mais parecido com as grandes universidades no exterior, e esse PDI está alinhado com o plano do Mackenzie como um todo. Então, nesses dez anos,
a gente tem feito revisão
de processos e tem webificado tudo.
Trabalhamos com dois ERPs: um para as tarefas de administração, e outro para o negócio da educação. Esse é o nosso legado: ele tem uns 20 anos, e uns 9 milhões de linhas de código. Os processos do ERP de educação já estão bem solidificados.
Como juntar todas as peças? Pois, de repente, precisamos fazer a integração de uma quantidade muito grande de módulos.
Montamos uma equipe própria, que treinamos, e essa equipe tem integrado todas as partes do legado para montar o nosso BSC [balanced scorecard, ou o painel com indicadores a respeito dos negócios]; o conselho de administração terá acesso via Internet ao BSC.
Mas temos sofrido com as auditorias, porque ainda usamos bancos de dados hierárquicos no legado, e os jovens auditores cresceram pensando em SQL [a linguagem de consulta aos bancos de dados modernos]; eles têm dificuldade para entender que parte da lógica fica um pouco no código e um pouco no banco de dados. Não é como auditar processos num SAP ou num Oracle, em que você aperta um botão e os relatórios ficam prontos.
Temos usado tecnologia nova para converter esses bancos de dados no padrão SQL, para dar uma roupagem de Internet para eles, mas esse trabalho demora.

IH — Quando você chegou no Mackenzie, havia um legado, e quando você sair, você vai deixar o seu legado. O seu legado é melhor?
Brito — Precisamos de uma equipe supercapaz, muito bem treinada, o que não é tão recomendável do ponto de vista estratégico, porque dependemos dessa equipe. Por outro lado, justamente por causa dessa equipe, nosso custo de operação é baixo.
Respondendo, nosso sistema está muito bom, mas sua segurança depende dessa equipe própria.
No nosso negócio, se o sistema de TI para, até as aulas presenciais param também, porque elas dependem de tecnologia. Então, se mantemos uma equipe enxuta para cuidar de uma área de TI essencial, temos de valorizar essas pessoas, treiná-las.
Acras — A NeoGrid se especializou em interligar empresas: por meio da nossa rede, as empresas compram e vendem. Já nascemos na Internet. Então, encontramos muitos legados, inclusive aqueles que o sobrinho do dono fez. Já vi empresa parar porque o sobrinho do dono faltou.
Com a nota fiscal eletrônica, nós nos surpreendemos: algumas empresas não conseguiam gerar o arquivo mínimo exigido pela Secretaria da Fazenda.
Nessa experiência, posso dizer que é tão difícil encontrar gente com prática em linguagens e sistemas antigos quanto encontrar aquele jovem que sabe Java e .NET. Temos dezenas de vagas assim em aberto, e temos dificuldade de preenchê-las.

IH — Qual é o mecanismo mais comum de troca de dados entre empresas?
Acras — O mais comum ainda é o arquivo de texto. Em várias empresas, a TI é só um centro de custos, com duas pessoas cuidando de 50, 100 usuários.

IH — Como é modernizar aplicativos num banco do tamanho do Bradesco?
Luiz — Estamos buscando as novas técnicas, com arquitetura SOA [arquitetura orientada a serviços, isto é, os sistemas prestam serviços padronizados, assim ninguém precisa se preocupar com a tecnologia dos sistemas], serviços reutilizáveis — tudo de moderno. Começamos a entregar sistemas este ano, e esse trabalho ainda vai nos consumir uns dois ou três anos.
Enquanto isso não acontece, temos de manter os sistemas do banco, sistemas para 40 mil pontos de atendimento, para 180 milhões de transações por dia.
Quando compramos um banco, às vezes compramos também tecnologias fora do nosso padrão, e algumas tecnologias fora de linha, sucateadas. Temos uma equipe só para renovar essas tecnologias, mas não podemos perder nem uma fração de segundo com esses legados e essas renovações. Algumas equipes usam ferramentas para evoluir, por exemplo, o código-fonte de aplicativos velhos.

IH — Quando vocês renovam um aplicativo, não fica mais vantajoso trocá-lo por alguma coisa mais nova?
Luiz — Mas essa renovação, muitas vezes, é quase uma substituição por uma coisa nova. Conseguimos modernizar um legado, modernizar a linguagem, a arquitetura, mantendo o desempenho.
Mas as áreas de negócio participam desse projeto desde o início. Elas olham para o legado e definem o que pode ser melhorado, definem melhor os requisitos dos sistemas. Assim a nova arquitetura já virá com algo a mais. Essa nova arquitetura deve dar mais funcionalidades para as áreas de negócio, mas o tempo de resposta de cada transação deve cair. Quando a gente ganha frações de segundo numa transação, faz diferença no fim do dia, se temos 180 milhões de transações para realizar.
Hélio — Para tirar um legado, tem o custo de desativá-lo. Às vezes, deixar uma aplicação do legado funcionando, num canto, é mais barato do que desativá-la.
Brito — Nós tentamos trocar o sistema de gestão acadêmica por um desses ERPs modernos. Selecionamos uma empresa e ela ficou três anos trabalhando nos ajustes. No fim, ficamos com o sistema velho, que há 20 anos nunca deixou a instituição um segundo na mão.
Quando a gente passeia pelo shopping, e entra numa loja das grande redes de varejo, vê que o pessoal usa aquela tela de caracteres verdes. Com dez cliques do mouse, o funcionário não faz o que faz com aquele legado de tela verde.
Fernando — Trocar qualquer legado é sempre traumático. Uso a estratégia de matar o legado por inanição: tiro alguma coisa dele e atualizo, e assim vai.
Na época em que o banco instalou os primeiros sistemas de informática, não tinha metodologias, ou documentação, ou desenvolvimento em camadas, ou terceirização.
Hoje, com o Société Générale, o dono francês, existe uma grande preocupação com governança, com novas metodologias para desenvolver sistemas.
Com o tempo e a governança, a gente acaba descobrindo como as pessoas têm o péssimo hábito de colocar funcionalidades num sistema e depois usá-las para o que elas não foram feitas. A gente faz um sistema de acordos e cobranças, que emite boleto avulso, e de repente tem gente usando o sistema não para fazer acordos ou cobranças, mas para emitir boletos. Esse é um dos problemas que eu procuro matar por inanição.
Alguns legados nós mantemos; outros, criamos camadas em torno dele. Estou usando o seguinte conceito na modernização: eu quero ver o usuário o menos possível; talvez só na festa de final de ano.
Eu não quero ver um técnico usar o Cobol para extrair informações para o usuário; eu quero montar um banco de dados, um sistema de BI, para que o usuário se sirva das informações. A função do legado é cuidar do essencial.
Conforme o tempo passa, vamos criando um sistema em camadas, e vamos tirando do legado as atividades que não pertencem ao legado, para ganhar eficiência. Hoje já existem ferramentas para tirar do Cobol, por exemplo, aquelas regras sobre o parcelamento das prestações, que ficariam melhor num sistema à parte, mas que hoje está muito intrínseco no Cobol.
Luiz — A vantagem disso é ter componentes corporativos: a gente altera aquele componente, e automaticamente todo o sistema enxerga a alteração, por exemplo a nova porcentagem. Hoje, com os legados, a gente tem de fazer a mesma alteração em vários sistemas. Essa é a vantagem da arquitetura SOA.
Carlos — Em 1998 [quando o banco foi fundado], decidimos que o Banco Alfa não teria legados, porque o proprietário de um legado tem a obrigação de renová-lo, de mantê-lo vivo. Fomos ao mercado e trouxemos pacotes de mercado, para cada uma das áreas de negócio do banco. Pois, convenhamos, contabilizar um crédito direto ao consumidor é a mesma coisa no Alfa, no Bradesco, no Cacique. Então, compramos essa funcionalidade de um terceiro, e compartilho o custo dessa funcionalidade com os outros 20, 30 clientes desse terceiro.
O segredo dessa estratégia é mapear direitinho, em cada unidade de negócios, o que é essencial e o que não é essencial. Esse mapeamento serve para descobrir o que deve ser feito dentro de casa.
Um pouco depois, em 2000, o problema era integrar os pacotes. Mas nós criamos uma arquitetura baseada em componentes corporativos, que mais tarde ganharia o nome de SOA. Essa arquitetura de integração é toda do Alfa — a gente detém o conhecimento. Como a gente montou do zero, essa arquitetura está bem constituída, o que os órgãos reguladores gostam muito. Eles veem que ela está na nossa mão, e não na mão do fornecedor.
Se mudou o IOF, a gente muda um componente corporativo, e pronto. Está mudado o IOF no sistema inteiro.
Tem regra de negócio no legado? Tem. Acontece. Mas o nosso esforço de gestão é ao contrário: não queremos deixar regras de negócio no legado.
Hoje, a gente constrói um novo produto em duas, três semanas. Antigamente, demorava um ano e meio.

IH — Por que as regras de negócio têm essa compulsão de ir parar no legado?
Carlos — Porque a área de negócios não pode esperar, e se não dá tempo de fazer do melhor jeito, a gente faz do pior, porque banco não perde negócio. Às vezes, o caminho mais curto e mais fácil é o caminho do legado.
Luiz — De quebra-galho, fica permanente.
Carlos — Quando a gente põe uma arquitetura e, com ela, atende a área de negócios com a mesma velocidade, as regras de negócios param de ir para o legado.

IH — Quando vocês identificam uma regra de negócio no legado, o que vocês fazem?
Carlos — A ideia é tirar e trazer para a camada de negócios, ligada à arquitetura de integração. Fazemos isso constantemente. Com a crise, os bancos do nosso tamanho mudaram a estratégia e, com isso, muito código que era estratégico, e que estava no legado, hoje não é mais estratégico, e estamos passando esse código para um dos produtos de mercado.
Somos um condomínio, com 25 fornecedores e 55 sistemas de terceiros
A ideia do condomínio é muito interessante, a gente usa esse termo com os fornecedores, é um condomínio que tem 25 fornecedores e 55 sistemas de terceiros. Já trocamos fornecedores e a área de negócios nem percebeu a troca.
Assim, esses sistemas não são nossos, na verdade: eles são do fornecedor, que tem de cuidar das linhas de código, que tem de cumprir os nossos SLAs, os nossos tempos de resposta, etc.
Walter — O fornecedor não percebe quando vocês planejam trocar de fornecedor? Ele não coloca umas dificuldades no sistema dele?
Carlos — O fornecedor não sabe direito o que ele está fornecendo: ele fornece o que chamamos, no Alfa, de primitivas funcionais. Um débito na conta-corrente, uma consulta a saldos, essas coisas são primitivas funcionais. Temos mais de 350 primitivas funcionais catalogadas. São componentes de software, interligados à arquitetura de integração. O fornecedor não sabe direito o que a gente monta com esses componentes básicos; a nossa esteira de crédito ao consumidor [esteira é a sequência de atividades para que um negócio se realize] é propriedade nossa. Mas montamos essa esteira com 170 primitivas funcionais, que são propriedade dos nossos fornecedores.
Assim, um fornecedor nunca fala com outro fornecedor. Ele sempre fala com o Alfa.
É 100% transparente? Nunca é 100% transparente, mas reduzimos muito o nosso grau de dependência de fornecedores.

IH — Você sabe explicar como surgem os legados?
Carlos — Se o executivo pensa num negócio novo e chama a área de TI imediatamente, a empresa está integrada, e há menos legados. Se o executivo não chama a área de TI, mas passa um pedido, não está integrado. Eu tenho esse indicador. Se os pedidos vêm por meio dos analistas da TI, a empresa e a área de TI estão alinhadas.
Mas tem um ditado que diz: cada escolha traz uma renúncia. Até que esse modelo funcionasse bem, até que não dependêssemos mais de fornecedores, foram anos de inferno. Os primeiros três anos foram terríveis, porque o fornecedor não quer abrir mão, não quer ficar frágil.

IH — Como são os legados num supermercado?
Walter — O Tenda Atacado existe há oito anos, mas estou há dois meses lá. Temos um centro de distribuição e 12 lojas, e estamos inaugurando umas três novas lojas por ano.
Usamos alguns módulos da SAP. Mas, para nós, o sistema do PDV [o ponto de vendas, ou seja, o caixa do mercado] é o mais importante. É o momento de maior tensão, porque precisa funcionar, e porque o preço no PDV precisa ser o mesmo preço da etiqueta. É uma dificuldade enorme manter o preço igual.
O PDV é um sistema muito complexo, e por isso não usamos um ERP; o PDV foi construído internamente.
Nosso sistema de compras também é importante, e também é um legado; foi desenvolvido para a web, mas é um legado.
Algumas interfaces com o nosso ERP são lentas, e não resolvemos toda a parte de relatórios. Isso porque a empresa cresceu mais do que esperávamos, e agora estamos correndo atrás.
Acho muito importante também considerar as pessoas e os processos como legados. Boa parte dos nossos processos depende de TI, e está na cabeça de funcionários da TI. Isso para nós é um problemão.
O usuário quer o resultado final, mas não quer saber o que está ali no meio, às vezes nem quer saber do desenho do processo.
Por exemplo: ele não entende o que é um erro de digitação no cadastro, que pode gerar uma nota fiscal eletrônica incorreta. Quando isso acontece, houve falha no processo, mas o usuário acha que houve uma falha na TI — que a área de TI não está atendendo.
Estamos montando um esquema de governança para acabar com isso. Cada área deve tomar conta dos seus próprios processos, e também dos seus próprios sistemas; nós estamos lá para apoiá-las.
Temos dificuldade de colocar esse esquema em prática, porque as pessoas ainda não conseguem pensar em processos. Mas aos poucos o esquema vai ganhando corpo.
Por exemplo: o usuário vai faturar, mas o sistema mostra um erro A2, que significa cliente sem crédito. Hoje, ele vem reclamar com a área de TI, dizendo que aquele erro A2 está atrapalhando o trabalho dele. Nós estamos direcionando o usuário para a área financeira, porque erro A2 faz parte do processo financeiro. Estamos fazendo isso há só três semanas e já tivemos resultados.
Outra coisa que acho importante: por que queremos tirar o legado? Quando vamos investigar, descobrimos um problema no servidor, um problema no processo. O usuário reclama: tira esse legado da minha frente, é muito lento. Então, vamos resolver o problema da lentidão. Às vezes, basta redesenhá-lo, recompilá-lo, colocá-lo num servidor novo e pronto — o legado vira o sistema que o usuário sempre quis.
Quando a gente decide não mexer no legado, sobra dinheiro, e se abre todo um leque de possibilidades.
Outro erro, semelhante a esse, é manter um legado a qualquer custo. Já cheguei a refazer o instalável de um legado, cheguei a procurar as DLLs velhas, de tão legado que o legado era. Deu certo — porque, quando a área de TI banca o herói, sempre dá certo.