O desafio que encontramos quando assumimos a área de TI da Ultragaz não eram muito diferentes daqueles enfrentados pelos diversos departamentos de tecnologia da informação: ser mais eficiente e eficaz nas soluções geradas. O nosso parque contava com um ERP implementado há bastante tempo e com um elevado nível de personalizações e uma série de aplicativos satélites, funcionais e tecnologicamente defasados, todos com uma grande dificuldade de manutenção. Para resolver esta questão, montamos um programa de renovação do departamento de TI, composto por quatro projetos principais: revisão da estrutura organizacional da área, definição dos processos internos (gestão de demanda, de projetos, ciclo de vida de desenvolvimento etc), orientação aos analistas ao conhecimento e discussão dos processos de negócio da companhia e, por último, renovação do parque tecnológico. Detalharei este último ponto.
Arquitetura de referência
A maioria dos nossos aplicativos estava construída em uma arquitetura cliente-servidor, combinada com workflow para a automatização de processos de aprovação. Porém, não conseguíamos com clareza diferenciar o escopo de atuação de cada ferramenta – muitas vezes tínhamos, ao mesmo tempo, uma única ferramenta, na mesma tecnologia, focada em dar apoio à tomada de decisões e na automação de processo. Como é de se imaginar, a tecnologia acabava não fazendo bem nenhuma das duas coisas.
Para resolver esta questão, definimos claramente uma arquitetura de referência composta basicamente por cinco conceitos/camadas: (1) sistemas transacionais; (2) motores de processos; (3) sistemas de consolidação de dados/apoio à decisão; (4) camada de apresentação; (5) utilização dos conceitos de SOA visando ao reaproveitamento de componentes, integrações, regras de negócio e até mesmo processos de negócio. Assim o trabalho começou: promovendo alinhamento entre os processos de negócio, indicadores, relatórios e as tomadas de decisão!
A renovação tecnológica partiu de duas grandes iniciativas: adoção de ferramentas de business intelligence (BW/BI) e business process management system (BPMS). Estes dois projetos andam em paralelo, disponibilizando e consumindo dados e indicadores constantemente, em via de mão dupla. Este foi um pulo do gato!
Em um primeiro momento isto parece aumentar a complexidade da implementação dos projetos, mas, em contrapartida, ajudou a garantir o sucesso de todo o trabalho. A utilização do data warehouse como fonte padrão de todos os indicadores e informações na companhia – diferentemente dos silos de dados dos aplicativos anteriores – garante a consistência e o alinhamento entre os processos de negócio, indicadores, relatório e as tomadas de decisão.
Explico isso por meio de um exemplo: o diretor analisa um relatório que apresenta o volume de vendas para um determinado cliente e, ao mesmo tempo, um serviço (SOA) disparado por um processo no BPMS utiliza exatamente a mesma informação para o acompanhamento da rentabilidade deste mesmo cliente. Um processo pode então ser disparado para que uma ação seja tomada, antes mesmo do diretor solicitar.
Como esta regra de rentabilidade foi construída como um serviço, todos os processos que orçam, acompanham, recalculam ou atualizam a rentabilidade deste determinado cliente “chamam” o mesmo serviço e realizam exatamente o mesmo cálculo. Obviamente, este é um trabalho árduo e que está sendo implementando para cada novo processo que decidimos atacar.
Reutilizando com o BPM
A arquitetura que definimos para a camada de automação de processo é basicamente composta por telas desenvolvidas em Java (JSF) e conceitos de serviços para construção de regras de negócio, consultas e integrações, diminuindo o acoplamento com os transacionais e aumentando consideravelmente a reutilização. Isto nos deu a possibilidade de portar os processos de uma ferramenta para outra, o que já foi inclusive testado e funciona.
Quando a ferramenta atual não nos atender mais, a exceção de algumas “extensões” que temos de classes da mesma (não chegam a 10% do desenvolvimento), podemos migrar totalmente o processo, isto é, mesmo se decidirmos trocar o “motor do processo”, o usuário final não sentirá essa alteração. A combinação destes dois conceitos e tecnologias, BI e BPM, foram implementadas visando a “blindar” os usuários, preparando-os para a fase que está por vir: a revisão da camada transacional, principalmente o ERP.
Apenas começando
Em vez de customizações, processos de negócio que tratam as especificidades do negócio e implementam regras complexas como um complemento ao ERP, consumindo, chamando ou atualizando as suas transações “standard”. No lugar de intermináveis extrações de dados e planilhas gigantescas que invadem e incham a nossa rede, geram análises inconsistentes e confusas; uma ferramenta feita para a geração de indicadores e relatórios, com dados saneados, indicadores consistentes e um poder muito maior de análise. Já chegamos a isso? Infelizmente ainda não. Esta batalha está apenas começando.
*Rodrigo Ferreira é coordenador do departamento de TI desde 2007 e responsável pelo projeto de implementação dos conceitos e ferramentas de BPMS na Ultragaz. Atuou como consultor everis consulting de 2003 a 2007 (principais clientes/projetos: Laboratórios Fleury, Suzano Papel e Celulose, Banco Santander, Confederação Nacional da Indústria, Editora Saraiva, Livraria Saraiva). É Engenheiro Eletricista formado pela Unicamp
