Referencial Teórico Vendas

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

Referencial Teórico Vendas

Equipe 1 - Processo de Negócio: Vendas[editar | editar código-fonte]

Tommy - Traduzir pag 4, 5 pdf

Anderson - Traduzir pag 6, 7 pdf

Claudio - Traduzir pag 8, 9 pdf

Felipe - Traduzir pag 10, 11 pdf

Fernando - Traduzir pag 12, 13, 14 pdf

1.1.3 Ciclo de vida do Camunda BPM

1.2 Por que BPMn?

1.3 Pode o BPMn ser uma ponto para o abismo?

1.3.1 O dilema

1.3.2 Os clientes de uma modelagem de processo

1.3.3 Um esquema de metodologia para a modelagem BPMn

2 A notação em detalhes

2.1. Entendendo o BPMn

2.1.1. O que o BPMn não faz

2.1.2 Mapeamento dos elementos básicos do BPMn

2.1.3 Perspectivas na análise de processos

2.1.4 Modelos, instâncias, tokens e correlações

2.1.5 Símbolos e atributos

2.2 Simples tarefas e eventos nulos

Isto leva ao BPMN.

1.2 Porque BPMn?

Fig. 1.3 - Exemplo de um processo simples no formato BPEL, gráfico e como XML

Fonte: Freund e Rücker (2012).

