Uma Abordagem para Modelagem de Processos através de um ERP

Uma Abordagem para Modelagem de Processos através de um ERP Alberto Kenji Ogura (Universidade Estadual Paulista) al_ogura@yahoo.com.br Fernando Augusto Silva Marins (Universidade Estadual Paulista) fmarins@feg.unesp.br Resumo Os sistemas de gestão empresariais estão em constante evolução e, ultimamente, transformaram-se em uma ferramenta para a gestão da cadeia de suprimentos. Estes sistemas tem um fluxo de informação bem definido, que reflete a maneira como uma empresa trabalha ou como o ERP deve se adaptar aos modelos da empresa. Assim, freqüentemente, é preciso adaptar a arquitetura de processo de um ERP para o modelo de negócios da empresa que deseja implementá-lo. Entretanto, em diversas ocasiões, estas adaptações nem sempre são necessárias, resultando em desperdício de tempo e de recurso. Para isso, é possível desenvolver uma arquitetura de processos que faz a conexão entre responsabilidade, processos de negócio e procedimentos operacionais no ERP a partir do tipo de empresa, resultando em uma arquitetura específica para determinadas situações. Palavras chave: Implementação de Aplicativos, Arquitetura de Processo, Enterprise Resource Planning. 1 Introdução Os sistemas de informação estão em evolução contínua desde que os processos produtivos e a cadeia produtiva começaram a despertar o interesse da alta administração. Em pouco tempo, houve uma evolução que consistiu no surgimento do MRP (Material Requirements Planning), passando pelo MRPII (Manufacturing Resources Planning) e chegando ao Enterprise Resource Planning - ERP (STAIR, 1999). A tendência atual da área de sistemas de informações gerenciais é de, não apenas visualizar a empresa isoladamente, mas toda a cadeia de suprimento, conseguindo realizar o planejamento estratégico e tático globalmente para a cadeia, além do operacional para a empresa. Para isso, estão sendo desenvolvidos softwares de gestão - novas ferramentas para atuar tanto em uma ponta da cadeia, no caso dos clientes com o CRM (Customer Relationship Management) (CHLEBA, 2001) até a outra ponta dos fornecedores, que são os sistemas de apoio à decisão (SAUTER, 1996). A introdução de um ERP em uma empresa tem um impacto enorme em todas as operações que são realizadas diariamente em suas instalações. Os sistemas ERP são atraentes porque unificam a informação, pois, segundo Oliveira e Ramos (2002), surgiram com a promessa de resolver problemas de integração, disponibilidade e confiabilidade de informações ao incorporar em um único sistema as funcionalidades que suportam diversos processos de negócios em uma empresa. Este trabalho procura apresentar uma proposta de arquitetura de processos que segue a lógica de informação de um ERP para diminuir algumas fases da implementação de um sistema de informação integrado, apresentando suas características, vantagens e desvantagens dessa nova proposta de arquitetura de processos. ENEGEP 2003 ABEPRO 1

