Projetos de ERP

As organizações normalmente enfrentam desafios quando tentam implementar iniciativas de mudança em BPM. Um cenário bastante comum e sujeito a estes desafios ocorre na implantação de Projetos de ERP (Enterprise Resource Planning). Estes sistemas são responsáveis pelas atividades chaves de qualquer empresa,  geralmente implicando em mudanças de processos críticos de setores como produção, serviços, RH, financeiro, logística, distribuição, entre outros e, portanto, envolvendo todos os colaboradores que fazem a empresa, do nível operacional ao estratégico.

Muitas empresas estão atualizando seus projetos de ERP devido à evolução de tecnologias como computação em nuvem e Big Data. Elas buscam plataformas baseadas em serviços para reduzir custos e integrar melhor a empresa à sua cadeia de valor, visando aumentar a eficiência do negócio. No entanto, essas mudanças trazem desafios significativos, incluindo a necessidade de novas competências, papéis diferenciados e uma mudança cultural que nem todos na organização estão preparados para enfrentar.

Desafios em Projetos de ERP

Projetos ERP frequentemente enfrentam falhas devido à má administração dos riscos de implantação, associados a fatores críticos de sucesso do projeto, conforme relatam Santos et al. (2018). A Abas ERP, empresa americana especializada em implantação de ERPs no mercado automotivo e de eletrônicos, destacou problemas comuns em tais projetos: falta de clareza nos objetivos, comprometimento deficiente da gestão, falta de competências no time de projeto (incluindo gestores, usuários e profissionais de TI), comunicação inadequada, processos atuais mal definidos, subestimação da migração de dados e resistência à mudança (Abas ERP, 2018).

Estes desafios destacam a importância do envolvimento das pessoas interessadas no projeto durante mudanças organizacionais, enfatizando a necessidade de uma comunicação efetiva que não se limite apenas a mensagens e apresentações unidirecionais. O sucesso em programas de mudança de processos de negócios requer uma comunicação eficiente que apoie as transformações organizacionais, envolvendo as pessoas afetadas por elas, conforme destacado por Prata & Santos (2019). O objetivo é garantir que os funcionários compreendam as prioridades de negócios, orientando suas decisões e atividades, promovendo comprometimento, confiança e lealdade com as mudanças. Neste sentido, as empresas podem usar o BPM como estratégia de comunicação, envolvendo os funcionários na exposição de seus processos atuais e no entendimento das mudanças que esses processos enfrentarão com a implantação do novo ERP.

Analistas de Processos x Especialistas de Domínio

As atividades iniciais de um projeto de ERP coincidem com as etapas iniciais do ciclo de vida de BPM, que incluem a identificação, a descoberta e a análise de processos de negócios, de acordo com Dumas (2013). Em geral, estas etapas são conduzidas por analistas de processos, que visam identificar processos, detalhando suas tarefas, produzindo modelos de processos que esclarecem como os procedimentos de trabalho são realizados (modelos AS-IS) e como eles podem ser aprimorados (modelos TO-BE). No entanto, muitas organizações, em particular aquelas com baixa maturidade em BPM, sofrem com a falta de informações provenientes de documentações de processos desatualizadas, inconsistentes ou inexistentes. E neste contexto, a principal fonte de informação sobre processos são as pessoas envolvidas na execução deles, isto é, os especialistas de domínio (usuários, proprietários, gerentes).

De acordo com Luebbe e Weske (2012), levantar processos por meio de interações entre analistas de processos e especialistas de domínio não é uma tarefa fácil. Tradicionalmente, os analistas de processos entrevistam especialistas em negócios, coletam informações e as traduzem em modelos de processos. No entanto, especialistas em domínio geralmente não estão familiarizados com o pensamento e as notações de processos, portanto, nem sempre fornecem feedback significativo.

Outro problema comum durante a modelagem de processos é que o analista de processos pode interpretar informações incorretamente porque não está familiarizado com o processo, gerando um modelo incompleto ou até errado. Finalmente, falhas durante a modelagem de processos geram retrabalho, custos desnecessários e comprometem a confiança das partes interessadas, impactando diretamente na eficácia da comunicação das mudanças. Tudo o que a gente não precisa!

BPM e Design Thinking

