Referencial Teórico Recursos Humanos

================================================[editar | editar código-fonte]

Referencial Teórico Recursos Humanos

Equipe 8 - Processo de Negócio: Recursos Humanos[editar | editar código-fonte]

João Paulo - Traduzir pag 1, 2, 3 pdf

Paulo Marcotti - Organizar pag 1 a 13

Pag. 1 Introdução

1.1 Business Process Management

1.1.1 Definição

1.1.2 BPMn na prática

1.1.3 Ciclo de vida do BPM Camunda

1.1.4 Automação de processos

2.1 Diagramas BPMn -  Modelagem de Processos - Notação BPMn - Referencial Teórico

Esta seção do PI foi elaborada por cada equipe e vai receber uma parcela da nota, por equipe e individual

João Paulo & Marcotti

Este trabalho é sobre Modelação e Notação dos Processos de Negócio (Business Process Model and Notation - BPMN 2.0). Para entender porque o BPMN foi inventado, precisa-se entender primeiro a Gestão dos Processos de Negócio (Business Process Management - BPM).

2.1.1

Definição

Segundo Freund e Rücker (2012), os experts usam diferentes definições para a Gestão dos Processos de Negócio. Uma delas é a definição dada pela Associação Européia de BPM (EABPM) no seu trabalho de referência  "Corpo Comum de Conhecimento do BPM":

"Gestão de Processos de Negócio é uma abordagem sistêmica para capturar, desenhar, executar, documentar, medir, monitorar e controlar tanto processos automatizados quanto não automatizados para encontrar os objetivos e estratégias de negócio de uma companhia. BPM envolve a consciente, compreensiva e cada vez mais tecnológica definição, aprimoramento, inovação, e manutenção de processos de ponta-a-ponta. Através dessa Gestão de Processos sistêmica e consciente, as companhias alcançam melhores resultados mais rápido e com mais flexibilidade. Pelo BPM, os processos podem se alinhar com a estratégia da empresa, e ajudam a aprimorar o desempenho da companhia como um todo graças a otimização dos processos entre as divisões da empresa ou além das fronteiras da companhia."

O que "processo de ponta-a-ponta" realmente significa é "do começo ao fim". O objetivo é entender e portanto acessar e melhorar um processo inteiro - não apenas seus componentes.   A definição do EABPM é considerada como útil, porque ela trata processos automatizados e não automatizados como igualmente importantes e sujeitos ao poder do BPM. Este entendimento é essencial para aplicar o BPM com sucesso porque raramente é suficiente melhorar apenas procedimentos organizacionais ou as tecnologias de suporte; geralmente precisa-se melhorar tanto os procedimentos quanto a tecnologia cooperativamente.

1.1.2

BPM na prática

Consultores que se especializaram em BPM afirmam que na maioria das vezes, seus novos projetos envolvem um dos seguintes 3 cenários:

1- O cliente quer aprimorar um processo usando Tecnologia da Informação (TI).

2- O cliente quer os processos atuais documentados.

3- O cliente quer introduzir processos inteiramente novos.

Na grande maioria das vezes, é encontrado o primeiro cenário: o cliente procura aprimorar o seu processo com TI. Geralmente a motivação é um desejo para melhorar a eficiência - por exemplo, usar software para eliminar chaveamento manual ou re-chaveamento de dados. Um cliente pode querer implementar monitoramento baseado em TI e análise de processos rotineiros baseada em indicadores-chave de desempenho (Key Performance Indicators - KPIs).

O segundo cenário, documentar os processos, geralmente é pedido porque o cliente precisa da documentação para guiar o trabalho das pessoas envolvidas. Outra justificativa é de que a documentação é mandatada por regulamento, ou que ela é necessária para obter certificações como a ISO 9000.

O terceiro cenário é o que acontece menos. Foi descoberto pelos pesquisadores que quando as companhias querem introduzir processos inteiramente novos, geralmente é porque elas estão sendo forçadas a se adaptar a condições de mercado diferentes, desenvolver novos canais de distribuição, ou introduzir novos produtos.

Em anúncios públicos, as companhias podem falar em aspectos gerais: elas têm um interesse em explorar BPM ou elas querem aumentar sua orientação do processo. Na prática, especialmente em organizações grandes, o argumento para o BPM geralmente é bem definido e específico, mas pode tomar 2 formas:

        1. Há uma razão forte para usar o BPM. O projeto envolve processos essenciais para serem criados, melhorados ou documentados.

        2. A razão para usar o BPM é "estratégica". Não terá nenhum benefício direto ou imediato, e o projeto provavelmente foi iniciado por algum gerente tentando alavancar sua carreira.

Como se pode imaginar, pessoas sérias não recebem o segundo argumento com entusiasmo. Com isso,  existe uma visão de que BPM, gestão de processos, ou qualquer coisa que se queira chamar, não é um fim em si.