O artigo está estruturado da seguinte maneira: na próxima seção é feita uma revisão bibliográfica sobre arquitetura de processos. Na terceira seção mostra-se o modelo de arquitetura de processos desenvolvido para um ERP e finalmente, na última seção apresentase as conclusões do trabalho. 2 Arquitetura de Processos de um ERP Uma das fases anteriores à implementação de um ERP é o desenho da nova arquitetura de processos da empresa. Para Martins e Bremer (2002), a integração e a visão por processos de negócios surge como meio potencializador para alcançar a eficiência e sincronia das empresas no mercado competitivo global. Nesta análise de processos, existem duas possibilidades a serem seguidas, a reengenharia e/ou o redesenho de processo: no processo de reengenharia, da forma concebida por Hammer e Champy (1994), parte-se de uma folha em branco, modelando-se todos os processos; já pelo método de redesenho de processo, segundo Scheer (1998) realiza-se uma remodelagem considerando os processos existentes e o conhecimento de seus executores. Scheer e Habermann (2000) afirmam, ainda, que o processo de implementação deve envolver a análise dos processos atuais do negócio e, principalmente, a possibilidade de modificá-los posteriormente. Para Vernadat (1996), a modelagem de processos tem por finalidade obter: uniformização do entendimento da forma de trabalho, gerando integração; análise e melhoria do fluxo de informações; explicitação do conhecimento sobre os processos, armazenando assim, knowhow organizacional; realização de análises organizacionais e de indicadores (processos, financeiros e outros); e realização de simulações, apoiando a tomada de decisões. Rozenfeld (1999) considera que a modelagem de processos de negócios compreende um conjunto de atividades realizadas na empresa, associadas às informações que manipula, utilizando os recursos e a organização da empresa. Forma uma unidade coesa e deve ser focalizado em um tipo de negócio, que normalmente está direcionado a um determinado mercado/cliente, com fornecedores bem definidos. 3 Arquitetura de Processos de um ERP De acordo com Corrêa e Gianesi (2001), a arquitetura de processos de um ERP é o fluxo de informações de várias áreas de negócio de uma empresa que se agrupam, formando um processo de atendimento às necessidades do mercado, conforme ilustrado na Figura 1. Nesta, vê-se as principais entidades de um ERP e o encadeamento entre estas, formando um fluxo de informação, que é, também a arquitetura de processos de um ERP. ENEGEP 2003 ABEPRO 2

DRP Vendas/ Previsão Faturamento Gestão de transportes S&OP ERP Contabilidade Geral Custos RCCP MPS MRPII Workflow Gestão de Ativos Recursos Humanos CRP MRP Folha de Pagamento Contas a Pagar PUR SFC Gestão Financeira Contas a Receber Recebimento fiscal Manutenção Figura 1 - Arquitetura de Processos de um ERP Fonte: Correa e Gianesi (2001) Em um processo de implementação, o primeiro passo é determinar o escopo do projeto e a nova arquitetura de processo. Atualmente, durante esta definição, é utilizado o enfoque da reengenharia de Hammer (1994), ou seja, parte-se de uma folha em branco e tenta-se adaptar o sistema ao processo da empresa. A proposta deste artigo inverte esta tendência ao determinar como a empresa deve se adaptar ao sistema e, também, qual é a estrutura organizacional sugerida de forma a atender os requisitos da arquitetura do ERP, fazendo a conexão entre o sistema, responsabilidade e procedimento de negócio. Caso haja uma função que não é exercida atualmente na empresa, cria-se um cargo ou adiciona-se estas atividades nos procedimentos de trabalho de um cargo e/ou função já existentes. Além disso, a arquitetura tende a ser personalizada para mercados específicos (Marketplace), por exemplo, segmenta-se uma determinada arquitetura para as empresas químicas, outra para bancos e outra para manufatura Just-in-Time. A experiência mostra que as empresas que se encontram no mesmo marketplace trabalham de forma parecida. Outro argumento interessante para que haja essa segmentação de arquiteturas por tipo de mercado, é que se realizará um benchmarking com as melhores práticas do mercado, para este segmento, de empresas de classe mundial, bem como se buscará identificar os indicadores de processo utilizados por este marketplace. Esta arquitetura com as melhores práticas seria o resultado de uma série de experiências com empresas do mesmo marketplace, entretanto, deixando a possibilidade de modificá-la para ajustes específicos. Ao trazer uma visão sistêmica do processo global da empresa, a arquitetura pode ajudar a rastrear erros durante o processo. Um dos maiores problemas nas implementações está no fato dos usuários serem treinados para um módulo específico, tendo pouca ou nenhuma ligação com o restante de um determinado processo. Por exemplo, imagine-se o processo de vendas de produtos de uma determinada empresa: para atender a um determinado pedido de venda, ENEGEP 2003 ABEPRO 3

