Upload
vinicius-ferreira
View
226
Download
0
Embed Size (px)
Citation preview
8/19/2019 6.4 Aula Transcrita
1/58
6.4 Modelagem de SistemasOrientada a Processos
8/19/2019 6.4 Aula Transcrita
2/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
2
RESUMO
Aula: 6.4 Modelagem de Sistemas Orientada a Processos – Transformando o Processo TO BE em Sistema
Tutor: Eduardo Britto, MSc, PMP, OCEB, CDIA+
Número de slides: 47 Duração da Aula: 62 min
SLIDE 1
8/19/2019 6.4 Aula Transcrita
3/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
3
SLIDE 2
Olá, sejam todos bem vindos a nossa última aula, deste módulo 6, sobre tecnologia e BPM. A aula de hoje irá abordar sobre o
tema de modelagem para automação de processos.
Para isso, iremos conversar a respeito da modelagem de sistemas orientada a processos e;
Iremos, também, apresentar como realizamos a modelagem de processo para prepará-lo para a automação;
Fechando, então, a nossa aula com os conceitos-chave apresentados.
8/19/2019 6.4 Aula Transcrita
4/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
4
SLIDE 3
Vamos, então, começar falando sobre a modelagem de sistemas orientada a processos.
8/19/2019 6.4 Aula Transcrita
5/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
5
SLIDE 4
O que significa modelagem de sistemas orientada a processos? Vamos começar explicando a partir de uma história que
vemos acontecer de forma muito recorrente nos mais diferentes tipos de organização. Essa história começa com a área de
negócios mapeando seus processos, avaliando suas oportunidades de melhoria, discutindo esse processo em reuniões com
diferentes áreas, até chegar o momento em que ela tem o seu processo redesenhado, um modelo to be. Como é muito
comum, a implementação desse processo to be exigirá alteração no sistema de informações existentes, de modo que a área
de negócios ou escritório de negócios envia esse processo, que foi o elemento principal da sua discussão, junto com todas as
regras de negócio e informações discutidas para a análise da área de TI. Ao chegar na TI, toda essa documentação é analisada
por um analista de sistemas que verifica quais os sistemas serão impactados, se será necessário o desenvolvimento de um
novo sistema e monta, então, a partir disso, o que chamamos de um documento de requisitos, que mostra, através de uma
lista de requisitos, todo escopo e esforço que será necessário para atender as demandas do negócio. Esse documento de
requisitos é enviado para a aprovação pela área de negócios e, uma vez aprovado, o projeto, então, pode ser iniciado. O
projeto de implementação começa com uma etapa de analise de sistemas que terá como resultado uma ampla
documentação mostrando, através de requisitos, casos de uso e protótipos de tela, todos os detalhes do que será
implementado para atender as necessidades do negócio. Com a ciência da área de negócios a TI, então, realiza a
programação de tudo o que ela identificou que teria que fazer para atender o escopo do projeto. Ao terminar o seu
desenvolvimento são organizados treinamentos para que os usuários conheçam os sistemas desenvolvidos, e aí, os principais
usuários de cada área fazem a homologação do sistema de modo que este possa, então, entrar em produção.
8/19/2019 6.4 Aula Transcrita
6/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
6
SLIDE 5
Qual é o grande problema pensando sobre o ponto de vista da gestão por processos nessa história que foi contada? O
problema é que, a partir do momento em que o processo saiu do escritório de processos, ele sumiu, desapareceu, ninguém
mais na TI falou sobre o processo.
E por que isso acontece? Entre inúmeros motivos nós podemos citar o fato, primeiro, que a TI, via de regra, não está
preparada para trabalhar com processos, ela não tem isso nem na sua cultura e nem na sua formação. Além disso, as
ferramentas convencionais de desenvolvimento não estão preparadas para a visão de processos. Ferramentas clássicas de
modelagem, tais como, ferramentas case, ferramentas de modelagem por caso de uso, ou de um ML e, também, linguagem
de programação convencional, como JAVA e Dotnet, não tem incorporadas em si a visão de processos.
A cultura da TI é uma cultura orientada a requisitos, casos de usos e telas, dessa forma, seja o que for o que a área denegócio apresente para a TI, via de regra, o que os analistas de sistemas irão fazer é transformar essa demanda em telas e
requisitos. Dessa forma, uma demanda que veio orientada a processos se transforma em um conjunto de especificações
funcionais, que descrevem o funcionamento de telas e sistemas. O processo que foi encaminhado acaba desaparecendo. Por
exemplo, digamos que a área de negócio tenha mapeado um processo que passava por vinte papéis diferentes
correspondentes aos colaboradores de oito áreas distintas da empresa. Ao chegar na TI, possivelmente esse processo vai se
tornar uma especificação funcional para cada um dos sistemas impactados. Muito do que estava descrito no processo será
realmente executado através desses sistemas.
É interessante notar que a implementação de um sistema não muda o que é feito em cada atividade, mas mudo o como é
feito. É como aquele exemplo do colaborador que enviava uma ordem de compra para um fornecedor via fax, e agora, com
automação, não precisa mais se preocupar com isso, pois o próprio sistema já encaminha esse documento automaticamente.
O sistema, aqui nesse exemplo, não mudou o que é feito, ou seja, a ordem de compra continua sendo enviada para o
8/19/2019 6.4 Aula Transcrita
7/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
7
fornecedor, mas o sistema tirou a responsabilidade do papel do colaborador e colocou essa responsabilidade como uma
tarefa automática de um sistema.
Então, a gente pode notar que o processo “to be” i mplementado, via de regra, é diferente do “to be” original. A automação
dos sistemas acaba mudando o processo ao torná-lo mais eficiente através da aplicação da tecnologia. Contudo, essa nova
versão do processo, que foi alterada devido às melhorias implementadas, não está mais mapeado.
E o que acontece, então, com a área de negócios um, dois ou seis meses depois deseja rodar um novo ciclo de melhorias
desse processo? O que acontece é que ela tem que fazer um novo “ as is”, porque o “to be” que ela desenhou não foi
exatamente aquilo que foi implementado devido as mudanças ocorridas na TI. Para tornar esse cenário ainda mais difícil, as
empresas costumam ter historicamente como cultura organizacional a ideia de desenvolver sistemas verticais para
determinadas áreas da organização. É o sistema de RH, o financeiro, o sistema administrativo, o sistema de vendas, o sistema
de compras. Os sistemas, via de regra, são verticais, costumam atender a somente uma área, só que os processos, esses são
horizontais, porque ao longo de um processo várias áreas são atendidas e, portanto, ao longo de um processo nós
trabalhamos com inúmeros sistemas.
8/19/2019 6.4 Aula Transcrita
8/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
8
SLIDE 6
Dessa forma, o que acaba acontecendo é o que vemos nessa figura, um enorme gap na comunicação que existe da área de
negócios para a área de TI, e novamente no retorno da área de TI para a área de negócios. A área de negócios entrega um
processo que desaparece na área de TI, e a área de TI entrega de volta um sistema que precisa ser reinterpretado na forma
de um processo para que novas melhorias possam ser realizadas.
8/19/2019 6.4 Aula Transcrita
9/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
9
SLIDE 7
Para resolver este problema surge a ideia da modelagem de sistemas orientada a processos. A principal diferença dessa
abordagem é que nela, o processo é o ponto principal da análise de sistemas. Tudo o que será desenvolvido e todas as
alterações e impactos identificados deverão acontecer para atender o processo, e tudo que não diga respeito ao processo
não deve ser considerado. O objetivo do sistema, então, passa a ser o atendimento ao processo, a sua execução e
automação, e dessa forma, a representação do processo automatizado torna-se o principal elemento no momento de se
avaliar as mudanças que serão realizadas nos sistemas.
8/19/2019 6.4 Aula Transcrita
10/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
10
SLIDE 8
8/19/2019 6.4 Aula Transcrita
11/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
11
SLIDE 9
Assim, a modelagem orientada a processos traz para o desenvolvimento as seguintes características, primeiro ela aproxima
muito mais a área de TI da área de negócios, uma vez que o processo representa o entendimento da área de negócios sobre
a sua realidade e o sistema está sendo desenvolvido para atender as demandas deste processo, torna-se mais natural o
alinhamento entre a área de TI e a área de negócios. Dessa forma, uma mudança em um sistema acaba tendo sempre como
motivador o atendimento de uma regra de negócio de um processo.
O processo que norteia as mudanças que serão feitas no sistema. Além disso, o processo é uma das melhores ferramentas
que temos para entender o negócio de uma forma completa, pois o processo apresenta, via de regra, uma visão integrada,
de ponta a ponta, da organização. Assim, à medida que a TI trabalha em cima do processo, o seu entendimento e a
comunicação com o negócio tendem a evoluir significativamente. A análise orientada a processos também traz uma enorme
oportunidade para a empresa de trabalhar na identificação dos seus serviços, pois a cada momento que for identificada uma
necessidade de interação do processo com o sistema, um serviço nesse sistema terá sido identificado.
O sistema proposto, então, será um sistema que irá dar suporte a execução do processo, e se possível, através de uma
plataforma de BPMS. Este sistema irá garantir a execução do processo, será próativo na identificação de atrasos, irá
coordenar a comunicação entre os atores do processo, e trará, então, todos aqueles benefícios que conhecemos na nossa
primeira aula.
8/19/2019 6.4 Aula Transcrita
12/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
12
SLIDE 10
A modelagem de sistemas orientada a processos irá, então, seguir alguns princípios que devem ser observados para sua
efetiva aplicação. Primeiro, o processo torna-se o contrato entre a TI e a área de negócios. O processo nada mais é do que o
escopo do sistema e tudo que será desenvolvido se baseará no que está definido no processo. O atendimento das
necessidades do negócio pela TI será representado pelo atendimento das necessidades que estão documentadas no
processo. Nesse sentido, a visão de processos sempre irá prevalecer sobre a visão de sistemas. As funcionalidades, que serão
ou não desenvolvidas, serão identificadas com base no que o processo está solicitando. Se o usuário desejar, por exemplo,
um novo recurso cuja necessidade não está definida no processo esse recurso será protelado em relação a outras
necessidades que foram identificadas pelo processo. Se por um lado o processo ganha posição de extremo destaque, por
outro é fundamental que o mesmo já se encontre maduro na área de negócios.
Um processo enviado para automação em que existam muitos pontos de dúvida ou discussão é um processo que deve
permanecer por mais tempo nas etapas de mapeamento e redesenho. O processo para ser enviado para a TI deve
representar uma visão de consenso por todos os atores que atuam sobre ele. Esse consenso pode ser obtido a partir de uma
validação do modelo já existente, de uma revisão do processo, ou até mesmo de um redesenho. Aqui é importante destacar
que um processo não precisa, necessariamente, passar pela etapa de redesenho para ser enviado para automação. Em
muitos casos o processo as is, como é feito atualmente, atende a área de negócios, e dessa forma, poderia apresentar
maiores ganhos ainda se fosse automatizado. É claro, que todo processo sempre pode melhorar em uma etapa de
redesenho, mas gostaríamos de trazer aqui, que em muitos casos, por questões de prazo, custo ou até mesmo por achar que
o processo já está bem apresentado, esse processo pode ir diretamente do modelo as is para o modelo de automação. Ao
receber o processo, a TI irá fazer uma análise funcional muito parecida com o que ela faz quando trabalha na modelagem de
um sistema, mas aqui o objetivo será o entendimento do processo e o desenvolvimento do seu modelo to do buscandoaumentar a eficiência do processo através do uso da tecnologia. A partir dessa análise são identificados e os sistemas se
8/19/2019 6.4 Aula Transcrita
13/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
13
integrarão ao processo, e para cada sistema será feita uma análise de quais mudanças ou melhorias serão necessárias para
atender o processo.
8/19/2019 6.4 Aula Transcrita
14/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
14
SLIDE 11
Esses princípios são a base para automação de processos, que nada mais é do que o desenvolvimento de sistemas de
informação, cujo objetivo está em automatizar a execução e o controle de um processo de negócios.
8/19/2019 6.4 Aula Transcrita
15/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
15
SLIDE 12
A modelagem do processo automatizado passa pelo levantamento de uma série de dados e informações que o analista de
sistemas deve avaliar e que podemos resumir na lista apresentada nesse slide.
Inicialmente o analista deverá identificar quais são os processos que serão modelados e qual o seu escopo, ou seja, onde
começa e onde termina cada processo. Para cada processo identificado ele fará uma análise detalhada das atividades que o
compõe, identificando que atividades são humanas, quais são automáticas e quais são sub-processos. Além disso, ele fará
uma análise das necessidades do processo em termos de uso de sistemas legados da empresa. Ele irá analisar, entre outras
situações, primeiro como inicia o processo, é muito comum que o novo processo de negócio se inicie a partir do cadastro de
uma informação em um sistema. Ele irá também analisar se não são necessárias aplicações de apoio a execução de cada
atividade humana.
Outra demanda por sistema que pode ocorrer é devido à necessidade de execução de alguma regra de negócio que está
disponibilizado em um sistema. É comum também surgir a necessidade de se implementar novas aplicações de cadastro,
devido as demandas do processo. Outra aplicação típica que se costuma desenvolver para apoio ao processo são as
aplicações de acompanhamento, que permitem que se consultem os dados do processo e todo o seu histórico. Finalmente,
serão avaliadas as integrações que serão exigidas pelo processo com os sistemas legados da empresa. Além da análise dos
sistemas, também são avaliadas as necessidades de implementação de indicadores.
8/19/2019 6.4 Aula Transcrita
16/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
16
SLIDE 13
Para auxiliar no entendimento de como funciona a modelagem orientada a processos nada melhor do que apresentarmos
um processo de exemplo. Este é um processo de RH chamado de Abertura de Novas Vagas, processo que é iniciado sempre
que algum centro de custo da empresa gostaria de solicitar a abertura de um novo posto de trabalho. Este processo, então, é
o responsável pela aprovação desta abertura.
8/19/2019 6.4 Aula Transcrita
17/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
17
O processo é iniciado com o preenchimento da solicitação e a primeira atividade é a atividade do gestor do centro de custo,
que pode aprovar, solicitar alterações ou reprovar o pedido. Se a solicitação é aprovada, a mesma é encaminha, então, para
uma aprovação hierárquica que irá depender do cargo que for aberto. Por exemplo, uma vaga de vendedor, em uma loja,
terá uma estrutura de aprovação muito mais simples e completamente diferente do que a estrutura da abertura de uma
vaga de tesoureiro.
Com o objetivo de garantir a integridade do processo e de que as pessoas corretas aprovem a solicitação, a identificação da
estrutura hierárquica, da aprovação de cada cargo, e as pessoas que ocupam cada papel, serão armazenadas em um sistema
que irá indicar quais são as aprovações necessárias para cada cargo e, após cada aprovação, irá indicar de existem
necessidades de aprovações adicionais. Cada um dos aprovadores pode, então, aprovar ou reprovar a solicitação, e sempre
que a mesma é aprovada é verificado novamente se a aprovação feita foi a última aprovação, ou se a solicitação deve ser
encaminhada para uma nova aprovação na estrutura hierárquica. Se o gestor do centro de custo ou algum dos aprovadores
recusarem o pedido, o solicitante é avisado e o processo é encerrado. Contudo, quando todos aprovarem, a última
aprovação será do RH. Se o RH também aprovar, os dados da vaga serão incluídos automaticamente no sistema de
recrutamento de seleção, iniciando, dessa forma, uma nova etapa desse processo. Nesse momento, também, o solicitante é
avisado da aprovação.
Vejam que em todas as atividades de aprovação existe também um controle de tempo, que quando ultrapassado, dispara um
aviso para o solicitante de que o processo encontra-se atrasado. Esta é uma das inúmeras possibilidades de controle de pro
atividade do processo.
8/19/2019 6.4 Aula Transcrita
18/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
18
SLIDE 14
8/19/2019 6.4 Aula Transcrita
19/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
19
SLIDE 15
Vamos, então, analisar este processo com base nos elementos e passos identificados anteriormente e vamos avaliar quais
requisitos são necessários a partir da analise desse processo. O elemento principal a ser avaliado é o próprio processo, que
neste caso é o processo de solicitação de Abertura de Novas Vagas. Este processo é iniciado com o preenchimento de uma
solicitação de abertura, como esse documento, hoje, é um formulário em papel, faz-se necessária a criação de uma aplicação
que permita o preenchimento deste documento. De forma semelhante, temos que ter uma forma de acompanhar o processo
de abertura de vagas, tanto em relação aos seus dados quanto em relação ao andamento do processo, de modo que
precisaremos também implementar uma aplicação de pesquisa de solicitações em andamento.
Toda a lógica de aprovação da vaga irá depender do cargo solicitado e da estrutura hierárquica de aprovação da empresa.
Para garantir que essa vaga será sempre aprovada pelas pessoas corretas é importante que essas informações sejam
armazenadas em um sistema. Contudo, ao buscar esse sistema, o analista identificou que essa estrutura não estavacadastrada em nenhum sistema atualmente, de modo que foi necessário a proposição de um novo sistema que pudesse
armazenar essa estrutura para dar apoio ao processo.
Ao final do processo, se a vaga estiver aprovada, automaticamente os seus dados são inseridos no sistema de recrutamento
de seleção iniciando, assim, uma nova etapa do processo. Dessa forma, o analista de sistemas teve que ir buscar, junto ao
sistema de recrutamento de seleção, quais eram as funcionalidades e serviços que ele dispunha, e descobriu que a única
forma existente, atualmente, para se criar uma nova vaga nesse sistema é através do preenchimento de uma tela. Para
viabilizar a automação dessa atividade, sem necessidade de intervenção humana, foi preciso, então, se definir a criação de
um novo serviço que permitisse a inclusão automática de uma vaga. Por fim, o analista também identificou que o negócio
gostaria da implementação de dois indicadores que mostrassem quantas vagas estavam sendo abertas em média por mês, e
quantas vagas estavam sendo reprovadas por mês e esse analista, então, verificou que o ponto de se colocar esse indicadorera os pontos em que os processos encerravam como aprovado ou encerrava como reprovado.
8/19/2019 6.4 Aula Transcrita
20/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
20
SLIDE 16
8/19/2019 6.4 Aula Transcrita
21/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
21
SLIDE 17
Este processo é um ótimo exemplo da ideia que está por trás do desenvolvimento orientado a processos. Vejam que, ao
longo da análise, foram identificados sete requisitos, sendo que o principal foi o primeiro requisito, de implementação do
processo, e que serviu de base para a identificação de todos os outros seis.
Na modelagem orientada a processos toda a definição de escopo é obtida a partir da análise do processo, as necessidades
que são ou não são atendidas são definidas a partir deste processo. E, como resultado, então, temos um novo processo
desenhado, o processo to do, que mostra como se comportará o processo com base na solução automatizada.
Ao longo dessa análise, o analista vai identificando os diferentes sistemas da organização que interagem com o processo.
Cada vez que uma funcionalidade é identificada cabe a este analista avaliar se já existe algum sistema na empresa que seja
responsável por gerir esta regra de negócios, caso não exista, possivelmente, um novo sistema teria que ser proposto.Contudo, se já houver um sistema, é importante que seja avaliado se esse sistema encontra-se pronto para atender as
demandas identificadas no processo. Se ele não estiver, possivelmente, uma alteração será necessária para que o processo
possa ser atendido. Contudo, caso o sistema já se encontre pronto para atender essa funcionalidade, o próximo passo é
avaliar se já existe um serviço disponibilizado por esse sistema que possa ser chamado pelo processo, se existir nada no
sistema precisará ser alterado para atender o processo, mas se não existir ainda o serviço, possivelmente, deverá ser definida
a criação de um novo serviço dentro desse sistema.
8/19/2019 6.4 Aula Transcrita
22/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
22
SLIDE 18
Vejam que, sob a ótica do ciclo de gestão por processos o desenvolvimento de sistemas se encaixa de uma forma muito
natural. A etapa de modelagem técnica representa, no desenvolvimento convencional de sistemas, as etapas de análise e
projeto; a etapa de implementação nada mais é do que o desenvolvimento do sistema; e a etapa de implementação é a
homologação e a entrada do sistema em produção.
8/19/2019 6.4 Aula Transcrita
23/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
23
SLIDE 19
8/19/2019 6.4 Aula Transcrita
24/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
24
SLIDE 20
8/19/2019 6.4 Aula Transcrita
25/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
25
SLIDE 21
Nesse sentido temos acompanhado que, via de regra, nós temos alguns típicos projetos que rodam o ciclo da gestão por
processos. O primeiro, que é o típico projeto de redesenho, não envolve a TI, e nem mesmo o modelo to do, iniciando com o
mapeamento do processo, o seu redesenho e finalizando com a implantação deste processo sem passar pela TI.
O segundo tipo é aquele que envolve a TI, mas não é suportado por um motor de processos. Nele o mapeamento e
redesenho do processo são realizados e o processo é analisado sobre a ótica da tecnologia criando, assim, o modelo to do.
Contudo, a organização, muitas vezes, não possui ferramentas adequadas para a implementação deste processo, apesar de
ter identificado seus requisitos através da análise baseada em processos. Dessa forma, os sistemas são desenvolvidos ou
alterados, mas o processo não é suportado por um motor de processos e, portanto, continua sendo empurrado
manualmente pela área de negócios.
Uma outra situação bastante comum que vemos ocorrer é quando o negócio tem um processo que já está mapeado e que
ele considera que já está com um bom nível de maturidade, mas este processo pode melhorar muito se for automatizado,
trazendo para si todos os benefícios inerentes a automação, conforme vimos na primeira aula. Nesse caso, a etapa de
redesenho não, necessariamente, precisa ser realizada, visto que o processo já é considerado maduro e que o negócio busca,
nesse momento, melhorias com base na automação. É importante frisar que, em muitos casos, este tipo de projeto ocorre
por dois motivos: ou porque o negócio não possui tempo nem orçamento para realizar o redesenho, ou porque ele gostaria
de ter informações muito mais precisas para redesenhar o processo, e o negócio, então, enxerga que a automação do
processo é uma das formas de se obter essas informações.
8/19/2019 6.4 Aula Transcrita
26/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
26
SLIDE 22
Bom, vamos então agora falar sobre como fazemos a modelagem para automação, iniciando com alguns conceitos.
8/19/2019 6.4 Aula Transcrita
27/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
27
SLIDE 23
Um modelo to do nada mais é do que a representação do processo na forma como ele será implementado. Como falamos
anteriormente, a modelagem to do nunca altera o que é feito em cada atividade, porque esta é uma decisão do negócio.
Contudo, com a evolução da tecnologia e de todas as alternativas que se abrem a partir da sua aplicação, o modelo to do visa
analisar como é a forma mais eficiente de cada atividade ser realizada. Além disso, no modelo to do, todas as possibilidades e
alternativas possíveis dentro de um processo devem ser detalhadas.
Em um modelo to be, muitas vezes, nem todas as exceções são descritas, porque o objetivo do modelo não é ter um
processo extremamente detalhado, e sim, trazer a tona os principais pontos fortes e fracos do processo de modo a
redesenhá-lo. Contudo, o modelo to do representa o processo que será executado e essa execução é de responsabilidade de
um sistema de informação. Porém, um sistema, uma vez definido e implementado, acaba, muitas vezes, engessando a
maleabilidade do processo. O sistema só vai fazer aquilo que está definido, opções que não foram desenhadas nãoconseguem ser representadas e executadas pelo sistema. Dessa forma, ao passarmos a responsabilidade da execução do
processo para um sistema é importante que também sejam avaliadas todas as alternativas possíveis para a execução do
processo, pois uma alternativa não mapeada irá representar o engessamento do processo e, muitas vezes, irá impedir a sua
execução.
Para a modelagem do processo o analista, via de regra, vai fazer a análise dos seguintes elementos: vai identificar quais são
as atividades que compõem o processo, e quais são as suas dependências; tanto para um processo como um todo, como
para cada uma das suas atividades, ele irá analisar quais são os critérios de início e de fim que devem ser atingidos; ele irá
definir quem são os participantes do processo e como o sistema identifica que pessoas que devem receber cada atividade;
finalmente, o analista também avalia quais são as regras de integridade que devem ser observadas para garantir que o
processo está atendendo as regras de negócio.
8/19/2019 6.4 Aula Transcrita
28/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
28
SLIDE 24
8/19/2019 6.4 Aula Transcrita
29/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
29
SLIDE 25
O sistema orientado a processo, por sua vez, tem na sua definição a identificação de quem faz cada uma das atividades
previstas. Um participante, neste caso, pode ser tanto um participante humano, representado por um papel, ou um
participante sistémico. Dessa forma, passa pela modelagem de um sistema orientado a processos, e passa, dessa forma, a
entender quais são as regras que identificam as pessoas dentro de uma organização que possuem um papel, e que lhes
permite receber e executar cada uma das atividades humanas. Para as atividades automáticas são avaliados quais são os
sistemas responsáveis pela execução de cada atividade e se esses sistemas já possuem serviços disponíveis prontos para
serem chamados pelo processo.
O principal trabalho do analista de sistemas, ou analista de BPM, na elaboração do modelo to do, é conseguir lançar mão de
todas as possibilidades possíveis que venham a incorporar a tecnologia ao processo, ou seja, fazer que o processo ocorra de
forma cada vez mais automática, com menor dependência humana e com maior probabilidade de acerto.
A identificação de poucas oportunidades de automação de um processo na passagem do seu modelo to be para um modelo
to do fará com que a sua implementação seja questionável, pois o retorno trazido pela aplicação da tecnologia será muito
pequeno. Dessa forma, o analista de sistemas deve estar atento as seguintes questões:
Ele deve buscar automatizar, ao máximo, as atividades de baixo valor agregado. São consideradas atividades de
baixo valor agregado aquelas atividades cuja análise humana tenha pouca participação, ou atividade onde essa
análise pode ser codificada em um algoritmo que represente os critérios utilizados, ou seja, atividades que podem
ser feitas por sistemas ou atividades cuja decisão pode ser descrita de alguma forma precisa, são atividades que não
precisariam, a princípio, serem feitas por pessoas. A automação dessas atividades poderá trazer grandes ganhos ao
processo, tanto em termos de velocidade de execução, como na diminuição da probabilidade de erros. Além disso, é importante que o analista identifique para cada atividade, quais são as formas práticas e intuitivas do
ator ao receber sua atividade. O responsável pela atividade tem dificuldade em acessar constantemente seu
8/19/2019 6.4 Aula Transcrita
30/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
30
terminal de trabalho na sua mesa? Neste caso, é melhor enviar esta atividade para um dispositivo móvel, ou será
que este ator é um fornecedor ou um cliente da empresa que não tem acesso interno a intranet da organização?
Nesse caso, é melhor que ele receba e responda essa atividade por e-mail . Além disso, é importante que o analista
avalie quais as informações que o ator humano necessita para realizar a sua atividade ou para tomar a sua decisão,
quanto mais o analista de sistemas conseguir identificar essas informações e traze-las já prontas para o usuário,
maior será a agilidade em que a atividade será executada e melhor será a precisão na tomada de decisões.
A distribuição do trabalho de forma automática também poderá melhorar em muito a eficiência do processo, pois irá
permitir que o analista identifique critérios de priorização entre as atividades ou entre instâncias do mesmo processo,
distribuindo as atividades de modo a garantir que, aquelas mais importantes, serão enviadas para participantes que tenham
condições de dar um retorno mais rápido.
8/19/2019 6.4 Aula Transcrita
31/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
31
SLIDE 26
A modelagem do processo to do, então, passa pela identificação e modelagem dos seguintes elementos, que veremos
detalhadamente a seguir.
Quais são os critérios de inicio do processo, ou seja, o que acontece no mundo real para que o processo seja disparado?
Quem são os participantes que executam o processo, que papéis eles possuem e como eles são identificados? Que atividades
são realizadas ao longo deste processo? Essas atividades são humanas, ou seja, realizadas por pessoas? São automáticas,
realizadas por sistemas? Ou são sub-processos que precisam ser detalhados?
8/19/2019 6.4 Aula Transcrita
32/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
32
SLIDE 27
Começando com os critérios de inicio dos processos devemos avaliar o que, no mundo real, acontece para que o processo
seja iniciado. Na grande maioria dos casos, o critério de início é o cadastramento de uma informação em um sistema, é, por
exemplo, uma solicitação de viagem, uma solicitação de abertura de vaga, ou um cadastro de pedido de férias, que é feito
em um sistema ou num formulário eletrônico. Contudo, existem outras situações que também podem exigir o disparo de um
processo. Por exemplo, um processo de reajuste salarial pode ser iniciado a partir do momento em que o cargo de um
funcionário é alterado no sistema de RH, ou um processo de aprovação de um orçamento complementar também pode ser
disparado automaticamente a partir do instante em que o orçamento de uma rubrica estratégica for esgotado, ou ainda
mais, uma solicitação de compra que poderia ser disparada a partir do momento em que o nível de estoque de um
determinado material ficasse abaixo do seu estoque mínimo. Existem inúmeras formas de se iniciar um processo, a mais
comum, como dissemos, é a partir do preenchimento de uma solicitação e uma aplicação ou formulário eletrônico, mas ela
não é a única, e o analista de sistemas deve estar muito atento a isso.
8/19/2019 6.4 Aula Transcrita
33/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
33
SLIDE 28
O próximo ponto a ser analisado são os participantes do processo. Como já comentamos, um participante pode ser tanto
humano como um sistema.
8/19/2019 6.4 Aula Transcrita
34/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
34
SLIDE 29
Os participantes humanos são agrupados em papéis. Um papel identifica uma determinada atividade dentro de uma
organização e de seus processos. Os papéis são definidos a partir de requisitos e atributos que seus atores devem ter, bem
como da forma como a empresa organiza suas atividades. O conceito de papel é fundamental para desvincular a definição do
processo e das pessoas que o executam. As pessoas responsáveis por realizar uma determinada atividade podem ser
alteradas a qualquer momento, já o papel só pode ser alterado com o redesenho do processo. São exemplos de papéis de um
processo de compras o solicitante do pedido de compras, o aprovador, a pessoa que faz a cotação da solicitação, o financeiro
que faz o pagamento da nota fiscal, e o recebimento que recebe a mercadoria.
8/19/2019 6.4 Aula Transcrita
35/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
35
SLIDE 30
Nesta figura, temos o exemplo de um processo de aprovação de crédito, nele temos três papéis bem definidos. Dois deles, de
gerente da compra e de gerente do produto, são papéis de dentro da organização e por isso, estão representados dentro da
piscina do processo. O terceiro, porém, é o papel do cliente que não faz parte da organização e que, por isso, está
representado fora do processo como uma piscina externa.
8/19/2019 6.4 Aula Transcrita
36/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
36
SLIDE 31
O papel distribui as responsabilidades pela execução de cada atividade do processo. Nesse sentido, é muito comum termos
alguns papéis que são definidos a partir de um cargo ou de uma função do colaborador dentro da empresa. Por exemplo,
podemos ter a função de presidente, ou de tesoureiro, e termos atividades que são claramente exercidas por pessoas que
ocupam essas funções. Podemos também ter o cargo de médico do trabalho, e termos novamente atividades que são
exercidas diretamente por este cargo. Outro papel bastante comum é o de gestor como, por exemplo, o gerente ou diretor
de um determinado centro de custo ou área da organização. Contudo, nem sempre essa relação é direta, em muitas
empresas, por exemplo, temos o cargo de auxiliar administrativo que, por ser um cargo de ampla aplicação, tem suas
atividades definidas muito mais pelo local e pela função onde está sendo realizado o trabalho, do que pelo seu cargo
propriamente dito.
A medida que vamos identificando os diversos papéis do processo e vamos analisando se os mesmos estão, ou não, atreladosa cargos e funções, conseguimos enxergar a distribuição destes papéis ao longo da estrutura hierárquica da empresa,
obtendo assim, o seu modelo organizacional.
8/19/2019 6.4 Aula Transcrita
37/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
37
SLIDE 32
Aqui neste exemplo temos a empresa XYZ distribuída em uma matriz e uma filial. A sede possui uma estrutura completa de
centros de custo, enquanto que as filiais possuem somente os centros de custos necessários para a sua operação, tendo o
restante das suas necessidades atendidas pela sede. Cada centro de custo apresentado possui um conjunto de colaboradores
alocados, e estes colaboradores estão vinculados a papéis. Dessa forma, podemos definir, por exemplo, que uma atividade
será realizada pelo ator que tiver o papel de tesoureiro, que neste caso, só existe na sede da organização, ou que será feito
pelo gerente da informática, que neste caso denota um cargo gerencial dentro da empresa, ou ainda, o que será realizado
pelo gerente da produção da filial do Rio Grande do Sul, sendo que neste último caso foi necessário precisar de qual filial
seria o ator, visto que este papel existe em mais de uma filial.
8/19/2019 6.4 Aula Transcrita
38/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
38
SLIDE 33
O resultado da identificação da definição de um papel está na avaliação de quais colaboradores irão receber uma
determinada atividade humana, modelada no processo, em sua lista de trabalho, sendo estes atores responsáveis pela a sua
execução.
8/19/2019 6.4 Aula Transcrita
39/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
39
SLIDE 34
Vamos então falar sobre a modelagem das atividades que compõem um processo automatizado. Uma atividade representa a
execução de um passo lógico dentro de um processo. A atividade deve ter um objetivo no processo, cabendo ao analista
detalhar a forma como a atividade é executada para analisar a melhor forma de se utilizar a tecnologia a favor do processo. É
nessa análise que será feita a avaliação do quanto uma ou mais atividades humanas, por exemplo, poderão ser substituídas
por atividades automáticas. É muito comum, nesse momento, termos uma mudança na granularidade das atividades,
fazendo com que uma atividade do to be vire duas atividades no modelo to do, ou duas atividades no modelo to be se
tornem uma só atividade no modelo to do. Contudo, cabe lembrar que, apesar das possíveis mudanças, o analista de
sistemas nunca alterará o que é feito no processo, mas somente o como. Desta forma, teremos ao final desta etapa a
identificação de quais são as atividades humanas, automáticas, ou de sub-processos. Como cada um desses tipos de
atividade exigirá o levantamento de um conjunto de informações distintas, iremos ver maiores detalhes de cada um desses
tipos a seguir.
8/19/2019 6.4 Aula Transcrita
40/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
40
SLIDE 35
8/19/2019 6.4 Aula Transcrita
41/58
8/19/2019 6.4 Aula Transcrita
42/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
42
SLIDE 37
Já neste processo de liberação de crédito temos vários exemplos de atividades humanas. Na primeira, o gerente da conta faz
a inclusão da proposta de crédito aprovada dentro do sistema, após o cliente deve comprovar que atendeu os requisitos para
a liberação do pagamento da próxima parcela do contrato, através da entrega de algumas documentações. Em seguida, o
gerente da conta analisa essa documentação e, estando tudo certo, envia a mesma para o analista de crédito. No crédito é
feita uma análise técnica da documentação entregue e, estando tudo correto, o processo é encaminhado para uma vistoria
presencial por um técnico. Vejam que, neste exemplo, nenhuma dessas atividades pode ser automatizadas, pois elas exigem
a entrada manual de informações, a entrega de uma documentação comprobatória, ou a análise desses documentos.
8/19/2019 6.4 Aula Transcrita
43/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
43
SLIDE 38
8/19/2019 6.4 Aula Transcrita
44/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
44
SLIDE 39
8/19/2019 6.4 Aula Transcrita
45/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
45
SLIDE 40
8/19/2019 6.4 Aula Transcrita
46/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
46
SLIDE 41
8/19/2019 6.4 Aula Transcrita
47/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
47
SLIDE 42
Já as atividades automáticas são aquelas que são executadas por um sistema ou pelo próprio motor de processo. Vamos ver
a seguir alguns usos típicos de atividades automáticas.
A primeira aplicação é a execução de uma regra de negócio que se encontra presente na lógica de algum sistema. Por
exemplo, em um processo de concessão de benefícios de uma empresa que administra um plano de saúde, podemos ter no
sistema gerenciador do plano todas as regras necessárias para que seja avaliado, de acordo com as características do plano e
das normas regulatórias em vigência, se um determinado beneficio deve, ou não, ser concedido para um segurado. Ainda
nesse exemplo, temos mais abaixo a execução de uma segunda regra de negócio, que identifica se o cliente tem um perfil
cujo histórico justifique a oferta de aquisição de um plano mais sofisticado. Em muitos casos, a execução das regras de
negócio pode não estar diretamente em um sistema, mas armazenadas dentro de um motor de regra, neste caso, o usuário
de negócio acaba tendo maior autonomia para administrar essa regra.
8/19/2019 6.4 Aula Transcrita
48/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
48
Outro uso comum e difundido da automação de processos está no envio de informações para usuário, esta é uma
funcionalidade clássica que ajuda muito na sensação de pró-atividade do processo, a medida que ela tranquiliza os seus
atores de que quando o processo alcançar um determinado ponto ou estágio que for do seu interesse ele será avisado a
respeito. Com isso, o usuário pode se despreocupar em ficar acompanhando o processo a todo instante, pois ele terá a
certeza de que será avisado quando chegar o momento. No exemplo abaixo, uma pessoa da área de recebimentos é
informada pelo processo sobre a aprovação de um pedido de compras de modo que ele se prepare para receber o material.
Outro uso de atividades automáticas é para o roteamento do processo. Inúmeras são as situações em que um processo pode
seguir caminhos distintos. Seja devido às características da instância do processo, ou devido a exceções que ocorreram ao
longo da sua execução. Nesse sentido, o roteamento do processo pode ser feita com base em uma decisão de um usuário, ou
de uma regra de negócio que foi implementada em um sistema. A decisão humana acontece quando o usuário possui várias
opções para encerrar a sua atividade, e essas opções são avaliadas logo após a atividade ter sido encerrada através de um
gateway . No desenho abaixo, a avaliação da ordem de compra, tanto pelo gestor do centro de custo, como pelo gestor da
produção, ou do vice-presidente, são exemplos de roteamentos realizados a partir de uma decisão do usuário.
8/19/2019 6.4 Aula Transcrita
49/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
49
O segundo tipo ocorre a partir da execução de uma regra de negócio em um sistema, no exemplo a solicitação de compra
deve ser aprovada por papéis distintos de acordo com suas características. Se for uma solicitação gerada a partir de uma
necessidade da linha de produção, ela deve ser avaliada pelo gestor da produção. Se for uma solicitação originária de uma
ordem de investimento, ela deve ser analisada pelo vice-presidente. E se for uma solicitação gerada por um demanda
administrativa, ela não necessitará de uma aprovação adicional. Nesse exemplo, essa decisão não foi tomada por uma
pessoa, e sim por um sistema, que tinha entre as suas funcionalidades a capacidade de tomar essa decisão.
Outro tipo de uso para as atividades automáticas é a atualização de informações ou a integração com sistemas legados. Em
inúmeros momentos, ao longo de um processo, surge a necessidade que um determinado sistema seja atualizado, ou que os
dados que existem nele sejam inseridos em um segundo sistema. Essa necessidade torna-se cada vez mais comum devido ànatureza do processo, que é horizontal, o que faz com que diversos sistemas de áreas distintas sejam utilizados ao longo das
suas atividades.
Por exemplo, um processo típico de uma venda eletrônica podemos utilizar um sistema de controle de estoque para verificar
se existe mercadoria disponível e dar baixa nessa mercadoria; o sistema financeiro para emitir uma nota fiscal; o sistema de
logística para programar a entrega para o cliente; o sistema de crédito para validar se o cliente pode realizar aquela compra;
e um sistema pós venda para agendar um contato para medir a satisfação do cliente.
8/19/2019 6.4 Aula Transcrita
50/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
50
Em um processo dessa natureza, é muito comum que essas interações entre sistemas sejam feitas pelo próprio processo. No
exemplo abaixo, temos um processo de compra com financiamento, onde, após a aprovação do pedido de produção e
confirmação com o cliente, o pedido deve ser incluído no sistema de produção, e uma nota fiscal deve ser emitida no sistema
financeiro. Para que essas integrações sejam viáveis, contudo, é importante que o processo tenha acesso a todas as
informações necessárias para que seja possível a realização destas integrações com estes sistemas.
8/19/2019 6.4 Aula Transcrita
51/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
51
SLIDE 43
8/19/2019 6.4 Aula Transcrita
52/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
52
SLIDE 44
O terceiro tipo de atividade que podemos identificar no processo automatizado é o sub-processo. Um sub-processo
representa um conjunto de atividades que, juntas, possuem um propósito específico. Este conjunto de atividades é agrupado
em um desenho de processos, e este processo pode, então, ser utilizado em outros processos como sub-processo. Os sub-
processos são utilizados, principalmente, para a organização e a clareza do desenho do processo. A representação de um
conjunto de atividades com ou sem o sub-processo não altera em nada o funcionamento do processo. Por exemplo, se
tivermos um processo com vinte atividades seqüenciais, e se este mesmo processo for representado por cinco sub-processos
com quatro atividades cada, em ambos os modelos o processo se comportará da mesma forma, pois o sub-processo é
somente um elemento de organização.
Costumamos utilizar os sub-processos para aumentar a legibilidade dos processos, principalmente quando estes são muito
grandes. Via de regra, é mais fácil entendermos um processo que possua cinco sub-processos com dez atividades cada, sendoque cada sub-processo possui um significado para o negócio, do que entendermos um único processo com cinquenta
atividades desenhadas.
Utilizamos, também, o conceito de sub-processos, quando pensamos no reaproveitamento de atividades. Por exemplo,
quando uma determinada seqüência de atividades ocorre diversas vezes em um mesmo processo, ou ocorre, também, em
outros processos que estão sendo modelados, podemos colocar essa seqüência em um sub-processo e utilizarmos sempre
que desejarmos incluir essa seqüência.
8/19/2019 6.4 Aula Transcrita
53/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
53
Nesta figura vemos na parte superior a representação do sub-processo dentro de um processo, e vemos, na parte inferior, a
representação do sub-processo aberto dentro do próprio desenho do processo.
8/19/2019 6.4 Aula Transcrita
54/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
54
SLIDE 45
Assim, chegamos ao final desta aula e do nosso módulo 6. Vamos passar pelos principais conceitos-chave apresentados na
aula de hoje.
8/19/2019 6.4 Aula Transcrita
55/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
55
SLIDE 46
Então, como vimos hoje, análise de sistema convencional não atende de forma natural o ciclo da gestão por processos, à
medida que toda a cultura e todos os instrumentos utilizados por ela, não estão, via de regra, preparados para orientação
aos processos.
A modelagem orientada a processo vem então, justamente, com a ideia de trazer o uso do processo como elemento principal
para a definição do escopo de um sistema e dos requisitos que serão atendidos pelo projeto de implantação de TI. Nesse
sentido, o modelo do processo, pronto para automação, que chamamos de modelo to do, é diferente do modelo to be, uma
vez que ele altera a forma como o processo será executado.
Cabe ao analista, então, avaliar ao longo da modelagem a melhor aplicação possível da tecnologia ao processo, buscando
automatizar atividades de baixo valor agregado e tornando, assim, o processo mais eficiente e menos suscetível a erros.
Um modelo to do é composto por atividade humanas, atividades automáticas e sub-processos, e cada dessas atividades
possuem características distintas que devem ser analisadas separadamente.
8/19/2019 6.4 Aula Transcrita
56/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
56
SLIDE 47
Agradeço a presença de todos e aguardo vocês, então, no nosso fórum de discussão para conversarmos mais a respeito do
modelo to do e da automação do processo. Muito obrigado.
8/19/2019 6.4 Aula Transcrita
57/58
6.4 Modelagem de Sistemas Orientada a Processos © ELO Group 2011
57
ANOTAÇÕES DO ALUNO
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
8/19/2019 6.4 Aula Transcrita
58/58
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________