Com o propósito de apoiar interações colaborativas entre analistas de processos e especialistas de domínio, algumas propostas vêm se apropriando de princípios de design (design thinking), aproximando as pessoas envolvidas e seus processos num trabalho colaborativo e estimulante, como no exemplo mostrado por Cereja et al. (2017). Brown (2009) define sete princípios de design que podemos aplicar com esse objetivo:

• P1. Centrado no humano: as pessoas que participam da identificação e modelagem de processos são o recurso mais importante e devem ser valorizadas;
• P2. Colaboração: todos os participantes devem poder colaborar para a construção coletiva do modelo de processo, fazendo com que todos se sintam responsáveis pelo resultado do trabalho;
• P3. Experimentação: precisamos procurar maneiras diferentes de modelar processos e quebrar barreiras, permitindo que especialistas em domínio possam modelar seus processos;
• P4. Reflexivo: é importante que o processo seja observado sob diferentes aspectos, permitindo uma maior discussão sobre eles;
• P5. Equipes multidisciplinares: promover o encontro de pessoas de diferentes áreas e funções relacionadas ao processo é fundamental, a fim de favorecer vários pontos de vista sobre o processo e permitir um maior detalhamento e compreensão em diferentes perspectivas;
• P6. Estímulo ao pensamento: permitir que não-designers pensem como designers, criando soluções; além disso, a proposta procura garantir que os analistas de domínio possam obter um pensamento de processo para que possam analisá-los, pensar nos problemas enfrentados e talvez propor possíveis melhorias;
• P7. Novas formas de pensar sobre o problema: neste contexto, pensar sobre os processos, estimulando a compreensão de suas melhorias.

Interação entre Analista de Processos e Especialistas de Domínio

Com base nesses princípios, Dutra (2015) definiu um método de interação entre analista de processos e especialistas de domínio em quatro etapas. Este método pode ser aplicado no formato de oficinas de curta duração (workshops) divididas em períodos de  3 a 4 horas.

1a. etapa: Preparação para a modelagem

Essa etapa é muito importante, pois a equipe precisa de um ambiente apropriado. Algumas instruções que podem ajudar:

• Selecione o ambiente: é importante selecionar um local livre de distrações, favorecendo a atenção de todos os envolvidos;
• Procure garantir a disponibilidade dos participantes: é importante garantir que todas as principais partes interessadas estejam totalmente engajadas na atividade durante o período proposto, considerando as características centradas no ser humano, colaborativas e multidisciplinares dos princípios de design (P1, P2 e P5);
• Prepare a ferramenta de modelagem: é importante preparar a ferramenta de modelagem para que ela esteja pronta para uso e disponível para os participantes durante a atividade de modelagem que incentiva a experimentação (P3). Você pode usar recursos simples como post-its, quadro branco e pincéis, para flexibilizar o desenho de processos com a participação de todos. A imagem abaixo mostra um kit simples e fácil de usar.

2a. etapa: Introdução aos conceitos essenciais

O analista de processos inicia o workshop, apresentando à equipe os conceitos essenciais para executar a tarefa, estimulando o raciocínio do processo (P6). Alguns exemplos de conceitos essenciais: Apresentação dos objetivos da organização com a realização da tarefa; Discussão da metodologia que será usada para modelagem; Introdução dos conceitos básicos de BPM, modelagem de processos e notação a ser utilizada (por exemplo, BPMN); Apresentação da ferramenta de modelagem de processos colaborativos. A ideia é manter todos alinhados e preparados para as próximas etapas.

3a. etapa: Modelagem dos macroprocessos

A fase de identificação deve identificar as principais características e tarefas do macroprocesso. Recomenda-se que o analista realize uma entrevista semi-estruturada, orientada por perguntas que ajudem a entender o escopo geral do processo, que funcionará como guia de apoio à modelagem. Exemplos de perguntas que podem ser usadas: Quais os objetivos do processo? Quem são os clientes e fornecedores? Por que ele é importante? Quando e como ele começa e termina? Quais as atividades mais importantes? Depois que as perguntas para identificação das macro tarefas forem respondidas, fornecendo novas formas de pensar sobre o processo (P7), o participante deve resumir o entendimento do macro processo e suas principais atividades, refletindo sobre vários aspectos do processo (P4).

4a. etapa: Modelagem dos detalhes do processo

