6.4 Aula Transcrita

8/19/2019 6.4 Aula Transcrita

1/58

6.4 Modelagem de SistemasOrientada a Processos


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


3/58


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.


4/58


4

SLIDE 3

Vamos, então, começar falando sobre a modelagem de sistemas orientada a processos.


5/58


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.


6/58


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


7/58


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/58


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.


9/58


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.


10/58


10

SLIDE 8


11/58


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.


12/58


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


13/58


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.


14/58


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.


15/58


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.


16/58


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.


17/58


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.


18/58


18

SLIDE 14


19/58


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.


20/58


20

SLIDE 16


21/58


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.


22/58


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.


23/58


23

SLIDE 19


24/58


24

SLIDE 20


25/58


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.


26/58


26

SLIDE 22

Bom, vamos então agora falar sobre como fazemos a modelagem para automação, iniciando com alguns conceitos.


27/58


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.


28/58


28

SLIDE 24


29/58


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


30/58


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.


31/58


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?


32/58


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.


33/58


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.


34/58


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.


35/58


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.


36/58


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.


37/58


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.


38/58


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.


39/58


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.


40/58


40

SLIDE 35


41/58


42/58


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.


43/58


43

SLIDE 38


44/58


44

SLIDE 39


45/58


45

SLIDE 40


46/58


46

SLIDE 41


47/58


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.


48/58


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.


49/58


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.


50/58


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.


51/58


51

SLIDE 43


52/58


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.


53/58


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.


54/58


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.


55/58


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.


56/58


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.


57/58


57

ANOTAÇÕES DO ALUNO

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________


58/58

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________ ________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

________________________________________________________

6.4 Aula Transcrita

Documents

Transcript of 6.4 Aula Transcrita