Na maioria das vezes é recomendado introduzir o BPM em etapas. Cada etapa deve produzir um benefício mensurável e prático que justifica o tempo e o esforço necessários para alcançá-lo. Quando a motivação da primeira etapa estiver estabelecida, vá para a próxima. Você deve pensar que essa abordagem produz soluções isoladas umas das outras, mas cada etapa contribui com o todo: a orientação do processo da companhia. Uma pessoa que faz caminhada pode usar um mapa e uma bússola para guiar seus passos. Quando você introduz BPM, você deve usar um bom modelo de procedimento e senso comum como seus guias.

2.1.3 Ciclo de vida do Camunda BPM

Fig. 1.1 - O ciclo da vida do Camunda BPM

https://pmarcotti.edublogs.org/files/2019/12/1_1-300x168.jpg

Fonte: Freund e Rücker (2012).

Modelos de procedimento sempre parecem ser muito simples ou muito complexos. Os que são muito simples contém apenas os elementos mais óbvios. Eles podem ser úteis para apresentações de marketing, mas não muito além disso. Do outro lado, modelos muito complexos trabalham tanto para antecipar qualquer contingência  que eles prendem o usuário como uma mosca em um âmbar. Eles são irrealisticamente rígidos. Mesmo assim, sem um modelo não seria possível ter um “mapa” para se orientar.

Os autores Jakob Freund e Bernd Rücker, em seu livro “Real Life BPMN” (2012), ao descrever a criação da figura 1.1 disseram:

“Depois de examinar o simples ciclo de vida do BPM, que é o modelo de procedimento do BPM mais bem estabelecido, nós o refinamos de acordo com nossa experiência. Nós queríamos criar um modelo relativamente leve sem muitas restrições. Acreditamos que isso seria mais prático do que os materiais de marketing coloridos e brilhantes que nós geralmente vemos nas conferências e encontros. O batizamos de “ciclo de vida do Camunda BPM. Veja na figura 1.1.

Nossa intenção com o ciclo de vida do Camunda BPM foi de descrever um processo de cada vez. Qualquer processo pode se repetir independente dos outros, e ele pode estar numa fase diferente toda vez que se repete. O ciclo é ativado quando uma das seguintes situações se apresenta:

・   Um processo existente deve ser documentado ou melhorado.

・   Um novo processo deve ser introduzido.

Temos que começar por examinar um processo existente. A descoberta processo claramente é diferenciar o processo objeto de outros processos a montante e a jusante. A descoberta revela a saída gerada pelo processo objeto, bem como a importância dessa saída para o cliente. Usamos técnicas tais como oficinas e entrevistas um-à-um para identificar não só o que precisa ser feito, mas também quem precisa estar envolvido, e quais sistemas de TI.

Nós documentamos as descobertas do processo em um modelo de processo de estado atual. Esta documentação do processo pode incluir muitos gráficos e descrições diferentes; que normalmente tem vários fluxogramas. Um exame sistemático do processo de estado atual identifica claramente os pontos fracos e as suas causas.

Realizamos análise de processos, quer porque a seja documentado pela primeira vez e o controle de processo contínuo revelou uma fraqueza de um processo que não pode ser remediado facilmente“ (FREUND; RÜCKER, 2012, Pág. 2)

As causas de pontos fracos identificados por uma análise do processo tornam-se o ponto de partida para um outro projeto processo. Se necessário, diferentes projetos de processos podem ser avaliados por meio da simulação de processos. Ao realizar um projeto de processo introduzindo um novo processo. O resultado em ambos os casos é um modelo de processos do estado de alvo.

Na realidade, o que normalmente deseja-se, é implementar o modelo de processos estado de destino como uma mudança nos procedimentos de negócios ou organizacionais, bem como um projeto de TI. A gestão da mudança, especialmente a comunicação do processo, desempenha um papel decisivo na mudança organizacional bem sucedida. Para a implementação de TI, o processo pode ser automatizado ou software pode ser desenvolvido, adaptado, ou adquirido. O resultado da aplicação processo é um processo de estado corrente correspondente ao modelo de processo de estado de alvo que, convenientemente, já foi documentado.

Na maioria dos casos, encontra-se todas as etapas de descoberta de processo para processo de implementação para ser necessário. Porque monitoramento do processo ocorre de forma contínua, no entanto, ele revela mais sobre a operação contínua do processo.

As tarefas mais importantes de controle de processo são o monitoramento contínuo de instâncias de processos individuais e a análise dos dados-chave para que os pontos fracos possam ser reconhecido o mais rápido possível. Problemas com entidades individuais requerem soluções diretas, e assim fazer os problemas estruturais se isso for possível. Se necessário, o modelo de processo estado atual tem que ser ajustado.

Se as causas estruturais dos problemas não são claras ou complexos, o que exige um projeto de melhoria que; depois novamente; inicia com uma análise de processo sistemático dos pontos fracos. A decisão de iniciar um projeto como este encontra-se com o proprietário do processo e qualquer outra pessoa que depende do processo. É comum considerar controle de processo contínuo como algo que segue implementação do processo, embora possa ser melhor tê-lo que seguir a documentação inicial. Isto é especialmente verdadeiro quando existe dúvida sobre a necessidade da melhoria.