são necessários diversas pessoas de áreas diferentes, como mostrado na Figura 2. No lado esquerdo desta figura estão localizadas possíveis áreas responsáveis, enquanto que nas caixas se tem as funções, decisões ou atividades desenvolvidas neste processo. Assim, é possível visualizar quais as áreas (Vendas, Planejamento, e Compras) que necessitam estar envolvidas neste processo. Vendas Entrada de Pedido (Produto, Qtde., Data, Cliente) Tem Estoque? Sim Não Envia para a Manufatura Planejamento Sim Tem Estoque de Materiais? Não Compras Compra Fabricar Produto Fabricar Produto Vendas Atende o Pedido Figura 2 - Processo simplificado de Vendas de Produto Deste modo, ao envolver todos os responsáveis por estas atividades, cria-se a visão por processos, sistêmica, que além de ajudar no entendimento do fluxo da informação e de seu processamento dentro do sistema, não deixa propagar erros e vícios para a etapa seguinte. Dentro deste desenho, é possível desenvolver e detalhar ainda mais cada subprocesso: tome-se como exemplo, Processo de Fabricação na Figura 3. Como na Figura 2, posicionam-se do lado esquerdo as responsabilidades, e nas caixas os eventos deste fluxo. Verifica-se que o input de informações para o fluxo da Figura 3 tem origem no fluxo da Figura 2, ou seja, receber o pedido de liberação da ordem de produção através do planejamento. Existe também a possibilidade de receber o pedido de liberação da ordem de produção através do departamento de compras, como nos casos de um processo make-tostock. ENEGEP 2003 ABEPRO 4

Processo de Planejamento Gerente de Receber Pedido de Fabricação Abre Ordem de Almoxarife Separa material para a Ordem de Montador Realiza a montagem e aponta no sistema Inspetor de Qualidade Realiza Inspeção de Qualidade Figura 3 Fluxo do Processo de Processo de Venda No caso do Processo de apresentado na Figura 3, já é possível verificar uma ligação entre fluxo de processo e procedimentos operacionais de cada atividade. Ao relacionar a arquitetura de um processo com atividades operacionais de uma aplicação ERP, verifica-se que é possível utilizar esta ferramenta para outras atividades como testes integrados e treinamento, por exemplo, diminuindo os tempos de confecção de manuais e documentos. As métricas para aferição do desempenho podem ser estabelecidas, de acordo com a necessidade, para os outputs de cada atividade. Por exemplo, na Figura 3, após a etapa de realização da montagem e apontamento no sistema é possível verificar se o lead time de fabricação está correto ou dentro de uma tolerância aceitável. É possível estabelecer também um indicador que verifique se a data de finalização da montagem foi igual ou menor que a data estipulada para o embarque, de modo a atender seus clientes no momento certo. 4 Conclusão Com este novo enfoque de arquitetura de processos, espera-se vantagens no tempo de implementação e treinamento. A elaboração da Arquitetura de Processos permite visualizar o fluxo de informações de um ERP de maneira holística, melhorando o rastreamento de problemas. Com uma Arquitetura de Processo pré-definida, não é preciso sair de uma folha em branco para definir quais os processos que serão atendidos pela implementação de um ERP. As responsabilidades por cada atividade estão pré-definidas, auxiliando a empresa que compra o ERP a definir o que falta em sua estrutura organizacional para atender a arquitetura proposta. Ainda, ao segmentar as arquiteturas por marketplace, a necessidade de adaptação é menor. ENEGEP 2003 ABEPRO 5