OMG aprovou a versão 2.0 (para a qual a camada contribuiu). Agora, BPMN significa "Modelo de Processo de Negócios e Notação". Não apenas a notação foi definida, como também o "modelo de meta". O OMG é altamente considerado. É famoso pelo padrão UML (Unified Modeling Language) usado no design de software. O patrocínio do OMG ao BPMN agrega credibilidade à lógica que os gerentes da empresa já possuem para escolher um modelo padronizado. BPMN é uma especificação. Ele existe como um documento simples que você pode baixar gratuitamente em formato PDF no OMG [QbjQ9J. O BPMN versão 1.2 tinha cerca de 320 páginas; O BPMN versão 2.0 possui cerca de 500 páginas. (Ambos estão disponíveis apenas em inglês.) Esses documentos definem todos os símbolos do BPM, seus significados e as regras para usá-los. Antes da versão 2.0, não era possível executar modelos de processo BPMN diretamente nos mecanismos de processo. A versão 1.2 ainda não havia definido todos os atributos técnicos necessários para execução, e isso resultou em várias tentativas infelizes de converter (ou "mapear") modelos BPMN em modelos BPEL (consulte a Seção 53_). O BPMN 2.0 permitiu a execução direta de modelos de processo BPMN em mecanismos de processo, o primeiro critério importante a favor de seu uso. O segundo critério importante foi a padronização, que produz os seguintes benefícios:  Você fica menos dependente de certas ferramentas de BPM porque não precisa aprender uma nova notação toda vez que muda de ferramenta. Mesmo agora, existem mais de 70 ferramentas BPMN disponíveis (e muitas são gratuitas, o que é maravilhoso, mas reduz a resistência à mudança de uma ferramenta para outra). A probabilidade aumenta de que seu clientes, fornecedores, consultores etc. têm uma noção do BPMN e, portanto, entenderão seus modelos de processo mais rapidamente.

Quando você contrata novos funcionários, as chances são maiores de que eles já lêem e podem criar modelos de processo BPMN.

Você pode se beneficiar do investimento feito por universidades e empresas privadas que compartilham suas soluções avançadas de BPMN. A estrutura do BPMN que apresentaremos na seção a seguir é um exemplo. Nós nunca o teríamos desenvolvido a menos que o BPMN fosse um padrão.

1.3 Pode o BPMn ser uma ponto para o abismo?

1.3.1 O dilema

Primeiro, o BPMN fornece um conjunto de símbolos. Segundo, implica uma metodologia que se expressa como regras para combinar graficamente os símbolos. Terceiro, as definições de símbolos e as regras para aplicá-las são chamadas de sintaxe. Quarto, o significado dos símbolos e construções que você pode modelar com os símbolos é chamado de semântica.

Infelizmente, apenas conhecer os símbolos do BPMN não é suficiente para você criar modelos de processos úteis. Desde 2007, usamos o BPMN extensivamente e com frequência, e você pode acreditar que sofremos terrivelmente! Sofremos principalmente porque sempre tentamos modelos com sintaxe correta e semântica consistente, em outras palavras, modelos inequívocos. Outros escolheram o caminho mais fácil, dizendo: "Nosso modelo de processo não é sintaticamente correto e não é inequívoco. Mas isso não importa, porque o principal é que o consumidor entende! "Essa atitude sai pela culatra porque:  Quando você aplica o BPMN de forma sintática 265 de maneira incorreta, você perde todos os benefícios da padronização. (Afinal, para que você precisa de um padrão se todos os modelos parecerem diferentes no final?) Muitas ferramentas BPMN nem sequer permitem a modelagem sintaticamente incorreta. Imprecisões ou inconsistências semânticas sempre criam o risco de que seu modelo seja mal interpretado. Esse risco é particularmente alto se você criar um modelo de processo inconsistente do estado de destino e enviá-lo à TI para implementar. Se você deseja fornecer seu modelo de processo diretamente ao mecanismo de processo, deve torná-lo correto, preciso e consistente. Nesse ponto, você ainda precisa reconciliar dois objetivos contraditórios:

1. Diferentes consumidores devem entender e aceitar o modelo de processo. Facilitar a compreensão do modelo ajuda a chegar a um acordo.
2. Como o modelo de processo precisa atender aos requisitos da modelagem formal, geralmente há um nível inevitável de complexidade. Isso dificulta a compreensão que leva ao acordo. O fracasso em reconciliar os objetivos, em preencher a lacuna no entendimento entre negócios e tecnologia, é a principal razão pela qual os modelos de processos tiveram sucesso limitado no passado. A má notícia é que somente o BPMN também não terá sucesso! Assim como no idioma falado, você pode usar o BPMN e ter sucesso ou falhar. Como na linguagem falada, o uso bem-sucedido de XXX

O BPMN depende de com quem você deseja se comunicar e sobre o que. Você fala com seus colegas sobre o trabalho que todos conhecem tão bem de maneira diferente do que com seus três anos sobre o motivo pelo qual o gato não gosta de ser puxado pelo rabo. Da mesma forma, você precisará de outros modelos de processos BPMN para coordenar com seus colegas de trabalho do que para apresentar o processo futuro à alta gerência. (Decida por si mesmo se o último cenário é semelhante à situação de bebês e gatos.)

Por um lado, modelos de processo BPMN diferentes são necessários para públicos e tópicos específicos, para que possam ser entendidos. Por outro lado, cada modelo deve conter todos os detalhes necessários para o tópico. O BPMN pode ser uma "linguagem comum" para negócios e TI, mas o fraseado permanecerá diferente.

O seguinte entendimento é, portanto, imperativo para o seu trabalho com o BPMN:

A precisão e a correção formal do modelo de processo devem variar dependendo do objetivo da modelagem e dos consumidores esperados.

1.3.2 Os clientes de uma modelagem de processo

Sempre que modelamos processos, temos que trabalhar de maneira focada no cliente. Devemos sempre manter o consumidor do nosso modelo em mente. Nós devemos nos colocar no lugar dele. Parece simples, mas poucos modelos de processo realmente suportam essa orientação.

Como já dissemos, o conhecimento, as habilidades e os interesses das pessoas que veem nossos modelos de processos variam bastante. Na lista a seguir, compilamos os tipos que encontramos em nossos projetos de BPM. Essas descrições são para os papéis desempenhados em relação ao projeto; elas não são os cargos das pessoas em qualquer organização. O que descobrimos é que, quanto mais experiência uma empresa desenvolve com BPM, mais consistente esses papéis são cumpridos. Recomendamos a familiarização com:

• Gerente de processo: os gerentes de processo têm responsabilidades estratégicas por processos. Eles estão muito interessados em otimizar o desempenho. Eles geralmente têm autoridade orçamentária, mas antes de assinarem, precisam estar convencidos de que seu plano de melhoria funcionará. Na maioria das empresas, os proprietários de processos habitam a primeira ou a segunda camada de gerenciamento. Eles podem ser membros de comitês de gestão ou chefes de grandes divisões. Gerente de processos: os gerentes de processos têm responsabilidade operacional por seus processos. Eles se reportam direta ou indiretamente aos proprietários do processo. Eles se candidatam a projetos de melhoria, atuando como parte requisitante de serviços externos. Os gerentes de processo geralmente são gerentes de nível baixo ou médio.

• Participante do processo: os participantes do processo trabalham com os processos e, na verdade, criam valor. O relacionamento deles com o gerente de processos varia muito. Nas empresas organizadas por divisões funcionais - vendas, logística etc. -, um gerente de processos é um executivo funcional da divisão em que o processo é realizado. Os participantes do processo se reportam diretamente a esse executivo funcional. (Se o processo for realizado entre departamentos, o que é comum especialmente em organizações matriciais de processo, veja a figura 1.4 podem surgir conflitos entre os executivos do departamento. A modelagem de processos sozinha não pode resolver esses problemas.)

Fig. 1.4 - A matriz de organização dos processos

Fonte: Freund e Rücker (2012).

• Analista de processos: As principais competências dos analistas de processos são o BPM em geral e o BPMN em particular. Eles suportam os gerentes de processo como prestadores de serviços internos ou externos em todas as etapas do ciclo de vida do BPM. Um analista de processos pode ser o contato de provedores de serviços externos ou atuar como o representante do gerente de processos. Dentro da empresa, os analistas de processos geralmente têm sua própria esfera de competência em BPM, como a organização comercial, ou fazem parte de suas divisões de TI. No entanto, é raro um analista de processos ser responsável pela implementação técnica.

O analista pode gostar de trabalho técnico, conhecer o BPMN de um lado para o outro, mas seus pontos fortes são como organizador e comunicador. Como construtor de pontes entre negócios e TI, o analista de processos é o centro de todo projeto de BPM. Cerca de 70% das pessoas que reivindicam ou são designadas para essa função, em nossa experiência, são pouco qualificadas porque não possuem as predisposições analítica. A qualificação mais importante de um analista de processos não é uma facilidade para enviar informações, mas uma facilidade para recebê-las. Os bons analistas de processos naturalmente querem entender tudo completamente. Ao mesmo tempo, eles têm muita empatia em relação as outras pessoas envolvidas e elas podem personalizar sua comunicação para cada grupo. Eles se lembram de todos os detalhes, mas também protegem sensivelmente os detalhes daqueles para quem os detalhes seriam apenas uma distração.

Os gerentes de projeto são bons analistas de processos? Não, nem o gerente de projetos deve ser a mesma pessoa que o analista de processos. A maioria dos gerentes de projeto se vê como "indivíduos dinâmicos, orientados para a ação", que constantemente precisam "levar alguém a bordo" ou "puxar castanhas do fogo". Eles podem ser extremamente hábeis em delegar responsabilidades (e honestamente, alguns são sacos de ar sem noção). Pode parecer ideal que um bom analista de processos também gerencie um projeto de BPM, mas isso raramente funciona.

Engenheiro de processo: Os engenheiros de processo usam a tecnologia para implementar o processo do estado de destino modelado pelos analistas de processo. Nos melhores casos, eles fazem isso no mecanismo de processo, que automatiza o processo. Você pode chamar um programador que programa a lógica do processo em Java, C # ou outra linguagem como engenheiro de processo. O principal trabalho do programador leva durante o estágio de implementação do ciclo de vida do BPM, embora o analista de processo também possa envolver o engenheiro de processo em outros estágios.

Agora que descrevemos os clientes em potencial de um modelo de processo, podemos conversar sobre como os modelos devem ser para manter esses clientes felizes.

1.3.3 Um esquema de metodologia para a modelagem BPMn

Em nossos projetos de consultoria e em nossas oficinas, introduzimos muitas pessoas de todos os tipos de empresas no BPMN. A partir dessa experiência coletada, desenvolvemos uma estrutura prática para a aplicação do BPMN. A estrutura nos ajuda a decidir quais símbolos e construções do BPMN usar em quais situações - e também quando reter no interesse da simplicidade. A estrutura concentra-se em projetos com processos que precisam de suporte tecnológico aprimorado e onde é o estado-alvo que precisa ser modelado. Em princípio, o que mostramos como padrões de modelagem também pode ser aplicado a outros cenários, como a descoberta, documentação e análise de processos do estado atual. Nós e nossos clientes tivemos experiências positivas com essa estrutura, mas mesmo que você não queira copiá-la exatamente, tente usá-la como referência para suas próprias convenções de modelagem.

A estrutura camunda BPMN (caBPMN) mostrada na figura 1.5 consiste em quatro níveis. Os níveis 1, 2 e 3a são os mais interessantes, que discutiremos em detalhes no restante deste artigo.

Fig. 1.5 - Esquema de modelagem BPMn Camunda (caBPMn)

Fonte: Freund e Rücker (2012).

• Fora do escopo: cenário do processo: desenvolvemos nossa estrutura especificamente para projetos que envolvem um processo individual ou um grupo gerenciável de processos relacionados. (Por enquanto, não vamos lidar com modelagem cenários de processos inteiros usando, por exemplo, os chamados mapas de processos. O portfólio do BPMN não contém mapas de processos.) Mesmo quando já modelamos um ou mais cenários de processos usando o BPMN a pedido do cliente, principalmente com os pools e fluxos de mensagens recolhidos descritos na seção 2.9.

• Nível 1: Modelo de processo estratégico: o grupo-alvo principal para os modelos de processo de nível 1 são proprietários e gerentes de processo. Um grupo secundário no início do Projeto pode incluir participantes e analistas de processos. Fornecemos isso como uma representação geral do processo, orientada para resultados. Queremos criar o entendimento mais rápido possível do procedimento para um público que não possui conhecimentos especiais do BPMN. Esboçamos o processo em algumas etapas como uma visão geral. Não mostramos erros ou variações. Consulte o Capítulo 3 para obter informações mais detalhadas sobre a criação de modelos de nível 1.

• Nível 2: modelo de processo operacional: nesse nível, investigamos os detalhes operacionais do processo real. Esses modelos são necessários para orientar os participantes em seu trabalho diário, mas também são cruciais para o analista de processos analisar pontos fracos e possíveis melhorias. A grande conquista de um analista de processos é desenvolver um modelo de processo de Nível 2 que não apenas coordene com o modelo de processo organizacional, mas que também possa ser entregue ao engenheiro de processo para aperfeiçoamento e implementação real no Nível 3. No Capítulo 4, descreva nosso procedimento para isso, adaptado ao BPMN.

• Nível 3a: modelo de processo executável: recomendamos a implementação do processo em um mecanismo de processo. Como isso nem sempre é possível, subdividimos a estrutura caBPMN: nível 3ª delas, refinando o modelo de processo criado no nível 2 para um mecanismo de processo. Isso só se tornou possível com o BPMN versão 2,0; explicamos no capítulo 5.

• Nível 3b: especificação de TI: sem um mecanismo de processo, você deve implementar a lógica do processo com uma linguagem de programação convencional - ou um sistema ERP ajustável ou algo semelhante. Isso geralmente requer especificações técnicas adicionais antes do início da implementação, e o procedimento depende da plataforma. O BPMN desempenha um papel subordinado nesses casos. Abordamos essa possibilidade em seção 4.4.5 em termos de documentação de alterações, mas não há escopo para este livro.

• Nível 4: Implementação: é aqui que o processo é realmente tecnicamente implementado em uma plataforma "convencional". Se você usa um mecanismo de processo, não precisa de especificações de TI separadas, e é por isso que nossa pirâmide é assimétrica.

As estruturas do caBPMN são puramente metódicas. Em outras palavras, ele funciona independentemente de ferramentas de software específicas, embora determinadas funções da ferramenta facilitem a aplicação. Lidamos com isso na Seção 6.4.2.

Como esses capítulos oferecem tantas informações práticas, recomendamos que você as leia, mesmo que não esteja convencido da utilidade de nossa estrutura. Se for esse o caso, pense em nossa estrutura como um sistema de classificação para nossos conselhos sobre a aplicação prática do BPMN.

Aguardamos seus comentários, não apenas neste livro, mas também na própria estrutura do caBPMN. Não é perfeito e não é final - e sempre pode ser melhor. Com a sua ajuda, talvez possamos melhorar para todos!

2 A notação em detalhes

2.1. Entendendo o BPMn

BPMn (Business Process Management notation) é um padrão de “desenho”, ou melhor, “modelagem” (em inglês, seria traduzido por design mas poderia ser melhor designado por drawing). Serve para modelar os processos de negócio. Neste trabalho vai ser focado a versão 2.0 do BPMn.

O que um macaco sabe sobre o sabor do gengibre?

Este provérbio indiano expressa o truísmo de que você não pode apreciar completamente o que não entende: "Não jogue pérolas aos porcos".

O BPMN é uma pérola que nem todo mundo pode apreciar porque nem todo mundo entende. Se você é novo no padrão, não se arrependerá de gastar algum tempo para se familiarizar com o que ele entende. Se você é novo no padrão, não se arrependerá de gastar algum tempo para se familiarizar com os princípios subjacentes. Para quem já conhece a especificação BPMN, este capítulo fornece explicações e dicas além da própria especificação. Também descreve as convenções visuais que usamos ao aplicar símbolos. Esta é a nossa etiqueta do BPMN.

Um entendimento completo faz do BPMN uma ferramenta extremamente poderosa para qualquer projeto BPMN moderno. Em nossa experiência, no entanto, mesmo aqueles com alta confiança em seus conhecimentos sobre BPMN ainda podem deixar de entender certos princípios fundamentais, e geralmente expressam supremacia pelo fato de que os fluxos de sequência não devem ser traçados através dos limites do pool.

2.1.1. O que o BPMn não faz

O BPMN foi desenvolvido para modelar processos: sequenciador lógico e cronológico de eventos. Isso é tudo. No entanto, você costuma ouvir o BPMN sendo criticado por não representar:

• Paisagens de processo

• Estruturas organizacionais

• Dados

• Estratégias

• Regras do negócio

2.1.2 Mapeamento dos elementos básicos do BPMn

Quando um diagrama de processo BPMn é desenhado, utiliza-se símbolos que podem ser categorizados como na figura 2.1, que são os elementos básicos de BPMn.

Fig. 2.1 - Elementos básicos de BPMn

Fonte: Freund e Rücker (2012).

2.1.3 Perspectivas na análise de processos

2.1.4 Modelos, instâncias, tokens e correlações

De acordo com Freund e Rucker (1995, p. 15), na especificação BPMn se introduz a ideia de que o comportamento do diagrama deve ser entendido claramente , pois um diagrama pode possuir várias raias e inúmeros processos, tornando difícil o entendimento do negócio . Essa mesma ideia é mais fácil em teoria do que em prática, pois alguns modelos de processos são tão complexos que se torna difícil de  saber como fazer com que o diagrama BPM fique bem organizado. Levando em consideração tudo isso, deve-se ter em mente a explicação dos seguintes tópicos:

• Modelo de Processo: A descrição básica do processo. Um diagrama pode descrever um ou mais modelos de processo.

• Instância do processo: Um processo carrega mais informação do que aparenta na realidade - O que uma pessoa leiga chamaria de “operação”. Por exemplo, a reclamação de um cliente é uma instância de processo de reclamação Alguns processos podem ser iniciados algumas vezes em um ano, e outras instâncias ocorrem mais frequentemente, por exemplo, ao ter um exemplo de processo em que ocorrem milhões de pedidos de relatórios de créditos em um período de um ano em uma determinada empresa.
• Rotas: Pode se aplicar o modelo de rota ao possuir um modelo de processo em mente do qual já se sabe quais processos devem ou podem ser usados durante uma instância de um processo. Uma rota é um conceito semelhante a compra de um carro. Um carro segue a estrada da qual possui uma divisão, nisso, o condutor deve decidir continuar em frente ou pode virar a direita ou esquerda. Logo, a rota corresponde ao modelo de processo e a cada caminho particular do carro representa uma instância. O modelo de rota pode ajudar a entender até o mais complexo processo de modelo de BPMN.

2.1.5 - Símbolos e atributos:

A especificação do BPMN descreve os símbolos providenciados para o modelo de processo, sendo também descrito de vários atributos. Muitos desses atributos não se parecem diagramas, pois eles são armazenados na ferramenta de modelagem e usados quando a ferramenta do processo executa os modelos. (FREUND ,J; RUCKER, 2012, p 15)

2.2 Simples tarefas e eventos nulos