Dada a importância do modelo de processo dentro do ciclo de vida do BPM, é devida a importância de um padrão de modelagem, como BPMN. No entanto, a modelagem de processos não é uma fase do ciclo de vida Camunda BPM. Isso porque a modelagem de processos é um método que afeta todas as fases, especialmente a documentação do processo e design processo. Comumente  encontrar-se pessoas que tentam inserir modelagem de processos como um estágio no mesmo nível como documentação de estado atual, o que é um equívoco.

O ciclo de vida do BPM descreve uma maneira simples de alcançar a melhoria contínua. Para aplicá-lo, é necessário coordenar a "triad". Isso significa as partes responsáveis, os métodos aplicados e as ferramentas de software de suporte. Conhecer a “triad" que caminha para um objetivo comum é a tarefa da governança do bpm, que tem autoridade sobre todos os processos e todos os projetos de bpm em uma organização.

A definição de BPM do EABPM usou o termo "automação de processo" e também usamos esse termo na descrição do ciclo de vida de camunda bpm. O Bpmn foi desenvolvido para automatizar a massa dos processos. Mesmo que você não seja um especialista em TI, é necessário entender o que significa automação de processos, pois isso ajudará você a entender como o bpmn cria pontes entre negócios e tecnologia.

Automação do processo

Aqui está um processo simples: um cliente bancário em potencial envia um pedido de crédito em papel, que acaba na mesa de um contador. O contador examina a súplica e depois verifica o valor do crédito do cliente em potencial por meio do site de uma agência de classificação de crédito. Os resultados são positivos, de modo que o contador registra o aplicativo em um software especial, vamos chamá-lo de "banksoft" e encaminhar os documentos a um gerente para aprovação.

Aqui está o mesmo processo automatizado de um potencial cliente do banco enviar um pedido de crédito em papel. No banco, um funcionário digitaliza o aplicativo em um software de formulário eletrônico chamado mecanismo de processo, passa o documento e o direciona para a lista de tarefas virtual do contador, que acessa a lista de tarefas talvez pelo site do banco ou por um programa de e-mail como o Outlook da Microsoft, examina o aplicativo na tela e clica em um botão no qual o mecanismo de acesso acessa a agência de classificação de crédito, transfere os detalhes pertinentes e recebe o relatório, uma vez que o relatório é positivo, pois o mecanismo de processo passa as informações para o banksoft e cria uma tarefa de aprovação no manager. lista de tarefas.

Se este exemplo representa uma proxy ideal, não é esse o ponto. Está aqui apenas para ilustrar os seguintes princípios de automação de processos:

• A automação de processos não significa necessariamente que todo o processo seja totalmente automatizado.

• O componente central da automação de processo é o mecanismo de processo que executa um modelo de processo executável

• O mecanismo de processo controla o processo, informando os humanos sobre as tarefas que eles precisam executar e lida com o resultado do que as pessoas fazem. Também se comunica com sistemas de TI internos e externos

• O mecanismo de processo decide quais tarefas ou chamadas de serviço ocorrem ou não em que condições e de acordo com o resultado da execução da tarefa ou chamada de serviço. Assim, as pessoas envolvidas ainda podem influenciar a sequência operacional de um processo automatizado.

A figura 1.2 ilustra esses princípios.

https://pmarcotti.edublogs.org/files/2019/12/1_2-300x173.jpg

Fig. 1.2 - Automação de Processo com um “motor de processo” (process engine)

Fonte: Freund e Rücker (2012).

Se você acha que a automação de processos em apenas um tipo de desenvolvimento de software, você está certo, o mecanismo de processo é o compilador ou intérprete e o modelo de processo executável é o código do programa. Um mecanismo de processo é o mecanismo de escolha em que a automação do processo é preocupante.

• O mecanismo do processo é especializado em representar a lógica do processo. Os serviços prestados teriam exigido extensa programação no passado; Agora, usar um mecanismo de processo pode torná-lo consideravelmente mais produtivo do que antes.

• Um mecanismo de processo combina gerenciamento de fluxo de trabalho com integração de aplicativos. Isso o torna uma ferramenta poderosa para implementar todos os tipos de processos, desde a estrela até o final, independentemente de outros aplicativos ou da geografia das pessoas no processo. Em algumas soluções de software em bpm, podemos adicionar um barramento de serviço corporativo separado ou outros componentes ao mecanismo de processo para tornar o conjunto mais versátil.

• Como o mecanismo de processo controla o processo, ele rastreia tudo. Ele sempre sabe o estágio atual do processo e quanto tempo cada tarefa levou para ser concluída. Como o mecanismo de processo monitora diretamente as principais indicações de desempenho, ele fornece um meio de analisar o desempenho. Isso oferece um enorme potencial para o controle bem-sucedido do processo.

Os três recursos acima justificariam a implementação de um mecanismo de processo, mas há uma quarta justificativa: o mecanismo de processo funciona com base em um modelo de processo executável. Nos melhores casos, esse modelo pode ser desenvolvido ou pelo menos entendido por alguém que não é técnico. Isso promove uma comunicação genuinamente boa entre os negócios e isso, e pode até resultar em documentação do processo que corresponde à realidade.

Isto leva ao BPMN.

1.2 Porque BPMn?