Entretanto, serão necessários estudos posteriores para comprovar se a aplicação desta proposta de Arquitetura de Processo efetivamente otimiza os processos de implementação mencionados. Também é necessário verificar se a arquitetura de processos de um ERP determina o modo como a empresa compradora do software terá que se adaptar. Alguns casos podem se encaixar perfeitamente, em outros a implementação pode ser traumática. É esperado que, por menor que seja o impacto da implementação, sempre haja custos relacionados a mudanças estruturais para que a empresa se adapte à Arquitetura de Processos do ERP, e vice-versa. Na elaboração do ROI - Retorno Sobre Investimento, essas mudanças estruturais nunca são considerados apesar terem impacto razoável sobre o custo do projeto de implementação. Não é o objetivo deste trabalho determinar quais são estes custos, nem a metodologia necessária para tal, entretanto, estes mesmos custos devem ser levados em conta ao elaborar o ROI. Além disso, é preciso verificar qual o impacto do trade-off desta mudança nos procedimentos diários de trabalho. Afinal, qual seria o custo de aplicação desta proposta em uma empresa que não está preparada para mudanças na maneira como trabalha? Finalmente, é preciso considerar, também, que as empresas tem administrações e culturas únicas, apesar de haver procedimentos semelhantes ou até iguais, o que pode dificultar a aplicação da Arquitetura de Processo proposta. 5 Referências CORRÊA, H. L., GIANESI, I. G. N., CAON, M (2001), Planejamento, Programação e Controle da, 4 ed. São Paulo, Editora Ática. CHLEBA, M. (2001), Marketing na Web, Jornal do Comércio do Rio de Janeiro. http://www.jornaldocommercio.com.br/175anos/br_pressa/panorama12.htm (acesso em 19/4/02). DAVENPORT, T. H. (2000), Does ERP build a better business?, CIO Magazine. Fevereiro. HAMMER, M., CHAMPY, J. (1994), Reengenharia: repensando a empresa m função dos clients, da concorrência e das grandes mudanças da gerenciar. 1 ed. Rio de Janeiro: Ed. Campus. MARTINS, V., BREMER, C. F. (2002), Proposta de uma ferramenta de integração entre sistemas ERP- SCADA: Caso Prático. In: XXII Congresso Brasileiro de Engenharia de. Anais. Curitiba. OLIVEIRA, M. A.; RAMOS, A.S.M, (2002), Fatores de Sucesso na Implementação de Sistemas Integrados de Gestão Empresarial (ERP): Estudo de Caso em uma Média Empresa. In: XXII Congresso Brasileiro de Engenharia de. Anais. Curitiba. PADILHA, T. C. C., MARINS, F. A. S. (2002), Sistemas ERP: Características, Custos e Tendências. In: XXII Congresso Brasileiro de Engenharia de. Anais. In: XXII Congresso Brasileiro de Engenharia de. Anais. Curitiba. SANTOS, R. P. C., et al. (2002), Engenharia de Processos de Negócios: Aplicações e Metodologias. In: XXII Congresso Brasileiro de Engenharia de. Anais. Curitiba. ROZENFELD, H. (1999), Integração de Empresas CIM Disponível em <http://www.numa.org.br>. Acesso em: Maio de 2002. SANTOS, R. P. C., CAMEIRA, R. F., CLEMENTE, A. A., CLEMENTE R. G. (2002), Engenharia de Processos de Negócios: Aplicações e Metodologias. In: XXII Congresso Brasileiro de Engenharia de. Anais. Curitiba. ENEGEP 2003 ABEPRO 6

SAUTER, V., (1996) Decision Support Systems: An Applied Managerial Application. 1 ed. New York: IE- Wiley. 432 p. SCHEER, A. W., (1998) Aris Business Process Framework. 2 ed. Berlim: Springer Verlag. SCHEER, A. W., HABERMANN F. (2000), Making a ERP Sucess Association for Computing Machinery Communications of the ACM. New York, Apr, 57-61. SLACK, Nigel (2000) Administração da. Ed. LTC. São Paulo. STAIR, R. M., (1998), Princípios de Sistemas de Informação: uma Abordagem Gerencial, 2 ed. São Paulo: Editora LTC. VERNADAT, F.B. (1996), Enterprise Modeling and Integration: principles and applications. 1 ed. Chapman & Hall, London. ENEGEP 2003 ABEPRO 7