Upload
vinicius-ferreira
View
228
Download
0
Embed Size (px)
Citation preview
8/19/2019 6.2 Aula Transcrita
1/46
6.2 Componentes de umaplataforma de BPMS
8/19/2019 6.2 Aula Transcrita
2/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
2
RESUMO
Aula: 6.2 Componentes de uma plataforma de BPMS
Tutor: Eduardo Britto, MSc, PMP, OCEB, CDIA+
Número de slides: 42 Duração da Aula: 55 min
SLIDE 1
8/19/2019 6.2 Aula Transcrita
3/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
3
SLIDE 2
Boa noite. Sejam bem vindos à segunda aula do módulo 6 do nosso curso sobre tecnologia e BPM.
Nessa aula nós iremos aprofundar um pouco mais os conhecimentos a respeito dos componentes tecnológicos que
dão apoio ao ciclo da gestão por processos.
Iremos também falar um pouquinho sobre a arquitetura orientada a serviços ou SOA, e conhecer qual é a relação
que existe entre SOA e BPM.
Finalmente, iremos fechar a aula dando um overview dos conceitos-chaves que apresentamos hoje.
8/19/2019 6.2 Aula Transcrita
4/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
4
SLIDE 3
Então, vamos começar conhecendo os componentes tecnológicos e ferramentas que nos ajudam na gestão por processos.
8/19/2019 6.2 Aula Transcrita
5/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
5
SLIDE 4
Existem inúmeras ferramentas e tecnologias que apoiam o ciclo de gestão por processos, vamos separá-las em três grupos,
que serão vistos ao longo deste capítulo. O primeiro grupo é o de ferramentas de BPA, ou Business Process Analys, que
ajudam o usuário do negócio a mapear, desenvolver, modelar e documentar o seu processo de negócio. O segundo grupo
são os padrões utilizados na gestão por processos sendo que os dois mais difundidos são o padrão BPMN, para modelagem
de processos, e o padrão BPEL, para automação e integração de sistemas. O terceiro grupo é composto pelas ferramentas
que são utilizadas para automação e a melhoria continua dos processos onde podemos citar tecnologias como, BPMS, BRM,
BAM e SOA.
8/19/2019 6.2 Aula Transcrita
6/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
6
SLIDE 5
Vamos começar então pelos BPAs. Os BPAs normalmente são utilizados para apoiar o usuário de negócio nas etapas de
mapeamento e redesenho de processos. Dentro do BPA é possível representar toda a estrutura de processograma da
organização, começando pela cadeia de valor e descendo até os detalhes de cada processo, e chegando então nas suas
atividades operacionais. Além disso, os BPAs são importantes repositórios de processos que permitem que os processos
sejam organizados e armazenados dentro de um banco de dados, com controle de acesso e autenticação de usuário. Ao
definir um processo no BPA o analista pode definir e detalhar também os indicares que compõe e que irão medir esse
processo, bem como identificar claramente os pontos do processo onde esses indicadores serão alimentados. De acordo com
o produto que está sendo utilizado é possível, inclusive, conectar os indicares definidos no BPA na base de dados gerada por
uma solução de BPMS, permitindo assim, que seja atualizado dentro do BPA os dados reais do processo. Outros três pontos
importantes de soluções de BPA, que veremos agora em maiores detalhes, são os pontos de documentação, simulação e
publicação de processos.
8/19/2019 6.2 Aula Transcrita
7/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
7
SLIDE 6
Em termos de documentação, é possível, no BPA, que a organização identifique para cada tipo de elemento utilizado para
representar o processo, quais as informações e atributos que devem ser preenchidos para se documentar esse elemento. Em
um processo em BPMN, por exemplo, é possível definir que informações devem ser preenchidas quando o usuário estiver
documentando uma atividade humana. Além disso, por ser um repositório de processo, o BPA se torna o local onde são
armazenadas e consultadas, em termos organizacionais, todas as informações a respeito de um processo de negócio. Essa
consulta pode ser realizada tanto através do acesso a ferramenta, como, também, através da geração de documentação em
relatórios. Muitos BPAs possuem ambientes que permitem que se defina templetes de documentação que descrevem como
um documento de especificação de processos deve ser gerado. Assim, a qualquer momento, com esse template definido, é
possível com um clique de botão solicitar a geração de um documento de especificação funcional automaticamente.
8/19/2019 6.2 Aula Transcrita
8/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
8
SLIDE 7
Outro recurso importante dos BPAs é a sua capacidade de realizar a simulação de processos. Na simulação o usuário
consegue modelar o seu processo e entrar com informações que servirão de premissas para avaliar como o processo irá se
comportar na configuração em que ele foi modelado. Para realizar uma simulação, contudo, é necessário que o analista entre
com dados bastante detalhados sobre o processo, tais como o volume de instancias que se espera que esse processo seja
executado por dia, por hora ou minuto, a quantidade de recursos disponíveis para a execução de cada atividade, o tempo
dispendido por cada recurso para realizar uma determinada atividade e para cada gate incondicional a probabilidade do
processo seguir por um caminho A ou por um caminho B. A partir desses dados, é possível simular o comportamento do
processo, e avaliar se ele irá executar da forma esperada. Com recursos de simulação, conseguimos avaliar o comportamento
de um processo sem que ele tenha que ser colocado em produção, minimizando assim, os custos que a empresa teria se
realmente fosse utilizar aquele processo na prática.
8/19/2019 6.2 Aula Transcrita
9/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
9
SLIDE 8
Outra importante funcionalidade dos BPAs são os seus recursos de publicação. Através delas é possível realizarmos a
publicação dos processos de negócio para toda a organização através de padrões conhecidos como portais internos ou
páginas da web. Nesses portais é possível também criarmos mecanismos de controle de acesso de modo a definirmos quem
poderá consultar cada processo. No momento de redesenho dos processos a equipe de analistas responsáveis pelo
redesenho poderia utilizar esse recurso para publicar o processo e colher sugestões de melhorias com outros usuários da
empresa. Para isso, essas ferramentas possuem recursos de colaboração que permitem que os usuários, autorizados,
comentem o processo sem que este seja efetivamente alterado. Ao final dessa etapa de coleta de sugestões a equipe de
redesenho pode, então, analisar cada item e avaliar quais sugestões ou criticas irá colher.
8/19/2019 6.2 Aula Transcrita
10/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
10
SLIDE 9
De uma maneira geral, os BPAs são utilizados pelas áreas de negócios, nas etapas de mapeamento e redesenho de processos
e, sempre que possível, ele também pode ser utilizado pelo analista de sistemas nas etapas de modelagem para automação.
Via de regra, o envolvimento da área de TI na aquisição de um BPA costuma ser de médio a nulo, dependendo do quanto o
escritório de processos da empresa tem autonomia para escolher a melhor solução para si. Contudo, um grande problema
que costuma acontecer de forma muito frequente nas organizações é a área de negócios escolher uma solução de BPA que é
incompatível com a solução de automação de processos escolhida pela área de TI, gerando, em muitos casos, inúmeras
situações de retrabalho e de falta de compatibilidade. Um outro ponto importante é que o modelo desenhado no BPA não é
um modelo verificável na vida real. Como a gente costuma dizer, o papel aceita tudo, e o BPA também, ou seja, não é
possível se ter a garantia que o processo desenhado no BPA é realmente exequível visto que o processo é um mero
documento e que somente poderá ser validado e colocado em prática no momento da sua implantação.
8/19/2019 6.2 Aula Transcrita
11/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
11
SLIDE 10
São exemplos de ferramentas de BPA o ARIS Business Architect, Oracle BPA, Websphere Modeler e o Corel e Graphics. É
comum que algumas pessoas acharem que o Visio é uma ferramenta de BPA. O Visio é uma excelente ferramenta para a
representação de processos, mas não pode ser considerada como uma solução de BPA, pois não tem as inúmeras
funcionalidades esperadas por ele, tais como o conceito de repositório de processos, dissimulação ou digestão de
indicadores.
8/19/2019 6.2 Aula Transcrita
12/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
12
SLIDE 11
Entrando agora nos padrões vamos começar falando do BPMN, o Business Process Model and Notation. O BPMN é uma
notação gráfica de representação de processos de negócios. Ao ser elaborada, os seus autores buscaram atender as
seguintes premissas: construir uma notação de fácil compreensão que se baseasse nas melhores prática existentes até o
momento e que não exigisse grande esforço para o seu aprendizado. Buscaram também representar dentro da notação
todos os aspectos existentes nos processos de negócios organizacionais sejam esses processos internos, externos ou be to
be. E, por fim, eles buscarem desenvolver um modelo completo que tivesse um poder de expressão capaz de representar
todos os níveis de detalhes existentes ao longo do ciclo de gestão por processos. Dessa forma a mesma notação deveria
conseguir atender tanto às necessidades dos analistas de negócio que desejam representar os seus modelos as easy to be,
como as necessidades dos analistas de sistemas com seu modelo to do.
8/19/2019 6.2 Aula Transcrita
13/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
13
SLIDE 12
O BPMN hoje é amplamente utilizado em nível mundial em grande parte das organizações. Ele conseguiu se torna um
padrão, de fato, principalmente a partir do momento em que a OMG, em 2006, o adotou como seu padrão oficial para
modelagem de processos, ajudando muito na sua popularização. Atualmente, ele é adotado em grande parte das
ferramentas de BPM, sejam elas de negócios ou de implementação de processos. Dessa forma, a sua enorme aceitação tem
ajudado em muito, tanto a disseminação do conceito de processo de negócio, como também facilitado à leitura e
entendimento dos processos entre diferentes organizações.
8/19/2019 6.2 Aula Transcrita
14/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
14
SLIDE 13
Nesse slide vemos um exemplo de um processo desenhado em BPMN. Vejam que o padrão utiliza o conceito de piscinas para
representar o processo, e de raias para representar os atores do processo. Atores externos à organização são representados
por outras piscinas que aparecem paralelas à piscina do processo. Os eventos de início e de fim do processo são
representados por círculos, os pontos de decisão são representados por losangos e as atividades são representadas por
retângulo. Na parte superior direita de cada atividade existe um estereótipo, que identifica o tipo da atividade; atividades
humanas tem a figura de um busto, atividades automáticas tem a figura de uma engrenagem, e subprocessos tem um sinal
de mais no centro da atividade.
8/19/2019 6.2 Aula Transcrita
15/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
15
SLIDE 14
Um outro padrão que ganho muita notoriedade no lançamento das primeiras ferramentas de BPMS foi o padrão BPEL,
Business Process Execution Language. O BPEL é um padrão criado para permitir a implementação de processos de integração
de sistemas. Muito utilizado em processos de SOA, o BPEL se utiliza do conceito de serviços para realizar a orquestração de
troca de informações entre sistemas. Uma das suas principais características são os seus recursos de manipulação de dados e
de chamadas de serviços, com diversas funcionalidades que facilitam que dados recebidos de um sistema sejam preparados
para serem utilizados na chamada de um próximo sistema. Além disso, o BPEL tem um aspecto bastante técnico conforma
podemos ver na figura ao lado de difícil compreensão por usuários de negócio.
Por ter se originado para realizar a orquestração de serviços, ele possui algumas características bastante limitantes para o
seu uso em processos de negócio, tais como a impossibilidade de se representar no seu fluxo uma condição que faça com
que exista uma transição para uma atividade anterior. Além disso, o padrão não possui nenhum elemento que represente,
ativamente, a atividade humana, dificultando, assim, ainda mais o seu uso para processos de negócios que não sejam de
integração. Porém, mesmo não tendo sido criado para automação de processos de negócio, com características humanas, ele
acabou sendo adotado por inúmeras ferramentas nas suas primeiras versões, há cinco anos. Contudo, com o tempo, grande
parte dos fabricantes acabou percebendo as dificuldades de uso desse padrão para processos humanos, e foram adaptando
os seus produtos para que utilizassem a notação de BPMN para processos humanos, e a notação BPEL para processos de
integração.
8/19/2019 6.2 Aula Transcrita
16/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
16
SLIDE 15
Finalmente, nós temos os BPMS, que são uma suíte de software que englobam um vasto conjunto de ferramentas que dão
apoio a todo o ciclo de gestão por processos.
8/19/2019 6.2 Aula Transcrita
17/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
17
SLIDE 16
Via de regra, um BPMS é composto pelos seguintes elementos: no centro nós temos o motor do processo responsável pela
interpretação e execução do processo de negócio. Para representarmos o processo e sua posterior codificação, nós
utilizamos uma ferramenta de modelagem e desenvolvimento do processo. A partir de uma aplicação de lista de trabalho os
usuários podem interagir com as atividades humanas. Ao longo do processo, atividades automáticas podem ser invocadas,
gerando a integração do processo com sistemas internos e externos da organização. Para permitir a gestão de regras de
negócios, que são utilizadas ao longo do processo, são utilizadas soluções de BRM, ou Business Rules. E, finalmente, para
monitorarmos o andamento do processo e realizarmos o acompanhamento dos seus indicadores nós utilizamos soluções de
BAM. Vamos a seguir ver detalhadamente cada um desses elementos.
8/19/2019 6.2 Aula Transcrita
18/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
18
SLIDE 17
Um motor do processo é o elemento central do BPMS. Ele é quem dá vida ao processo, ele é o seu maestro. A sua principal
característica é a sua capacidade de interpretação, pois ele consegue seguir o processo conforme este foi desenhado e, para
cada tipo de atividade, ele consegue realizar a ação correspondente. Sempre que o motor encontra uma atividade humana,
ele busca identificar quem são os usuários que podem receber essa atividade; ele também monta as atividades que devem
ser enviadas para esse usuário; e encaminha essa atividade para os usuários habilitados. Nesse momento, o motor do
processo fica, então, em stand by, aguardando que o usuário informe que terminou a atividade, momento esse que,
novamente, ele vai ser então ativado e irá buscar a próxima atividade do processo. Já quando encontra uma atividade
automática o motor sabe como identificar o sistema que deve ser chamado e consegue, então, estabelecer uma
comunicação desse sistema com o processo de modo a solicitar a execução de uma rotina ou serviço e no retorno tratar a
resposta recebida. Já quando o processo encontra um gate, o motor sabe interpretar as condições existentes em cada
transição dirigindo, assim, o processo para a atividade correta. Além disso, o motor mantém todas as informações
pertinentes ao processo, registrando todo o seu histórico de execução que servirá mais tarde como uma valiosa base de
dados para a análise de melhoria contínua do processo.
8/19/2019 6.2 Aula Transcrita
19/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
19
SLIDE 18
A interface de interação do usuário com o processo ocorre através da lista de trabalho. A lista de trabalho funciona de forma
semelhante a uma caixa de e-mail , cada usuário possui a sua e para acessá-la, ele deve fazer um login com a sua
identificação. Todas as atividades humanas que são enviadas para um determinado usuário aparecem na sua lista de
trabalho, como podemos ver na parte superior dessa imagem. Ao clicar na atividade o usuário consulta o conteúdo da
atividade, onde deve estar todas as informações necessárias para a sua execução. Para terminar a atividade, o usuário irá
respondê-la, informando de que forma a atividade foi finalizada.
8/19/2019 6.2 Aula Transcrita
20/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
20
SLIDE 19
Outro componente do BPMS, são os motores de regras de negócios, também conhecidos como business rules. O BRM é uma
tecnologia que permite que o próprio usuário de negócios defina suas regras de forma declarativa, numa espécie de
algoritmo, em português, estruturado. Cada regra definida fica armazenada em um repositório de regras, podendo ser
consultada e alterada sempre que a área de negócios achar necessário. A grande vantagem dos motores de regra está,
justamente, na liberdade que eles dão para o usuário de negócios definir e dar manutenção em suas próprias regras. Essa
situação, normalmente, é impossível de acontecer quando essas regras estão codificadas dentro de telas de sistemas,
tornando o acesso e o processo de alteração dessas regras muito difícil. São exemplos de regra de negócios, regras que, por
exemplo, definam como realizar as alçadas de uma aprovação, como fazer o cálculo de preços, de impostos ou de um
desconto ao consumidor, ou que fazem a avaliação de escores de riscos ou de definição de prioridades.
8/19/2019 6.2 Aula Transcrita
21/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
21
SLIDE 20
Nesse slide temos o exemplo de uma arquitetura utilizada por um motor de regra. O repositório de regras armazena todas as
regras criadas, e fazem o controle de acesso as mesmas. Através da ferramenta de autoria, os analistas e gestores do negócio
podem criar novas regras e dar manutenção às regras existentes. As regras são definidas em português estruturado, e na sua
criação são definidas quais os valores de entrada e de saída são esperados para a sua execução. No exemplo, para esta regra
ser executada, o sistema terá que enviar as informações de valor e de tipo de mídia e a regra dará, como retorno, de que
forma a confirmação será exigida. As regras armazenadas no repositório são, então, disponibilizadas para os sistemas e para
os processos através do mecanismo de serviços, dessa forma, sempre que um processo precisar executar determinada regra,
ele irá chamar um serviço disponibilizado pelo motor de regras, passando as informações necessárias e recebendo o retorno
esperado.
8/19/2019 6.2 Aula Transcrita
22/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
22
SLIDE 21
Dessa forma o uso de motores de regra traz para a organização inúmeros benefícios e entre eles podemos citar uma maior
flexibilidade para a área de negócio para definir as suas regras, traz também uma grande independência entre as regras de
negócio e a sua aplicação em sistemas e processos, tendo em vista que agora elas são definidas externamente a esses
sistemas. Os motores de regra também trazem uma maior transparência sobre as regras que existem atualmente, uma vez
que essas regras são armazenadas em um repositório, não ficam mais dentro de um código, de um sistema legado. Outro
ponto importante é a redução no esforço na manutenção de sistemas, tendo em vista que muitas modificações em regras de
negócio poderão ser feitas diretamente no BRM, sem exigir uma nova codificação no sistema. E, como consequência para
tudo isso, temos uma maior agilidade para a adaptação dos sistemas as suas novas regras de negócio, ganhando, então,
assim, em toda a organização em termos de custo e esforço.
8/19/2019 6.2 Aula Transcrita
23/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
23
SLIDE 22
Uma outra tecnologia de grande importância na gestão por processos é o BAM, Business Activity Monitoring, ou
monitoramento de atividade de negócios. O BAM é uma tecnologia que permite o acompanhamento de indicadores de
negócio em tempo real, mostrando o que está acontecendo com os processos nesse exato momento. Ao contrário do BI, que
serve para a análise do passado, o BAM é uma ferramenta de tomada de decisão imediata, pois permite que o usuário de
negócio acompanhe a sua operação e tome ações que alterem os cenários em andamento.
8/19/2019 6.2 Aula Transcrita
24/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
24
SLIDE 23
Os indicadores, no BAM, são acompanhados pelos usuários, através do que chamamos de dashboards, que são painéis
montados de acordo com as necessidades do negócio, onde são mostrados os diversos indicadores que precisam ser
monitorados. Para cada indicador é possível modelarmos regras que definem que na ocorrência de uma determinada
situação como, por exemplo, um indicador que apresente um comportamento fora do previsto, sejam enviados alertas para
os usuários responsáveis. Além disso, na ocorrência dessas situações, nós também podemos definir que sejam executadas as
ações corretivas automáticas como, por exemplo, o disparo de um novo processo ou uma chamada de uma rotina de um
sistema legado.
8/19/2019 6.2 Aula Transcrita
25/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
25
SLIDE 24
Nesse slide vemos, então, o exemplo de implementação de um dashboard . Vejam que esse dashboard está acompanhando
diversos indicadores que são importantes para o negócio, tais como o desempenho de SLA, e o controle de capacidade de um
posto de armazenamento. Caso um determinado SLA não seja comprido, uma alerta pode ser disparado, ou alguma ação
pode ser tomada automaticamente. No canto inferior esquerdo, temos uma caixa de entrada que mostra alguns alertas que
foram gerados dentro da própria ferramenta.
8/19/2019 6.2 Aula Transcrita
26/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
26
SLIDE 25
Vimos até aqui algumas das principais tecnologias que apóiam as iniciativas de gestão por processo. Devido a sua
importância e complexidade, deixamos para ver por último, em um capítulo a parte, um dos principais modelos utilizados por
soluções de BPM, que é o SOA ou Arquitetura Orientada a Serviços, que visa facilitar, enormemente, a capacidade do
processo de se integrar com sistemas externos ou internos à organização.
8/19/2019 6.2 Aula Transcrita
27/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
27
SLIDE 26
Então, vamos começar falando sobre uma das realidades mais comuns que existem nas áreas de TI das organizações. Como
comentamos anteriormente, atualmente, a maior parte das organizações conta com uma quantidade muito grande de
sistemas para dar apoio ao andamento do seu negócio. Via de regra, esses sistemas surgem com necessidades diferentes,
muitas vezes verticais, de determinadas áreas de negócio e, por isso, acabam atendendo de uma forma muito particular
somente uma determinada área. É muito comum vermos sistemas que são utilizados somente por um departamento ou
centro de custos da empresa, pois esses sistemas foram concebidos ou adquiridos para atender aquele departamento.
Porém, chega uma hora que esses sistemas têm que se falar entre si, de modo a aumentar a produtividade da empresa,
neste momento começam a surgir as integrações, que permitem a interação entre diferentes sistemas. Contudo, via de
regra, essas integrações vão sendo desenvolvidas sobre demanda à medida que elas se fazem necessárias, de forma
desorganizada, que viabiliza a criação de um cenário onde tudo é caótico.
Neste cenário, cada integração é desenvolvida de forma distinta, com tecnologias diferentes. Além disso, é muito comum
uma mesma integração acabar sendo redesenvolvida mais de uma vez, ou seja, toda vez que eu preciso integrar um sistema
A com um outro sistema, eu acabo redesenvolvendo essa integração. Além disso, quando um sistema A precisa se integrar
com um sistema B é muito comum ela trazer para dentro do sistema B detalhes técnicos da estrutura do sistema A. Isso faz
com que sempre que alguma coisa da estrutura de um sistema for alterado seja preciso repetir essa alteração em todos os
outros sistemas que fazem uma integração com ele, isso é o que chamamos de um alto nível de acoplamento, ou seja,
quando o sistema conhece detalhes técnicos de outro sistema para viabilizar uma integração com ele. Para piorar a situação,
não raro, as empresas não tem uma estrutura organizada para documentar quais são as integrações que existem e como elas
funcionam. É muito comum vermos áreas de TI, onde às integrações entre sistemas são completamente desconhecidas, ou
quando elas são conhecidas, a documentação é muito pobre e quase ninguém mais sabe como elas funcionam. Todo essecenário acaba por gerar o que chamamos de um “espaguete” de integrações, onde todo mundo se integra com todo mundo
de uma forma não organizada e documentada, conforme mostra a figura do slide.
8/19/2019 6.2 Aula Transcrita
28/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
28
SLIDE 27
Como resultado, as áreas de TI acabam passando por uma série de dificuldades, resultantes dessa situação. Algumas das
maiores dificuldades geradas são, primeiro, a dificuldade na modificação de um sistema devido ao forte acoplamento com
outros sistemas. Se um sistema, por exemplo, se integra com outros cinco, possivelmente a mudança na estrutura interna
desse sistema exigirá, também, a mudança na codificação dos outros cinco sistemas que se integram a ele. A mesma coisa
ocorre com as regras de negócio do sistema, se uma regra de negócio teve que ser reaplicada em vários outros sistemas,
para viabilizar a integração, quando essa regra de negócio mudar, a mudança terá que ser feita em todos esses cinco
sistemas. Esse forte acoplamento acaba trazendo um grande temor nas áreas de TI no momento em que tem que ser feita
uma substituição ou mudança no sistema. É muito comum, no momento em que uma área de TI precisa mudar algo no
sistema, ela não saber, com convicção, se todas as integrações com aquele sistema realmente estão documentadas. Dessa
forma, a melhoria de sistema acaba sendo retardada ou gerando um esforço muito maior do que o desejado. Em um cenário
mais grave, muitas vezes a substituição integral de um sistema antigo por um mais novo torna-se inviável, dada à
complexidade de adaptar essa mudança, e todos os outros sistemas legados da empresa, ou seja, como resultado nós temos
um cenário de alto custo, longos prazos e enormes riscos operacionais.
8/19/2019 6.2 Aula Transcrita
29/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
29
SLIDE 28
Para reforçar esse cenário temos um estudo do Gartner que traz que 35% do orçamento anual gasto com manutenção de
sistemas é dispendido na manutenção de integrações entre sistemas. E, aproximadamente, 30% dos investimentos com
implantação de ERPs se originam da necessidade de se integrar essas ERPs com sistemas legados da empresa. Ou seja, por
um lado a integração entre sistemas é hoje um grande complicador quando pensamos em agilidade e eficiência na mudança
dos nossos sistemas porém, essa mesma integração é um dos fatores mais importantes quando pensamos na automação de
processos, pois devido às características horizontais do negócio, normalmente um processo acaba integrando e passando por
diferentes sistemas da empresa.
8/19/2019 6.2 Aula Transcrita
30/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
30
SLIDE 29
Para ajudar a organizar toda essa situação surgiu o conceito de serviço. Um serviço nada mais é do que a exposição de uma
funcionalidade de um sistema para o mundo exterior. O serviço trabalha sempre em nível de negócio, ou seja, essa
funcionalidade que é disponibilizada para outros sistemas deve ser entendida pela área de negócio. Por exemplo, um sistema
de gestão orçamentária poderia disponibilizar um serviço para a consulta de um valor disponível em orçamento de um
determinado centro de custo, e poderia, também, disponibilizar um segundo serviço que realizasse a reserva orçamentária
de uma rubrica, para uma despesa que foi aprovada, mas ainda não foi paga. De forma similar, um sistema financeiro poderia
disponibilizar um serviço que permitisse a emissão e o cadastro de uma nota fiscal nesse sistema, e um segundo serviço que
trouxesse o quanto a empresa faturou em um determinado mês. Vejam que, nesses quatro exemplos, os serviços
apresentados têm características claramente de negócios.
8/19/2019 6.2 Aula Transcrita
31/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
31
SLIDE 30
Entre as principais características de um serviço podemos trazer que um serviço possui um conjunto de entradas e saídas
bem definidas, assim como premissas, restrições e lógicas de negócio. Um serviço de consulta orçamentaria, por exemplo,
possivelmente tem como entrada a rubrica que se deseja consultar, o centro de custo da rubrica e o mês de competência do
orçamento, e tenha como saída o valor total do orçamento previsto naquele mês, o quanto desse orçamento já foi reservado
e o quanto desse orçamento já foi gasto.
Outro ponto chave do conceito de serviços está no baixo acoplamento. Quando um sistema disponibiliza uma funcionalidade
sua através de um serviço, está ocultando do consumidor, todo e qualquer detalhe sobre a forma como o serviço é
implementado. Toda a estrutura interna e lógica utilizada para se processar as informações enviadas pelo serviço devem ser
transparentes para o consumidor, que irá sempre chamar o serviço com informações em níveis de negócio, e irá sempre
receber o retorno também com informações em níveis de negócio. Para o processo de viagens, por exemplo, é
completamente transparente a forma como o sistema orçamentário busca as informações de orçamento da rubrica de
viagens de um determinado centro de custo. Toda essa lógica está encapsulada dentro do serviço, não é visível para quem
está fora dele. Dessa forma, os sistemas que se integram através do uso de serviços possuem baixo acoplamento, pois é pré-
requisito que as solicitações e retornos com esse serviço, ocorram sempre em nível de negócio, independente da forma
como o sistema implementa aquela funcionalidade. Assim, mudanças internas nos sistemas que disponibilizam um serviço,
não devem e não podem impactar no uso desse serviço por outros sistemas. Finalmente, um serviço é algo reutilizável, ou
seja, um mesmo serviço disponibilizado por um sistema A pode ser utilizado por um ou mais outros sistemas distintos.
8/19/2019 6.2 Aula Transcrita
32/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
32
SLIDE 31
Aqui nós vemos um desenho que mostra a estrutura de uma chamada de serviço. O consumidor é o ente externo que precisa
utilizar esse serviço, como por exemplo, o processo de viagens que precisa consultar o orçamento disponível. O provedor é o
sistema que está disponibilizando o serviço para outros sistemas, como por exemplo, um sistema orçamentário que
disponibiliza um serviço de consulta ao orçamento.
A interface é o ponto de ligação entre o provedor e o consumidor, ou seja, é a forma como o serviço será chamado, qual a
sua identificação e o detalhamento das informações de entrada e saída. Por fim, a implementação é a forma como o sistema
provedor se organiza internamente. É justamente a implementação que é só vista pelo provedor, ou seja, o consumidor
desconhece completamente como funciona a implementação do provedor, ele conhece somente a interface do serviço.
8/19/2019 6.2 Aula Transcrita
33/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
33
SLIDE 32
Como exemplo, temos abaixo dois serviços disponibilizados por um sistema de RH. No primeiro, um serviço de registro de
ausências, é utilizado sempre que um sistema precisa cadastrar uma ausência futura para um colaborador, nesse caso, temos
um serviço de inclusão de dados que é disponibilizado por um sistema de RH para qualquer outro sistema, ou processo, que
tenha essa demanda.
No caso, essa necessidade já foi identificada no processo de viagens, quando o colaborador não for bater o ponto, por um
determinado período, por estar viajando pela empresa. E também foi identificado no processo de licença médica, quando o
colaborador tiver que se ausentar do trabalho por problemas de saúde. Um segundo serviço no nosso exemplo também é
disponibilizado pelo sistema de RH, que é o serviço de consulta salários. Nesse caso, o sistema de folha de pagamento, que é
externo ao sistema de RH, chama esse serviço mensalmente sempre que precisa rodar o cálculo da folha.
8/19/2019 6.2 Aula Transcrita
34/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
34
SLIDE 33
A partir dos conceitos de serviços surgiu o conceito de SOA, Service Oriented Architecture, ou Arquitetura Orientada a
Serviços. Existem inúmeras definições de SOA, mas, para nós, a que traz de forma mais concreta os seus conceitos é essa
apresentada abaixo: SOA é uma filosofia de TI que visa criar e disponibilizar soluções modulares e fracamente acopladas,
baseadas no conceito de serviços. Por que dizemos que SOA é uma filosofia de TI? Porque ela é uma forma de pensar na
integração dos sistemas, de organizar essas integrações. E que forma é essa? É justamente através do uso de serviços. Por
estarmos usando serviços, estamos, necessariamente, dizendo que as soluções são modulares, por exemplo, somente no
sistema orçamentário é onde teremos um serviço de consulta de orçamento. Estamos também dizendo que elas são
fracamente acopladas, pois um dos conceitos do uso de serviços é que o consumidor não deve conhecer os detalhes de
implementação do provedor. Então, conforme podemos ver na figura abaixo, uma arquitetura SOA tem um conjunto de
sistemas provedores que disponibilizam funcionalidades através da publicação dos seus serviços numa camada de serviços,
que podem ser chamadas por consumidores. É interessante notar que em um determinado sistema ou processo, pode ser,
por algumas funcionalidades, provedor e, para outras funcionalidades, consumidor.
8/19/2019 6.2 Aula Transcrita
35/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
35
SLIDE 34
SOA não é uma tecnologia, mas sim, uma forma de organizar a integração entre os sistemas. Muito menos é um software.
Existem inúmeras soluções no mercado que facilitam enormemente a implantação de uma arquitetura orientada a serviços,
mas a sua aquisição não é obrigatória para que tenhamos uma arquitetura SOA. Dessa forma, SOA não é algo que possa ser
comprado, ela é a forma como pensamos, organização, da integração entre os nossos sistemas. E, finalmente, SOA não é web
services, web services são uma forma de publicar um serviço na web, e eles são bastante utilizados para implantação de
soluções SOA, mas SOA é muito mais amplo do que isso.
8/19/2019 6.2 Aula Transcrita
36/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
36
SLIDE 35
A implementação de uma arquitetura orientada a serviços tem o objetivo de solucionar uma série de problemas existentes
nas formas convencionais de se implantar a integração entre sistemas. Com o uso de serviços a integração entre sistemas
passa a ter um baixo acoplamento, ou seja, um sistema não conhece detalhes do funcionamento interno do outro, de modo
que, mudança do funcionamento interno de um sistema não devem alterar em nada a implementação de outros sistemas
que se integram a ele. Além disso, uma vez disponibilizado um serviço, esse serviço poderá ser reutilizado inúmeras vezes
pela mesma ou por diferentes aplicações. O serviço de registro de ausências, por exemplo, uma vez disponibilizado poderia
ser utilizado tanto pelo processo de viagens, como pelo processo de licença médica, ou pelo processo de aprovação de férias,
ou pelo processo de aprovação de licença maternidade, sem que nada mais precise ser feito dentro do sistema de RH. Além
disso, como o conceito de serviços está a nível de negócio, nada impede que posteriormente um sistema inteiro seja alterado
sem que haja qualquer tipo de impacto nos sistemas que se integram com ele. Para isso, contudo, é preciso garantir que o
novo sistema conseguirá implementar os mesmos serviços do sistema anterior, com exatamente a mesma assinatura e
comportamento esperado. Dessa forma, ganha-se muito em agilidade e em redução de custos.
8/19/2019 6.2 Aula Transcrita
37/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
37
SLIDE 36
Na implantação de uma arquitetura orientada a serviços, um dos fatores cruciais de sucesso, está na escolha de serviços
adequados, que traga uma ótima relação custo/benefício. A escolha de serviços que tenham, por exemplo, baixa
probabilidade de reuso, podem não justificar o esforço de transformar uma integração, que já está funcionando, em um
serviço. Dessa forma, existe uma série de fatores que devem ser analisados sempre que identificarmos que uma integração
poderia ser transformada em um serviço. Esses fatores não são mutualmente exclusivos, pelo contrário, eles formam uma
pontuação onde quanto mais uma determinada integração se encaixar nesses critérios, maior será o ganho de transformá-la
em um serviço. Vamos, então analisar, cada um deles:
O primeiro critério analisa o quanto uma determinada funcionalidade está implementada, de forma redundante, em
diferentes sistemas da organização. Uma funcionalidade que existe em diversos sistemas é sempre de difícil manutenção,
pois sempre que precisarmos alterar alguma coisa na sua regra de negócio teremos que fazer essa mudança em diferentes
sistemas. Além disso, em quanto mais locais for preciso alterar, maior será a probabilidade de gerarmos erros na codificação.
Finalmente, uma das expectativas e estratégia de implantação de SOA é justamente que tenhamos soluções modulares,
onde, sempre que possível, uma determinada funcionalidade esteja sendo disponibilizada em um único sistema. Dessa
forma, quanto mais sistemas uma funcionalidade estiver implementada, mais cresce o interesse em transformar essa
funcionalidade em um serviço.
Outro ponto importante de avaliação está na quantidade de sistemas que tenha essa integração implementada. Quanto mais
sistemas utilizarem uma determinada integração, maior será a sua reutilização, dessa forma, ao transformarmos essa
integração em um serviço, estaremos reduzindo, consideravelmente, a quantidade de código redundante, visto que todas
essas integrações serão transformadas em chamadas para um único serviço. Como consequência, maior também será a
economia no momento em que uma mudança nessa regra de negócio for necessária, visto que essa mudança precisará ser
feita em um só local, e não em cada um dos sistemas.
8/19/2019 6.2 Aula Transcrita
38/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
38
O volume de alterações esperadas em uma determinada funcionalidade também é um ponto importante quando avaliamos a
atratividade de transformar uma integração em um serviço. Existem funcionalidades que, pela natureza do seu negócio,
estão em constante alteração. Funcionalidades que mudam frequentemente, mesmo que estejam integradas com poucos
sistemas, exigirão retrabalho constantes nesses sistemas, cada vez que for necessária uma alteração. Fazendo uma
comparação com o critério anterior, digamos que uma funcionalidade esteja integrada com cinco sistemas e costuma exigir
duas alterações por ano, dessa forma, ao longo de um ano, teremos duas alterações em cinco sistemas, ou seja, a
necessidade de alterar dez pontos de integração. Num outro cenário, digamos que uma segunda funcionalidade estejaintegrada a dois sistemas somente, mas costuma sofrer, pelo menos, uma alteração por mês. Neste caso teremos doze
alterações em dois sistemas ao longo de um ano, ou seja, a necessidade de alterarmos vinte e quatro pontos de integração.
Vejam que, nesse caso, a frequência das alterações fez com que a transformação dessa funcionalidade em um serviço fosse
mais vantajosa do que no primeiro caso.
No mesmo sentido, um outro fator importante está na agilidade que será cobrada para que ocorra uma alteração e uma
integração. Se a alteração na funcionalidade, ou regra de negócio, exigir uma velocidade muito rápida de execução, ter essa
integração já exposta como serviço, tenderá a fazer com que a mudança na sua estrutura exija menos tempo para ser
implementada. E mesmo que essa funcionalidade, hoje, tenha poucos pontos de integração com outros sistemas, é
importante que se faça uma projeção de qual a tendência para as próximas semanas ou meses. Talvez uma integração que é
hoje pouco acessada venha a ser muito requisitada em pouco tempo, de modo que a sua transformação em serviço trará
ganho de curto ou médio prazo quando essas novas implementações forem necessárias.
E, finalmente, temos que avaliar a complexidade de transformar uma integração em um serviço. Aqui, a avaliação é inversa a
que fizemos até o momento. Existem casos em que a integração tem um nível de complexidade muito elevado, são críticas
para a organização e encontram-se, atualmente, funcionando bem, sem nenhum problema. Nestes casos é importante
avaliarmos os riscos de este processo de transformação da integração em serviço trazer instabilidade e introduzir novos erros
e então compararmos este risco com todos os possíveis ganhos que apresentamos nos itens anteriores, de modo então, a
realizarmos uma avaliação adequada de custos versus riscos versus benefícios.
8/19/2019 6.2 Aula Transcrita
39/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
39
SLIDE 37
Dado esse cenário qual o relacionamento existente entre BPM e SOA? Tanto o BPM quanto o SOA são modelos que surgiram
de forma independente com objetivos distintos. Por um lado, o BPM surgiu com a ideia de desenvolver a gestão por
processos apoiado por soluções de tecnologia. Já a SOA, surgiu para organizar a forma como são pensadas as integrações
entre os sistemas.
8/19/2019 6.2 Aula Transcrita
40/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
40
SLIDE 38
Entre os dois modelos existe uma relação muito próxima de interação. Por um lado, os processos são consumidores natos de
serviços, pois sempre que um processo precisa realizar uma operação ou consulta em um sistema ele precisará que esse
sistema disponibilize uma funcionalidade para que ele possa chamá-la. Nesse sentido, a arquitetura orientada a serviços vem
justamente com a ideia de ajudar os processos, a viabilizar a implementação dessas integrações.
8/19/2019 6.2 Aula Transcrita
41/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
41
SLIDE 39
Dessa forma existe um circulo virtuoso entre BPM e SOA. Por um lado, a modelagem e análise de processos é uma forma
muito natural de se identificar a necessidade de serviços. Por outro lado, para que a arquitetura SOA possa, realmente, trazer
retorno para a organização é importante que sejam identificados bons candidatos a serviços, que tenham uma alta
probabilidade de serem reutilizados. E nesse sentido, a modelagem de processos é justamente uma ótima forma de
identificarmos bons serviços, com alto nível de reutilização. E, uma vez que os serviços são identificados e construídos,
justamente a arquitetura orientada a serviços, viabiliza que, quando um segundo processo, ou uma nova aplicação precisem
utilizar novamente esse serviço, nenhum esforço adicional seja mais necessário, porque o serviço já foi construído,
disponibilizado e encontra-se pronto para reuso.
8/19/2019 6.2 Aula Transcrita
42/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
42
SLIDE 40
Chegamos ao final dessa aula, antes de terminar, vamos, então, repassar alguns dos conceitos apresentados.
8/19/2019 6.2 Aula Transcrita
43/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
43
SLIDE 41
Ao longo da aula de hoje vimos inúmeras iniciativas de TI que buscam viabilizar e implementar a gestão por processos. Temos
padrões como o BPEL e BPMN, que busca uniformizar alguns conceitos. Temos inúmeras tecnologias como o BPA, BPMS,
BRM e BAM, que facilitam o ciclo de gestão por processos. E temos, então, a Arquitetura Orientada a Serviços como uma
importante parceira para a implementação de processos com alto nível de automatização e integração.
8/19/2019 6.2 Aula Transcrita
44/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
44
SLIDE 42
Agradecemos a todos por ter nos acompanhado até aqui, espero vocês no nosso fórum de discussão. Até a próxima aula.
8/19/2019 6.2 Aula Transcrita
45/46
6.1 Componentes de uma plataforma de BPMS © ELO Group 2011
45
ANOTAÇÕES DO ALUNO
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
8/19/2019 6.2 Aula Transcrita
46/46
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________ ________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________
________________________________________________________