Nesse ponto, as tarefas macro já estão identificadas e é hora de aprender os detalhes, como responsabilidades, interações, transições, regras e eventos. Primeiro, é necessário apresentar os elementos de modelagem da ferramenta, lembrando os conceitos básicos da notação que vamos utilizar.

Para demonstrar o uso da ferramenta aos participantes, o analista pode representar as tarefas macro e, ao mesmo tempo, já demonstrar o uso da ferramenta, criando um guia de referência. Os participantes devem incentivar o detalhamento de cada macro tarefa, de acordo com a fase de descoberta. Este método de design top-down pode ajudar a descobrir mais detalhes sobre a tarefa macro, examinando cada tarefa até atingir o nível de detalhe desejado. Essa atividade centrada no humano (P1) promove o pensamento reflexivo, o processo de pensamento e novas formas de pensar sobre o problema (P4, P6 e P7).

O analista de processos pode intervir fazendo perguntas sobre o processo para garantir o uso correto dos conceitos de modelagem. No entanto, é importante que ele não interfira tirando conclusões sobre as atividades, pois isso pode diminuir a participação de especialistas em negócios e torná-los meros observadores. Durante esta etapa, devemos identificar e apontar os pontos críticos do processo e os pontos de falha no modelo. No entanto, é fundamental que não abordemos as melhorias do processo ainda, para evitar que o participante contamine o modelo de processo no estado atual com insights de melhorias que não correspondam ao processo real executado.

Por fim…

Uma vez detalhado o processo, o analista deve validá-lo, correspondendo à fase de modelagem no estado atual (esboço do modelo). Nesse momento, o analista de processos deve solicitar aos participantes que resumam verbalmente o processo modelado do início ao fim para observar se alguma parte do processo não foi representada. Depois de compreender completamente os processos atuais, o modelo esboçado pode ser usado como ponto de partida para abordar as mudanças, proporcionadas pelos novos processos atrelados ao sistema de ERP, identificando os pontos de diferenças e desenhando as alterações necessárias. Recomenda-se ainda que o workshop com foco nas melhorias de processos seja realizado em ocasião própria, próximo a este primeiro evento.

Esse método foi aplicado em projetos de ERP reais e demonstrou ser uma estratégia de comunicação bastante eficaz.

Conclusão

A comunicação de mudanças de processos em projetos ERP ganha destaque diante dos desafios persistentes há mais de uma década. No entanto, considerar a comunicação de mudanças em tarefas que as pessoas executam há anos baseada apenas em mensagens e apresentações expositivas tem mostrado pouca eficácia na mitigação dos principais desafios desses projetos, os quais frequentemente enfrentam resistência e medo das mudanças por parte dos envolvidos.

Ao pensar no BPM como uma estratégia de comunicação de mudanças, partimos do centro do problema para atacar os desafios. Adicionar a esta abordagem os princípios de design centrado no humano, garantindo o envolvimento das pessoas, certamente fará uma grande diferença na condução do projeto.

Bom trabalho e sucesso com o seu projeto!

Referências

Abas ERP, 2018. The 7 Reasons ERP Projects Fail and How to Avoid the Pitfalls. Access in: https://abas-erp.com/en/news/7-reasons-erp-projects-fail-avoid-pitfalls

Brown, T. 2009. Change by design: how design thinking transforms organizations and inspires innovation. New York: Harper Business.

Cereja J.R., Santoro F.M., Gorbacheva E., Matzner M. 2017. Application of the Design Thinking Approach to Process Redesign at an Insurance Company in Brazil. In: vom Brocke J., Mendling J. (eds) Business Process Management Cases. Management for Professionals. Springer, Cham.

Dumas, M., Rosa, M. L., Mendling, J. and Reijers, H. 2013. Fundamentals of Business Process Management, Springer.

Dutra, D. L. 2015. Um Framework para Mapeamento de Processos As-Is apoiado por Design Thinking. Master Dissertation, Centro de Informática, UFPE, Brazil. 2015.

Luebbe, A., Weske, A. 2012. The effect of tangible media on individuals in business process modeling.

Prata, A. M., Santos S. C., 2019. Towards Organizational Transformations: A Manageable Model to Communicate Changes, Americas Conference on Information Systems (AMCIS 2019).

Santos, S. C., Santana C., Elihimas, J., 2018. Critical Success Factors for ERP Implementation in Sector  Public: An Analysis Based on Literature and a Real Case, European Conference on Information Systems (ECIS 2018).