Por que usar a modelagem de processos de negócios?
As organizações usam a modelagem de processos de negócios (modelagem de BP) para documentar visualmente, entender e melhorar seus processos. Parte do Gerenciamento de processos de negócios (BPM), a modelagem de BP tem sido usada como uma ferramenta organizacional para mapear o que é (ou o "como é") e formar uma linha de base e determinar o futuro (o que "vai ser") com quaisquer melhorias assimiladas. A modelagem de BP representa visualmente todas as atividades, eventos e recursos de conexão do processo de um produto ou serviço para torná-lo mais eficiente. Ela geralmente combina as disciplinas de mapeamento de processos, descoberta de processos, simulação de processo, análise de processos e melhoria de processos. Dentro de um evento de reengenharia de processos de negócios (BPR), a modelagem de BP é usada para iluminar quais processos já estão em uso e representar novos processos. Algumas das outras razões para usar a modelagem de BP são as seguintes:
- Para criar modelos visuais de processos - A documentação baseada em Word muitas vezes não é suficiente para que os funcionários entendam a maneira como um processo é executado. Apoiar essa documentação com representações visuais ajuda a fornecer uma imagem abrangente.
- Alinhar operações - Em qualquer nova estratégia de negócios, manter os processos consistentes após uma mudança requer descobrir como permanecer dentro da estratégia organizacional geral. Também são realizadas análises para identificar gargalos e ineficiências e permitir agilidade nos processos.
- Melhorar a comunicação do processo - A comunicação é a chave para todas as seguintes tarefas: formalizar os processos existentes (que antes eram conhecimento informal), criar processos consistentes, eliminar suposições com regras de negócios, lidar com exceções, fornecer conformidade regulatória, garantir que os empresários estejam no comando, e apoiar novas iniciativas (como o Lean Six Sigma).
- Melhorar a eficiência operacional - A modelagem de processos promove a otimização permitindo simulação e ilustrando melhorias necessárias. Isso reduz o tempo do ciclo e promove uma melhor utilização de recursos.
- Ganhar vantagem competitiva - Um processo é melhor no geral quando é constantemente refinado e alinhado com as estratégias de seus negócios. Essa eficiência coloca a empresa em uma posição de inclinação para a frente para ser melhor do que a concorrência.
Modelagem de processos de negócios no desenvolvimento de software
O desenvolvimento de software é um campo de risco. Vinte anos atrás, o relatório CHAOS de 1995 do Standish Group informou que 90% dos projetos de software fracassam. Hoje esses números são menores, mas ainda refletem que há trabalho a ser feito. No relatório de 2015 do mesmo grupo, a taxa de sucesso para projetos de desenvolvimento de software ainda era de apenas 29%. As recomendações do grupo para melhorar esses números ao longo dos anos têm ido e vindo com as novas tendências, mas uma recomendação principal se mantém: comunique-se com todas as partes interessadas, especialmente os usuários finais, pois são os usuários que acabam definindo os requisitos em primeiro lugar. Especialistas recomendam desenvolver modelos claros com notação compreensível no início dos projetos, a fim de validar os requisitos do software. A modelagem de BP permite que engenheiros de software negociem com as partes interessadas para determinar o sistema que precisa ser construído, com base no que é ideal para ambos os grupos.
A maioria dos modelos de BP foram desenvolvidos como parte das arquiteturas empresariais existentes, o que mostra que a intenção durante o desenvolvimento é que o usuário final esteja representado. No entanto, esses modelos foram feitos a partir de várias perspectivas diferentes, incluindo funcional, comportamental, organizacional e informativa. Especialistas concordam que a combinação dessas perspectivas no design de processos é o melhor método.
- A perspectiva funcional mostra quais elementos do processo estão sendo realizados e quais informações são relevantes para eles.
- A perspectiva comportamental (ou dinâmica) demonstra a sequência de interação e como os elementos do processo são realizados.
- A perspectiva organizacional mostra por quem e onde os elementos de um processo são realizados.
- A perspectiva informativa representa a origem das informações que são produzidas ou analisadas.
Linguagens de modelagem de processos de negócios em softwares de modelagem de processos de negócios
Todas as linguagens existentes do modelo de processamento de negócios vêm de diferentes facetas da tradição científica, e foram construídas para se adequar a uma perspectiva ou outra. Há uma sobreposição significativa entre elas, mas existem quatro categorias amplas de linguagens de modelagem de processos de negócios.
- Linguagens tradicionais de modelagem de processos: originárias do sistema de informações de gerenciamento (MIS) tradicional da engenharia da informação, essas linguagens devem ser compreendidas e não são tipicamente formais. Elas incluem IDEF, Petri Nets, EPC, Diagramas de atividade de função, REA e BPML.
- Linguagens de modelagem de fluxo de trabalho: essas linguagens de script servem para descrever fluxos de trabalho para um sistema de gerenciamento de fluxo de trabalho (WfMS). Estes idiomas muito formais incluem linguagem de descrição do processo de fluxo de trabalho (WPDL) e formatos de intercâmbio propostos (PIF, PSL).
- Linguagens de integração de processos: essas linguagens têm o propósito de se integrar entre empresas e capturar diferentes níveis da semântica nos processos. Elas incluem RosettaNet, ebXML e BPEL4WS.
- Linguagens orientadas a objetos: destinadas a serem compreendidas por especialistas em TI e domínio, essas linguagens representam o domínio do software. A maior parte da modelagem orientada a objetos leva em consideração as perspectivas funcionais, comportamentais e informativas.
Hafedh Mili et al recomenda que as equipes usem uma linguagem central para a modelagem e, em seguida, usem diferentes partes de outra linguagem que se adequem ao processo. Nesse campo, parece que os especialistas concordam que até mesmo as linguagens devem ser impulsionados pelas tarefas.
Como abordar um projeto de modelagem de processos de negócios
Escolher uma abordagem para modelagem de processos de negócios (BP) é tão essencial quanto executá-la. A abordagem, baseada na tarefa real, não é igual para todos os casos. Algumas classificações devem ser feitas antes que um projeto seja realizado. De acordo com Bider, os profissionais devem considerar três fatores: os processos de negócios reais, as características do ambiente de modelagem e o uso pretendido do modelo. Esses três fatores podem ser divididos em considerações de negócio específicas.
- Os processos comerciais – As empresas devem considerar seus participantes ativos e passivos, o quanto eles estão atingido suas metas operacionais, a proximidade de interação do processo com seu ambiente e a natureza e a ordem do fluxo do processo.
- As características do ambiente de modelagem - Para o ambiente de modelagem, as empresas devem considerar a maturidade de seus processos existentes e se há ou não pessoal disponível que entenda a notação muito formal.
- O uso pretendido do modelo - As empresas devem considerar seus objetivos para projetar modelos e qual base está usando para criar modelos. Por exemplo, a empresa pode estar tentando melhorar os processos atuais, fornecendo análises ou reengenharia, ou construindo um novo sistema de computador.
Como não há uma abordagem universal para a modelagem de BP, especialistas recomendam considerar todos os fatores exclusivos do negócio. Alguns profissionais recomendam uma abordagem formal especificada que reúna todas as informações antes de escolher as ferramentas, enquanto outros recomendam ferramentas específicas que funcionaram para eles no passado. Dois de nossos especialistas fazem suas recomendações abaixo.
De acordo com Dani Peleva, diretora executiva da Local Fame Ltd:
“When approaching a business process modeling task, I’d always break it through the prism of project management as it helps me get an idea of the objective of the system that needs engineering, the time the process needs to be completed for, as well as the resources available. Once you know what the requirements are, i.e. the purpose of the process is, what the deliverables are, the budget/resource constraints and so forth, it is a lot easier to approach the design/engineering stage.
When it comes to process engineering at Local Fame, we always have efficiency and effectiveness in mind - the most cost-effective, timely and optimized manner that a process can flow. For this purpose, I always approach the task from a few different angles - from the start of the process, as well as from the end of the process backwards. When you do not limit yourself with the direction of the process flow you can identify gaps and possible flaws in the strategy and implementation, as well as possible bottlenecks. Once I come up with a few different models I test those applying different scenarios in order to understand how sustainable those are in turbulent environment. This is when usually you sift through the best models and shortlist one or two successful ones.
Additionally, an intrinsic part of business process modelling for me is risk management, more specifically, identifying the potential flaws of the model and where and under what circumstances the model can fail. Identifying those weaknesses of the process helps you create contingency plans and backups, and as you often may find yourself, you get to optimize the process even further and scrap some of the chunks you initially considered essential, but later on realized you could go without. When thinking about risk management, however, one should know a risk could be both a positive and a negative, risk can create opportunities for the process to fail or get delayed, but also speed up and become more efficient, which again leads to the process optimisation and potential changes in the model. Tools I often use when doing business process modelling are Gliffy, Activiti Modeller, and Gantt charts.
To conclude, when modelling a process or re-engineering an existing one, I usually approach the task from a project management perspective analysing the requirements fully before moving to the design stage. After design stage, I test the model numerous times in different scenarios and if needed I return to different stages to optimise and tweak it further. Lastly, I always think about risk management and contingency to make sure that the process is resilient and sustainable.”
Ray McKenzie, Founder and Principal, Red Beach Advisors, recommends, “As a management and business consultant for small- to medium-sized companies, a primary duty of mine is to develop efficient and optimized process for every organization to be productive. I always start with examining the problem and finding out the history of the problem, the different parts of the problem, and the effect the problem has on the business. Understanding the problem and components are core pieces to developing an effective process model to improve. Start with the problem. Examine the parties involved. Understand the current performance and measurements. Define the performance improvement goals. Outline an efficient process which drives results and displays success.”
Fluxos de trabalho e a abordagem orientada a serviços de negócios (BSOA)
Alguns especialistas consideram a modelagem de BP para desenvolvimento de software como uma perspectiva de "antes e depois" que gira em torno da introdução de serviços web. Antes do desenvolvimento da web, a principal abordagem para o desenvolvimento de processos eram os fluxos de trabalho. Na abordagem do fluxo de trabalho, os processos de negócios são pré-determinados. As linguagens mais adequadas são a linguagem de execução de processo de negócios (BPEL) e a linguagem de definição de fluxo (FDL). A abordagem do fluxo de trabalho foi criticada por não ser muito flexível em um ambiente moderno.
Após o desenvolvimento de serviços web, a abordagem da modelagem BP para o desenvolvimento de software tornou-se mais focada e identificada como a Abordagem Orientada a Serviços de Negócios (BSOA). A modelagem de processos é baseada na composição flexível dos serviços de negócios. A abordagem pode ser adaptada para abordar quais são os objetivos e requisitos do designer no desenvolvimento da arquitetura usando blocos de construção. Os serviços realizam pequenas tarefas, como desenvolvimento de dados ou procedimentos simples de serviço. Com tudo isso junto, a BSOA faz um sistema extremamente reutilizável que pode ser corrigido e atualizado regularmente. Essa abordagem é creditada como sendo Agile e aplicável a muitos tipos diferentes de organizações.
Diferentes maneiras de modelar processos de negócios
Com tantos padrões e linguagens padronizadas, alguns profissionais acham que a criatividade no design de processos está se esgotando. Abordagens alternativas podem restaurar parte dessa criatividade. Algumas das técnicas mais populares que podem ser independentes ou até mesmo complementar abordagens mais formais são as seguintes:
- técnica de gráfico de fluxo;
- diagramas de fluxo de dados — técnica de Yourdon;
- diagramas de atividade de função (RAD);
- diagramas de interação de função (RID);
- gráfico de Gantt;
- definição integrada para modelagem de função (IDEF);
- redes de Petri coloridas (CPN);
- métodos orientados a objetos (OO);
- técnica de fluxo de trabalho;
- simulação;
- notação de modelo de processo de negócios (BPMN);
- diagrama de atividade de UML;
- modelos de processo transformacional;
- narrativa;
- modelos de processo hierárquicos
- Visualização
According to Bernard Lee, President of Charlotte Search Engine Consultants, there are other ways to model your projects visually. He points out that, “As a lifelong entrepreneur who started my first business at 20, I am now 53 and am considered a ‘college dropout.’ It has always been about systems, automation, and measuring risks to achieve our stated goals. This has been true in my career as a wealth manager, a Healthcare IT executive, and now as the founder of a digital marketing agency that specializes in SEO. Yes, SEO is about metrics, analytics, and CTR (click-through rate). Nevertheless, I've found the creative aspects is what separates the pretenders from the achievers. We are Google partners so we believe in the usual success measurements, but get there differently. YouTube, Geo-Tagging, and unorthodox combinations of our client's digital properties consistently land multiple properties on page one for the most important keywords. The visual of multiple positions on page one always has an immediate impact on our client’s brand, traffic, and conversions while moving competitors to page two.”
Mapeamento de processos x Modelagem de processos
O mapeamento de processos é uma revisão de alto nível de uma organização como uma entidade única com partes interconectadas. O fluxo de processos de negócios na organização é revisto para esclarecer quem faz o quê, como os processos são realizados e por qual padrão eles são julgados. Na modelagem de processos, os profissionais estão mais focados no quão eficientes são os processos, usando as melhores práticas de negócios e econômicas. Embora ambos representem os processos graficamente, a modelagem de processos é um mergulho mais profundo nos relacionamentos que produzem os serviços e os resultados.
Estrutura para a modelagem e avaliação de processos de software (FMESP)
Uma das questões complicadas que surgiram com o desenvolvimento de processos de negócios padronizados é a noção de que sua eficácia deve ser determinada. Em outras palavras, quão bem-sucedidos são os processos de negócios? A FMESP traz um conjunto de métricas para avaliar modelos conceituais de processos comerciais: o que eles fazem e o que não fazem. Ela mede a complexidade estrutural dos modelos de processo de software e, em seguida, as atividades, funções e produtos de trabalho. Essa estrutura destina-se a fornecer às empresas informações objetivas sobre a manutenção de seus modelos.
Desenvolva bons modelos de processo de negócios
Como um profissional começa em um modelo de BP? Uma das abordagens comuns defende a escolha de um problema, a seleção do método e, em seguida, a resolução do problema. Mantê-lo simples garante que tudo o que é relevante esteja no modelo e que tudo no modelo seja relevante.
Outras dicas profissionais incluem:
- Certifique-se de saber quem serão seus recursos. Desenvolva listas de tarefas, pessoas e o tempo necessário para concluir o modelo.
- Conduza suas entrevistas na ordem em que as funções aparecem no modelo do processo.
- Documente. Documente. Documente.
- Verifique novamente todos os seus símbolos, certifique-se de que haja uma chave e siga cada etapa para garantir que o caminho o leve de volta ou para a frente.
- Conheça o resultado desejado com antecedência.
- Descubra seus pontos de início e término.
- Obtenha os documentos e formulários que fazem parte do processo com antecedência.
- Use modelos sempre que puder.
De acordo com Steve Wallis, co-fundador/analista/consultor da ASK MATT, Foundation for the Advancement of Social Theory (FAST) - Theory for a better world:
“BPM is incredibly useful for showing ‘what goes on’’ within a business organization. However, it can also create a false sense of comfort. When the map says, ‘You are here’ we feel a sense of security. However, unless the map shows how to get from ‘here’ to ‘there’ it is not going to be very useful. More importantly for the ever-shifting world of business, a map needs to show multiple paths so that leaders can take advantage of new options when unanticipated problems arise (and you know they will). Research in this area suggests that models (maps) which are more complex and have more interconnections are more useful for understanding how organizational processes work, and how they might be changed when the need arises. What does NOT work is a simple, linear model such as:
Fonte da imagem: Steve Wallis
Oh, se ao menos a vida fosse tão fácil e tão previsível, no entanto, não é. Portanto, procuramos uma abordagem um pouco diferente para a modelagem de processos de negócios. Chamamos-a de mapeamento estratégico do conhecimento (SKM) e nos concentramos nos aspectos transformacionais da modelagem. Em vez de modelar o que está acontecendo no nível da “superfície” (por exemplo, a pesquisa dá informações para a fabricação), encorajamos nossos clientes a ver quais mudanças ocorrem em todas as etapas interconectadas do processo. A partir de nossa pesquisa e experiência, desenvolvemos duas técnicas fáceis para o desenvolvimento de bons modelos.
Primeiro, para entender uma transformação em um modelo, deve haver mais de uma seta apontando para cada caixa. Por exemplo, se estamos falando em fazer doces, o processo de criação requer matéria-prima (farinha, ovos, açúcar, chocolate etc.), equipamentos (forno, racks, misturadores etc.) e cozinheiros (com algum nível de especialização). Portanto, para entender melhor a transformação, criamos um modelo mostrando como cada um desses "insumos" se combina para criar o "resultado" transformado. Para alguns, isso pode parecer óbvio. No entanto, aqui está o insight oculto (por exemplo, recheio de chocolate): se você tem um modelo onde há apenas uma seta apontando para algo, essa falta de setas adicionais indica uma lacuna no modelo. Para gerenciar o processo, você está perdendo um caminho alternativo.
A segunda dica para fazer modelos eficazes é entender cada seta como sendo "causal". Esta é uma das grandes partes do "conhecimento esquecido" no mundo dos negócios. Causalidade é a essência da compreensão científica. Para entender o processo transformacional e os processos comerciais em geral, não basta simplesmente dizer: "o cozinheiro mistura os ingredientes e faz os bolos". Um bom gerente entende que ter mais matérias-primas, mais equipamentos e mais especialização causará a transformação em um produto (ou serviço) comercializável. E, para gerenciar esse processo, pode haver algumas trocas entre eles (um especialista realmente bom pode ser capaz de aproveitar um pouco mais a matéria-prima), mas cada fluxo é necessário para criar o produto final. Sem matéria-prima não terei um bolo para comer com o meu café!”
Modelo e notação de processos de negócios (BPMN)
O BPMN foi desenvolvido pela Business Process Management Initiative (BPMI) como um padrão aberto da indústria e agora é mantido pelo Object Management Group (OMG). Nenhuma empresa de software ou consultoria é dona dele. Ele é uma notação gráfica para criar modelos de processo, semelhantes aos fluxogramas, que é usada e compreendida em todo o setor. Muitas ferramentas de software suportam o BPMN. No entanto, o significado das formas e símbolos são independentes dessas ferramentas, e esses significados são precisos. O BPMN é uma parte central do gerenciamento de processos de negócios (BPM), uma iniciativa de arquitetura empresarial. A versão do BPMN que está atualmente em uso é v2.0, atualizada pela última vez em 2011. Os profissionais podem ser certificados no BPMN v2.0 por meio do processo de exame do OMG. O OMG também oferece guias que mostram como a notação é dividida nos grupos de eventos, atividades, fluxos, dados, artefatos etc. Os elementos são categorizados em quatro grupos importantes que são chamados de objetos de fluxo, objetos de conexão, raias e artefatos.
Fonte: OMG
A intenção do BPMN é que usuários técnicos e usuários de negócios possam entender uma linguagem diagramática comum. O BPMN é baseado em uma técnica de fluxograma semelhante à desenvolvida a partir da linguagem de modelagem unificada (UML) e é capaz de ser mapeado diretamente para a linguagem de execução de processos de negócios (BPEL), uma linguagem baseada em XML que é usada para definir serviços comerciais empresariais dentro dos serviços web.
Críticas ao BPMN
A opinião do setor varia de acordo com o uso do BPMN na modelagem de BP. Os críticos argumentam que o BPMN é muito mais complexo e avançado do que precisa ser para as partes interessadas que podem não estar muito próximas do processo real. Além disso, com tantos símbolos é fácil cometer erros, contrariando o objetivo de seu uso.
Os defensores do BPMN dizem que a maioria dos profissionais usam apenas um punhado de símbolos, tornando desnecessário o conhecimento de símbolos obscuros. Algumas empresas internacionais exigem consistência com o BPMN, especialmente quando as linguagens podem ser variadas. Compreender os processos com uma notação padronizada é um desafio menor.
Outros tipos de notações e diagramas
Em 2012, Cristina Venera realizou um estudo de duas linguagens de notação populares, BPMN e diagrama de atividade de UML (UML AD). Ela descobriu, entre profissionais e referências, que ambas as linguagens são igualmente fáceis de entender pelas partes interessadas na modelagem de BP, e que ambas forneceram soluções semelhantes. No entanto, a diferença é que o BPMN pode ser mapeado para (WS)BPEL, enquanto o UML AD não pode de ser mapeado automaticamente para nenhum BPEL.
Outros tipos de notações incluem cadeia de processos impulsionados por eventos (EPC), diagramas de fluxo de trabalho e mapas mentais. O EPC é mais usado para processos de negócios de alto nível, consiste em cinco elementos e regras e sempre começa com e termina com um evento. Há regras entre: "OR", "AND" ou "XOR" representados como conectores gráficos.
Diagramas de fluxo de trabalho ilustram estágios e relacionamentos entre todas as partes de uma empresa. Nos diagramas do fluxo de trabalho, não há um conjunto de símbolos acordados (padrão). É mais difícil comparar modelos feitos em uma organização, mas permite mais liberdade para a criatividade.
Os mapas mentais são os menos restritivos de qualquer uma das técnicas listadas aqui. Embora geralmente sejam hierárquicos, eles podem ser feitos à mão em um guardanapo em um bar, se necessário. Mapas mentais são uma maneira de mostrar relacionamentos em torno de um único conceito, bem como quaisquer associações. Eles são de fluxo livre e permitem o máximo de criatividade.
Fonte: Jennifer Frith
O que procurar em um software de modelagem de processos comerciais
De todas as opiniões e pesquisas de especialistas, não parece haver uma ferramenta que atenda a todas as necessidades permanentes de uma organização. Os principais requisitos recomendados para uma ferramenta ou um conjunto de ferramentas são que eles sejam rápidos (para aprender) e baratos. A página inicial do BPMN lista 74 ferramentas compatíveis com BPMN. Se a conformidade com o BPMN for um requisito, a pesquisa já está limitada. Caso contrário, os usuários devem especificar seus objetivos e requisitos, quais ferramentas satisfazem seus requisitos, quais são os critérios mais significativos e quais seriam as ferramentas potenciais para uso. Então, TESTE. Encontrar a ferramenta certa pode ser um processo, mas você não se arrependerá.
De acordo com Norbert Nogrady, diretor administrativo e co-proprietário da JCM Ltd: norbert.nogrady.bpralumni@gmail.com, Twitter: @kgordos
“I started to reorganize organizational units more than 15 years ago. At the time, the number of available process modeling tools was very limited, much less their functionality. However, as time went by, I witnessed the evolution of such tools. In the beginning, I used large sheets, then Microsoft Word and Visio. However, I had a number of serious issues with these tools. The biggest problem is that BPR projects tend to be lengthy and thus overwhelming. The usual routine at the large corporations I worked for was (one of the following):
- A gerência indicou o departamento de TI para encontrar uma ferramenta para o gerenciamento de processos de negócios (fluxo de trabalho) que se adequasse aos requisitos de TI.
- Líderes no nível de gerenciamento com engenheiros de BPR criaram seus respectivos processos
- Diagramas de processo foram criados usando várias ferramentas.
- Os processos foram então transferidos para o departamento de TI, para que eles avaliassem se os processos se encaixavam no sistema de fluxo de trabalho de sua escolha.
- Após várias iterações, geralmente resultando em comprometimentos em relação aos processos, o departamento de TI começou a programar os processos no sistema de fluxo de trabalho.
- Os processos foram implementados na organização, com a necessidade imediata de realizar a reengenharia de muitos deles.
- Os pontos de dois a seis foram repetidos por muito tempo até que um conjunto aceitável de processos de negócios fosse criado.
Como ficou claro acima, o BPR desta forma não foi fácil, mas sim levou muito tempo e consumo de recursos. Além disso, percebi muito cedo que os departamentos deveriam criar seus próprios processos, em vez de iterar com a TI. Portanto, vários comprometimentos do processo poderiam ser evitados. Além disso, levou muito tempo para implementar os processos criados no sistema de fluxo de trabalho pela programação. Ambos os problemas me incomodaram ao nível em que comecei a procurar uma solução que se encaixasse nos requisitos habituais de TI e suportasse totalmente minhas atividades de BPR.”
Depois de muita tentativa e erro, Nogrady finalmente encontrou uma solução que funcionou para ele. Após sua pesquisa bem-sucedida, ele sugere procurar um sistema de fluxo de trabalho que tenha uma ferramenta integrada de processo e editor de fluxo de trabalho com uma interface gráfica, tornando a programação de processos obsoleta. A vantagem é que uma vez criado um processo no editor de fluxo de trabalho gráfico, é preciso apenas um clique de um botão para executá-lo imediatamente no sistema de fluxo de trabalho. Portanto, todos os departamentos podem criar seus próprios processos de negócios, sem a necessidade de programação. Seguir esse caminho significa que há pouco ou nenhum ajuste nos fluxos de trabalho e, o mais importante, muito tempo e recursos podem ser poupados dessa forma. Por fim, uma boa solução fará com que o teste dos processos leve muito menos tempo e esforço. Dessa maneira, caso um processo possa usar alguma melhoria, qualquer pessoa no departamento pode dar suas sugestões e, se o líder do departamento aprovar, o processo modificado deve ser capaz de ser executado no sistema de fluxo de trabalho em algumas horas.
O futuro da modelagem de processos de negócios
Uma área crítica de preocupação com o futuro da modelagem de BP inclui como as abordagens de modelagem podem ser padronizadas. Muitas empresas estão mudando para uma plataforma mais Agile, e a modelagem de BP não necessariamente anda lado a lado com os processos Agile. Uma abordagem de modelagem só pode ser considerada Agile para alguns tipos de processos, de acordo com um estudo recente de Nancy Alexopoulou.
Como Ian Gotts, fundador e CEO da Elements.cloud e colunista da Digital Business também observa: “Há grandes problemas no espaço de modelagem de BP. Fornecedores de software de BPM, automação e fluxo de trabalho sequestraram o BPM, de modo que o B no BPM desapareceu. A modelagem passou a significar definir fluxos de trabalho por TI para TI. No entanto, a visualização de processos (modelagem de processos de negócios) é valiosa para os usuários finais. Eles usam o diagrama do processo de negócios para concordar sobre como o trabalho é feito. Isso fornece a perspectiva dos bastidores da TI. No entanto, tentar usar a notação BPMN como um modelo para todos é algo difícil de se conseguir. Com tantos símbolos, parece complicado, e os empresários são rapidamente desengajados e se perguntam por que estão fazendo isso.
“There is a notation - Universal Process Notation (UPN) - that works for business people, that has been very successful. It is outlined in Chapter two of the e-book, Analysis, Automation & Adoption for #AwesomeAdmins. The first principle that is relevant here is that we are not building a huge flowchart, but a hierarchical process map, where every diagram is easier to follow. For example, at a bank, there may be 10,000 diagrams for all of the processes, but they are organized in a hierarchy so no diagram is overwhelming. Second, the notation is a simple model using an activity box or step with inputs and output, resources identified (or swimlanes), and hyperlinks to supporting information. This process map is useful for end users, but it is also valuable for compliance, IT, and management where metrics can be viewed in the context of a process. Using this approach is valuable for app vendors to improve adoption. An end-to-end process can make sense of the detailed flow of apps.”
Saiba mais sobre modelagem de processos de negócios
Interessado em saber mais sobre a modelagem de BP e como implementá-la em sua empresa? A seguir estão listas de recursos para uma leitura mais aprofundada que podem ajudar.
Livros e e-books
- Analysis, Automation & Adoption for #AwesomeAdmins - Manual gratuito do software UPN
- A Pragmatic Guide to Business Process Modelling, de John Holt
- Essential Business Process Modeling, de Michael Havey
- Business Process Modeling, Simulation and Design, Second Edition, de Manuel Laguna e John Marklund
White Papers
- Strategic Knowledge Mapping For Improved Policy and Strategic Planning, de Steven E. Wallis e Bernadette Wright.
- Strategic Knowledge Mapping: The Co-Creation of Useful Knowledge, de Steven E. Wallis e Bernadette Wright.
Software
- Uma lista de softwares gratuitos de modelagem de processos de negócios
- Comparação das ferramentas de notação de modelagem de processos de negócios
- Guia de mercado para análise de processos de negócios empresariais - da Gartner
Outros tipos de diagramas
Como o Smartsheet pode ajudar a melhorar os processos de negócios
Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.