blog

Usando BPM e Design Thinking para Comunicar Mudanças Organizacionais em Projetos de ERP

Versão para impressão
Compartilhe:

Projetos de ERP

As organizações normalmente enfrentam desafios quando tentam implementar iniciativas de mudança em seus processos de negócios. Um cenário bastante comum e sujeito a estes desafios ocorre na implantação de sistemas de gestão empresarial, mais conhecidos como 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.

Muitos projetos de ERP têm sido renovados recentemente, principalmente devido à evolução de tecnologias como a computação em nuvem e o Big Data, visando plataformas baseadas em serviços para reduzir custos, e uma maior integração entre a empresa e sua cadeia de valor para aumentar a eficiência do negócio. Para atender a estas novas demandas, as soluções de ERP vem se transformando em complexos sistemas de gestão integrada, com a promessa de oferecer maior eficiência, produtividade e gestão dos negócios, a partir de uma maior integração de processos e processamento inteligente de informações. Mas, todos grandes benefícios trazem consigo grandes desafios. Muitas vezes a sofisticação dos novos sistemas ERPs é traduzida em transformações profundas nas organizações, que impactam diretamente nas atividades de todos funcionários em todos os níveis, acostumados há anos com seus procedimentos de trabalho. Estas mudanças demandam muitas vezes novas competências, papéis diferenciados, funções muito menos operacionais e mais gerenciais, envolvendo uma mudança de cultura organizacional e de “mindset” pessoal, que nem sempre as pessoas que fazem a organização estão preparadas para enfrentar.

Não é de hoje que projetos ERP têm sofrido falhas. De acordo com Santos et al. (2018), uma das razões é a má administração referente à identificação e gerenciamento de riscos de implantação, em geral, associados a fatores críticos de sucesso do projeto. Num artigo recente sobre os desafios em projetos de ERP (2018), a Abas ERP, uma empresa americana com foco na implantação de ERPs no mercado automotivo e de eletrônicos, destaca alguns problemas comuns a tais projetos: a falta de clareza quanto aos objetivos do projeto; a falta de comprometimento do time de gestão; falta de competências do time de projeto, que inclui gestores, usuários e profissionais de TI; a falta de comunicação aberta, ampla e transparente; processos correntes ou atuais (AS-IS) não claramente definidos; migração de dados subestimada e; finalmente, medo da mudança.

Estes desafios evidenciam o quanto o envolvimento das pessoas interessadas no projeto é fundamental no cenário de mudanças organizacionais, e como estas mudanças precisam ser comunicadas de forma efetiva, não apenas com mensagens e apresentações, quase sempre unidirecionais. Neste contexto, o sucesso em programas de mudança de processos de negócios requer, acima de tudo, um tipo eficiente de comunicação, que suporte as transformações organizacionais, envolvendo as pessoas impactadas por elas, como ressalta Prata & Santos (2019). O objetivo é garantir que os funcionários tenham conhecimento e compreensão das prioridades de negócios, de forma que possam ser orientados em suas decisões e atividades, além de promover comprometimento, confiança e lealdade com as mudanças. É aí que o BPM pode ser usado como estratégia de comunicação, envolvendo funcionários, a partir da exposição de seus processos atuais e, junto com eles, entendendo as mudanças que estes processos sofrerã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 podem ser aplicados 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 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; 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.

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.

A figura mostra o método de interação em quatro etapas. A primeira etapa é de preparação para modelagem que consiste em preparar ambiente, convidar participantes, alinhamento sobre a dinâmica das atividades de identificação, descoberta e análise de processos. A segunda etapa é a introdução aos conceitos essenciais e consistem em discussão de conceitos iniciais sobre objetivos do projeto de ERP, metodologia de processos e notações. A terceira etapa é modelagem dos macroprocessos e consiste em modelar os processos de forma macro, discutindo e refletindo sobre eles, a partir de um roteiro de questões. A quarta etapa é a modelagem dos detalhes e consiste no entendimentos dos detalhes de processos atuais, para só então identificar as mudanças provenientes dos módulos ERP.
`Método de interação entre analista de processos e especialistas de domínio

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.
Modelagem BPM
Ferramentas de modelagem

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

As principais características e tarefas do macroprocesso devem ser identificadas (fase de identificação). 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 a ser utilizada.

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 ser incentivados a detalhar cada macro tarefa, de acordo com a fase de descoberta. Este método de design top-down pode ajudar na descoberta de mais detalhes sobre a tarefa macro, de modo que cada tarefa seja examinada até que 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. Ao longo desta etapa, pontos críticos do processo e pontos de falha devem ser identificados e apontados no modelo. No entanto, é muito importante que as melhorias do processo ainda não sejam abordadas para impedir que o participante contamine o modelo de processo no estado atual, com insights de melhorias que não correspondem ao processo real executado.

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 resumem verbalmente o processo modelado do início ao fim para observar se alguma parte do processo não foi representada. Depois do completo entendimento dos processos atuais, o modelo esboçado pode ser usado como ponto de partida para a abordagem das 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 mostrou que funciona como uma estratégia de comunicação bastante efetiva.

Conclusão

A comunicação de mudanças de processos em projetos ERP ganha destaque diante dos desafios que persistem há mais de uma década. Considerar a comunicação de mudanças em tarefas que as pessoas executam há anos baseada em mensagens e apresentações expositivas têm mostrado pouca eficácia na mitigação dos principais desafios destes projetos, quase sempre sujeitos à resistência e ao 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).

Compartilhe:
gostei deste conteúdo
quero mais informações
X

nossas soluções

Assine nossa newsletter