SlideShare a Scribd company logo
1 of 13
Download to read offline
Camunda BPM
em comparação com alternativas
Maio de 2015 – camunda.com
Índice
Índice
Comparações com alternativas���������������������������������������������������������������������� 2
Introdução: Vantagens da automação����������������������������������������������������������� 2
Automação de processos desenvolvida internamente�������������������������������� 3
Implementada dentro de uma aplicação pronta������������������������������������������ 5
Conjuntos BPM tradicionais���������������������������������������������������������������������������� 7
Camunda BPM�������������������������������������������������������������������������������������������������� 9
2
Comparações com alternativas
Comparações com alternativas
Introdução: Vantagens da automação
A automação de processos é uma forma inteligente de organizar tare-
fas de negócios em um processo. Existem razões óbvias para empresas
adotarem esse método:
●● Custos mais baixos – com automação, menos tarefas precisam ser
tratadas manualmente.
●● Processos mais rápidos – com a eliminação de tempo ocioso que ine-
vitavelmente acontece com processamento manual.
●● Menos erros de processo – outra vantagem de reduzir as tarefas ma-
nuais em um processo é que você terá menos erros.
Para um negócio em expansão, processos de negócio desorganizados ou
não documentados muitas vezes são um obstáculo para a escalabilida-
de. Como consequência, a capacidade de crescimento da empresa fica
prejudicada.
Sem automação
Desenvolvidas
internamente
Aplicações
prontas
Conjuntos BPM
tradicionais
Camunda BPM
Menor custo de
processo
Execuções mais
rápidas de processos
Menos erros de
processo
Real transparência do
processo
Possivelmente Possivelmente
Maior agilidade do
processo
Possivelmente
Menor esforço de
programação
Processos feitos sob
medida
Integração na TI
existente
Sem necessidade de
desenvolvedores espe-
cíficos do fornecedor
Sem ficar preso a um
fornecedor
Processos ponta a
ponta
Possivelmente
3
Automação de processos desenvolvida internamente
Usando nossa experiência direta com projetos de clientes, bem como
trabalhando com questões levantadas pelos próprios clientes, compila-
mos uma crítica detalhada das opções disponíveis em termos de auto-
mação de processos.
Para dar algum contexto ao documento, é bom ter em mente que es-
tamos fazendo nossas avaliações com base em empresas que realizam
desenvolvimento de software e com disponibilidade de desenvolvedores
apropriados.
Automação de processos desenvolvida
internamente
Exemplo
Muitas vezes uma empresa reconhece que alguns de seus processos
manuais seriam melhores se fossem automatizados. Assim, alguém na
empresa pode decidir passar algum tempo escrevendo um programa
simples que automatize um processo comum. Os benefícios de automa-
tizar processos manuais podem se tornar aparentes bem depressa. O
programa simples pode ser expandido para incluir mais processamento.
A conclusão lógica disso é um programa que funciona como uma caixa
preta, na qual ele inicia, depois algo acontece e, em algum ponto, o pro-
cesso se conclui ou falha.
Infelizmente, há grandes desvantagens nesse método.
Desvantagens
Sem transparência no processo
A lógica do processo é expressa diretamente no código fonte, o qual só é
compreensível ou conhecido pelos programadores respectivos. Também
não é incomum que se acrescente mais código sem atualização na do-
cumentação. Os processos são muitas vezes modelados em documento
de requisitos ou escritos num estágio posterior. No entanto, nunca se
pode saber com certeza se essas representações criadas manualmente
correspondem efetivamente à realidade.
Isso se aplica tanto à questão fundamental de como os processos são
executados quanto à questão de como um processo em particular
(instância de processo) foi efetivamente executado em casos individuais.
Isso pode ser um grande problema para setores que precisam obede-
cer a uma regulamentação rígida. O cumprimento dessas normas nem
sempre pode ser garantido.
Sem agilidade no processo
Tanto a implementação técnica inicial dos processos como a adaptação
dos processos já implementados exigem comunicação intensa. Qual-
quer implementação técnica exige uma complexa coordenação entre os
especialistas da matéria bem como profissionais de TI, estando sujeita a
4
Automação de processos desenvolvida internamente
erros e demandando tempo. Muitas vezes, os processos desejados são
descritos pelo lado negocial em notação relativamente não vinculante,
que o lado da TI terá que entender primeiro para conseguir produzir
resultados significativos. Esses resultados são muitas vezes prejudicados
por atrasos e erros em vários estágios em razão desse processo impreci-
so de comunicação.
Grande esforço de programação
O desafio de automatizar processos de negócio é muitas vezes subes-
timado. À primeira vista, parece ser tecnicamente simples programar
uma sequência de atividades ao mesmo tempo em que se levam em
consideração estruturas rudimentares de controle (se / então, etc.). No
entanto, os desafios surgem com frequência quando se chega a estados
de espera durante a execução.
Por exemplo: Recebemos um pedido que precisa ser examinado por um
atendente. Depois do exame, o item é enviado. Se o exame ultrapassar
um determinado limite de tempo, um lembrete deve ser acionado e, se
isso não for bem sucedido, será necessária uma realocação para ou-
tro atendente. O estado de espera descrito neste exemplo (o processo
aguarda a conclusão da tarefa), em combinação com o prazo apertado
necessário para acionamento de dois níveis, é relativamente desafiador
para programar. O esforço aumenta exponencialmente com a complexi-
dade do processo: em processos reais ponta a ponta, muitas vezes exis-
tem mais de 50 estados de espera e a mesma quantidade de atividades
com dependência temporal.
O exemplo acima é apenas a ponta do iceberg. Existem muitos outros
desafios na automação de processos (por exemplo, no processamento
assíncrono de transações, em articulações complexas de serviços, em
processos de alto volume com as respectivas realocações, etc.). Esses
muitas vezes não são conhecidos no começo de uma automação de
processos seletiva e somente serão entendidos como tal quando já for
tarde demais.
Em suma, é bastante claro que o desenvolvimento interno de uma fer-
ramenta de processo faz tão pouco sentido quando o desenvolvimento
interno de um banco de dados ou de um sistema operacional.
Conclusão
De um modo geral, a automação de processos com desenvolvedores
de software internos pode parecer um método lógico à primeira vista.
Especialmente quando existe preocupação com “processo sob medida” e
“independência de fornecedor” e com certeza na automação de proces-
sos de negócios essenciais. Camunda consegue incluir as vantagens do
desenvolvimento interno sem colocar os desenvolvedores numa posição
de reinventar a roda.
5
Implementada dentro de uma aplicação pronta
Implementada dentro de uma aplicação
pronta
Exemplo
Há muitos processos que são comuns a muitas empresas e existem apli-
cações prontas que tiram proveito desse fato (por exemplo, CRM, ERP
etc.). Esses softwares tentam possibilitar o gerenciamento do processo
de uma empresa de forma ampla, sem necessidade de desenvolvedores.
Claro que esse método tem a vantagem de não exigir qualquer progra-
mação, mas também há graves desvantagens a serem consideradas.
Desvantagens
Sem processos feitos sob medida
Como esse tipo de aplicação visa a ser um produto “comprado pronto”,
seu principal objetivo é ter um amplo atrativo. Esses processos mui-
tas vezes não se encaixam na realidade específica de uma empresa. A
automação de processos comuns de apoio, como solicitações de férias
e emissão de faturas, mas a situação não é a mesma quando envolve
os processos essenciais de uma empresa. Processos mais individualiza-
dos, como acionamentos de seguro ou solicitação de telecomunicações
possuem componentes específicos de uma empresa. Na realidade, a
essência de cada negócio é, por princípio, exclusiva, para se diferenciar
da concorrência. É aqui que uma ampla ferramenta de processamento
de negócio perde todas as vantagens.
Alguns fornecedores de aplicações prontas prometem resolver este
problema com a “customização”, que é oferecer ajustes específicos dos
processos para os clientes. Isso levanta a questão de se isso pode ser
suficiente para refletir o grau de individualidade demonstrado no mo-
delo de negócio. Nossa experiência demonstra que, muitas vezes, não
é o caso. Mas mesmo que o fornecedor do software consiga obter essa
customização, ainda existem duas grandes desvantagens para o usuário
final:
Sem agilidade no processo
Em casos muito raros, os ajustes do processo podem ser feitos sem o
envolvimento do fornecedor. Mas na grande maioria dos casos, a custo-
mização é um serviço cobrado pelo fornecedor. Além dos custos asso-
ciados com os ajustes, o prazo alocado para implementar uma mudança
é determinado pelos próprios fornecedores. Restrições de tempo que a
empresa possa ter não seriam levadas em consideração.
6
Implementada dentro de uma aplicação pronta
Ficar preso a um fornecedor
A utilização de aplicações prontas, que dependem do fornecedor para
customização, sempre faz com que a empresa fique presa àquele
fornecedor. Se o relacionamento com o fornecedor se deteriorar, se o
fornecedor for comprado ou se tornar insolvente, isso pode resultar em
sérios riscos para a empresa. Esse fato se tornará mais crítico o quanto
mais profundamente os processos de automação estiverem envolvidos
na atividade principal da empresa.
Sem integração com a TI existente
Outro caso muito raro é de que a aplicação comprada pronta seja o úni-
co elemento no panorama atual de TI. Na maioria dos casos a situação
requer o acréscimo de software à infraestrutura existente. Ocorre que
as aplicações prontas não podem ser facilmente inseridas em estruturas
técnicas existentes e só conseguem funcionar com trabalho adicional.
Sem processos ponta a ponta
Do ponto de vista do negócio, existe um problema mais crítico que surge
do uso de aplicações prontas. A aplicação pronta normalmente repre-
senta apenas uma fração do panorama do processo (por exemplo, ERP,
CRM, etc.). Um verdadeiro processo ponta a ponta que abranja natu-
ralmente múltiplos sistemas de aplicação nunca pode ser totalmente
implementado nas aplicações prontas e isso só pode ser gerenciado,
medido ou aperfeiçoado de forma holística.
Isso resulta em muitos problemas posteriores. Por exemplo, o empre-
gado envolvido muitas vezes trabalha com listas de tarefas múltiplas, já
que todas as aplicações prontas vêm com suas próprias listas de tare-
fas, as quais são – naturalmente – específicas do produto. Cada lista de
tarefas funcionaria de forma diferente e variaria na funcionalidade que
oferece.
Conclusão
O argumento para um produto “comprado pronto” parece forte à pri-
meira vista. No entanto, deve-se ter em mente que os benefícios são
predominantemente de curto prazo, enquanto as desvantagens têm
impacto de longa duração. Uma empresa cujo modelo de negócio está
implementado em TI deve estar ciente de que a TI é o coração da empre-
sa e um fator crítico de sucesso para se diferenciar da concorrência. Essa
percepção posteriormente demonstra que esse componente essencial
não pode ser adquirido com pressa, mas deve ser desenvolvido de for-
ma individual.
Isso não significa que se tenha que reinventar a roda. Significa montar
a sua própria automação de processos individual a partir dos compo-
nentes existentes. Com esses componentes você tem significativamente
mais controle do que teria com aplicações prontas. Camunda BPM ofere-
ce esses componentes, os quais proporcionam controle completo sobre
como os processos são elaborados e mantidos.
7
Conjuntos BPM tradicionais
Conjuntos BPM tradicionais
Exemplo
Conjuntos BPM tradicionais são muito semelhantes a aplicações prontas
em sua tentativa de atender a um grande público – seu objetivo é tentar
agregar valor introduzindo um elemento de programabilidade ao sof-
tware. Eles permitem modelagem individual e projeto técnico de proces-
sos automáticos e semiautomáticos, e assim podem oferecer recursos
de medição e melhoria sistemática.
No entanto, na maior parte eles deixam de oferecer os benefícios
associados com projeto determinado pelo modelo. Sendo forçados a
modelar aspectos da aplicação de processos como máscaras, interfaces
e similares, perde-se a facilidade de mapear o processo sem precisar
conhecer a infraestrutura.
Como consequência de querer proporcionar programabilidade, o desen-
volvimento de software proprietário é naturalmente necessário. Isso, por
sua vez, coloca na empresa a responsabilidade de aprender a desenvol-
ver implementação de software específica do fornecedor.
Em nossa ampla experiência com projetos BPM, descobrimos que, na
verdade, é esse “benefício” percebido que causa a maioria dos proble-
mas com conjuntos BPM de transição. O problema é especialmente
acentuado quando já está ocorrendo desenvolvimento de software na
própria empresa de forma estruturada, por exemplo, em Java ou JavaS-
cript.
Desvantagens
Grande esforço de programação
Como o desenvolvimento de software é específico do fornecedor, os
desenvolvedores da própria empresa precisam aprender e praticar a
plataforma específica do fornecedor. A despesa relacionada não é única,
mas contínua, já que é necessário novo treinamento para assegurar
que o conhecimento seja mantido. Qualquer conhecimento existente de
desenvolvimento de software em Java ou JavaScript (por exemplo) não
pode ser aplicado. Além disso, as atuais ferramentas, técnicas e me-
lhores práticas de desenvolvimento de software (por exemplo, teste de
unidade) não podem ser aplicadas ou podem apenas parcialmente. Isso
limita bastante a produtividade dos desenvolvedores. Como consequên-
cia, a implementação técnica é muito mais complexa do que aparenta à
primeira vista.
Incapacidade de se modelarem partes distintas de um
processo
Em razão de um método de desenvolvimento predominantemente
determinado pelo modelo, as possibilidades de implementação técnica
são limitadas. A seguinte comparação ilustra esse problema: Em uma
tela em branco, um artista pode pintar um quadro exatamente como
8
Conjuntos BPM tradicionais
ele imagina. Alternativamente, existe o princípio de “pintar por núme-
ros”, em que mesmo um leigo pode criar imagens incríveis colorindo
áreas predeterminadas. No entanto, eles só podem criar o que foi
pré-elaborado.
De forma semelhante às aplicações compradas prontas, o princípio de
“pintar por números” em conjuntos BPM muitas vezes é flexível o sufi-
ciente para processos padrão de suporte (por exemplo, solicitações de
férias, emissão de faturas). No entanto, as possibilidades limitadas de
implementação técnica são insuficientes para captar e implementar os
processos do negócio essencial.
Sem integração na TI existente
Em nível operacional, as desvantagens das aplicações prontas também
se aplicam a conjuntos tradicionais de BPM: não podem ser facilmente
inseridos em estruturas existentes de TI.
Necessidade de desenvolvedores especializados
Como já citado, um método de desenvolvimento determinado pelo
modelo é inevitavelmente específico do fornecedor. Então não há como
fugir do fato de que você precisará de desenvolvedores treinados especi-
ficamente para usar um conjunto BPM específico. Se eles não estiverem
disponíveis, eles serão muito mais difíceis de encontrar do que desenvol-
vedores em linguagens de programação populares como Java ou JavaS-
cript.
Ficar preso a um fornecedor
Como consequência, há uma forte dependência do fornecedor, já que
ele e seus parceiros são normalmente os únicos que possuem desen-
volvedores com o nível necessário de conhecimento. Isso é aceitável no
contexto de processos de suporte (por exemplo, solicitações de férias,
emissão de faturas), mas representa um risco inaceitável ao captar e
implementar processos de negócios essenciais.
Conclusão
Os conjuntos BPM tradicionais sofrem de um problema de estarem
“presos no meio”. A usabilidade tem sua extensão forçada na tentativa
de acomodar recursos de dois métodos diferentes.
Eles são tão inadequados quanto produtos de aplicação comprados
prontos para o desenvolvimento de software já existente em qualquer
empresa e nem mesmo conseguem oferecer uma solução pronta para a
automação de processos. Esse dilema resulta de uma busca infrutífera
por uma conciliação entre os dois extremos, em grande parte, de um
fluxo mais acadêmico da última década (desenvolvimento de software
determinado pelo modelo). As baixas taxas de crescimento desses pro-
dutos na última década parecem confirmar essa presunção.
9
Camunda BPM
Camunda BPM
Um breve exemplo
Camunda não acredita na capacidade de soluções prontas para auto-
mação de processos e não está tentando manter empresas presas a ela
insistindo em nada de natureza proprietária. Esses fatos significam que
tudo de que uma empresa precisa é conhecimento, habilidades e ferra-
mentas para seus atuais desenvolvedores projetarem e executarem um
gerenciamento de processo de ponta a ponta. Os padrões de modela-
gem e integração Java ou JavaScript que Camunda utiliza são totalmente
abertos e amplamente aceitos. Isso nos dá uma gama de vantagens em
relação a outras opções de BPM, o que pode ser comprovado por exem-
plos do mundo real.
Vantagens
Transparência e agilidade do processo
Camunda segue à risca o padrão ISSO para modelagem de processo, o
BPMN 2.0. Os processos que precisam ser automatizados podem ser
documentados de forma gráfica pelos respectivos setores e executados
no Camunda sem transformação adicional. Operacionalmente, os pro-
cessos atuais podem ser visualizados de forma direta. O “código fonte”
do processo também pode ser visualizado e facilmente entendido pelos
setores de negócio.
Esse fato, por exemplo, aumentou a agilidade dos processos na Zalando
AG, como confirmado por Marko Lehn (Líder de Equipe de Engenharia
de Software):
Menor esforço de programação
Os desafios técnicos vivenciados durante a automação de processos
de uma solução desenvolvida internamente são resolvidos no desen-
volvimento de Camunda BPM. A ferramenta de processo no âmago da
plataforma é um componente maduro e estável com funções poderosas,
que podem ser usadas para projetos imediatamente.
»Nossos modelos de processo BPMN 2.0 são executados direta-
mente, o que melhorou a comunicação entre os setores negociais
e o desenvolvimento, e reduziu os ciclos de desenvolvimento.«
Zalando AG
Marko Lehn
Líder de Equipe de Engenharia de
Software
10
Camunda BPM
Aplicações inseridas sob medida
Ao contrário de conjuntos BPM tradicionais, Camunda é uma estrutura
aberta que pode ser inserida sem problemas no atual ambiente técnico.
Ela permite o uso de todo o ecossistema Java ou JavaScript para o desen-
volvimento de aplicações de processo e não impõe restrições ao uso de
outros componentes e estruturas (por exemplo, Spring, Java EE, etc.).
A integração existente com Java EE foi um argumento essencial para o
uso de Camunda BPM na Freenet AG:
Isso já foi provado em um contexto desafiador na Lufthansa Technik,
como explica Tobias Mohr (Líder de Equipe de Projetos e Sistemas de TI):
Sem necessidade de desenvolvedores especializados ou de
ficar preso a um fornecedor
Camunda BPM é de código aberto e livremente disponível. Se necessá-
rio, Camunda, como fornecedor, também oferece uma edição corpora-
tiva Camunda BPM Enterprise Edition, suporte técnico com acordo de
nível de serviço (SLA), atualizações, correções, manutenção evolutiva
dentro da versão (patch releases) e funcionalidades extras de adminis-
tração e monitoramento em grandes volumes de dados históricos. Essa
combinação significa que qualquer Incorporador Java ou JavaScript pode
trabalhar de forma produtiva em curto prazo com Camunda BPM e a
dependência de Camunda como fornecedor é mínima.
Esse fato foi decisivo para o uso de Camunda BPM na 11 Internet AG:
»Em Camunda BPM encontramos uma plataforma enxuta e está-
vel para nossos projetos ágeis de BPM/SOA em um complexo am-
biente de processo. O desempenho e confiabilidade de Camunda
BPM foram comprovados em vários projetos e confirmou nossa
opção pelo produto.«
Lufthansa Technik
Tobias Mohr
Líder de Equipe de Projetos e
Sistemas de TI
»Duas coisas são importantes para a automação de nossos pro-
cessos essenciais: alta disponibilidade em um cenário de carga
pesada e integração em nosso modelo de programação atual Java
EE6. Ambos são fornecidos com Camunda BPM.«Freenet AG
11
Camunda BPM
Conclusão
●● Camunda vs. Desenvolvimento Interno: Em termos de sistemas de
automação de processos desenvolvidos internamente, Camunda BPM
possui todas as vantagens desse método combinadas com uma maior
transparência e escalabilidade de processos.
●● Camunda vs. Aplicações Prontas: Camunda BPM é muito superior à
automação de processos que vem inserida em aplicações prontas. É
ágil, pode ser completamente adaptada às necessidades da empresa
e até mesmo totalmente integrada à infraestrutura existente de TI.
●● Camunda vs. Conjuntos BPM Tradicionais: Camunda BPM também
oferece qualquer benefício aparente de um conjunto BPM tradicional
sem ter que fazer o desenvolvedor sofrer com práticas proprietárias
de desenvolvimento.
●● Finalmente, se você pretende ajudar uma empresa a manter coesão e
escalabilidade à medida que cresce, é essencial implementar o Geren-
ciamento de Processos de Negócio. Se você quer desfrutar de todos
os benefícios disponíveis desse método você vai precisar de Camunda
BPM.
»Preferimos soluções de código aberto que nos proporciona
controle total da tecnologia e permitem o desenvolvimento de
adaptações específicas, se necessário. Camunda BPM veio a ser
uma solução ideal para nós. Também vemos uma excelente opor-
tunidade de compartilhar nosso conhecimento de processo com
outros e nos beneficiarmos de uma comunidade ativa por trás de
Camunda BPM.«11 Internet AG
12
Marca
Marca
Europa/Ásia
Camunda Services GmbH
Zossener Str. 55
10961 Berlin
Alemanha
Fone: +49 (0) 30 664 04 09 - 00
E-Mail: info@camunda.com
www.camunda.de
América
Camunda Inc.
44 Montgomery St, Suite 400
San Francisco, CA 94104
Estados Unidos
Fone: +1.415.548.0166
E-Mail: info@camunda.com
www.camunda.com

More Related Content

More from Mauricio Bitencourt, CBPP

Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022
Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022
Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022Mauricio Bitencourt, CBPP
 
A importância da Gestão de Processos nas Organizações: Exemplos Práticos de ...
A importância da Gestão de  Processos nas Organizações: Exemplos Práticos de ...A importância da Gestão de  Processos nas Organizações: Exemplos Práticos de ...
A importância da Gestão de Processos nas Organizações: Exemplos Práticos de ...Mauricio Bitencourt, CBPP
 
Camunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdfCamunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdfMauricio Bitencourt, CBPP
 
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...Mauricio Bitencourt, CBPP
 
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...Mauricio Bitencourt, CBPP
 
Camunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdfCamunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdfMauricio Bitencourt, CBPP
 
Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021
Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021
Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021Mauricio Bitencourt, CBPP
 
Process Mining e Digital Twin na Indústria 4.0
Process Mining e Digital Twin na Indústria 4.0Process Mining e Digital Twin na Indústria 4.0
Process Mining e Digital Twin na Indústria 4.0Mauricio Bitencourt, CBPP
 
BPM Day Paraíba 2018 - Maurício Bitencourt
BPM Day Paraíba 2018 - Maurício BitencourtBPM Day Paraíba 2018 - Maurício Bitencourt
BPM Day Paraíba 2018 - Maurício BitencourtMauricio Bitencourt, CBPP
 
Melhores serviços com a modelagem e a automação de decisões
Melhores serviços com a modelagem e a automação de decisõesMelhores serviços com a modelagem e a automação de decisões
Melhores serviços com a modelagem e a automação de decisõesMauricio Bitencourt, CBPP
 
BPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEG
BPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEGBPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEG
BPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEGMauricio Bitencourt, CBPP
 
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e DecisõesBPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e DecisõesMauricio Bitencourt, CBPP
 
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e DecisõesTDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e DecisõesMauricio Bitencourt, CBPP
 
TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...
TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...
TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...Mauricio Bitencourt, CBPP
 
Transformación Digital de Procesos, Casos y Decisiones
Transformación Digital de Procesos, Casos y DecisionesTransformación Digital de Procesos, Casos y Decisiones
Transformación Digital de Procesos, Casos y DecisionesMauricio Bitencourt, CBPP
 
Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...
Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...
Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...Mauricio Bitencourt, CBPP
 
Transformação Digital da Gestão de Crédito
Transformação Digital da Gestão de CréditoTransformação Digital da Gestão de Crédito
Transformação Digital da Gestão de CréditoMauricio Bitencourt, CBPP
 
Melhoria e Transformação Digital de Processos, Casos e Decisões
Melhoria e Transformação Digital de  Processos, Casos e DecisõesMelhoria e Transformação Digital de  Processos, Casos e Decisões
Melhoria e Transformação Digital de Processos, Casos e DecisõesMauricio Bitencourt, CBPP
 
Segundo Fórum da Comunidade Serpro de Processos
Segundo Fórum da Comunidade Serpro de ProcessosSegundo Fórum da Comunidade Serpro de Processos
Segundo Fórum da Comunidade Serpro de ProcessosMauricio Bitencourt, CBPP
 

More from Mauricio Bitencourt, CBPP (20)

Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022
Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022
Camunda User Group Brazil - Hybrid Meet Up #13 Porto Alegre - 25 Nov 2022
 
A importância da Gestão de Processos nas Organizações: Exemplos Práticos de ...
A importância da Gestão de  Processos nas Organizações: Exemplos Práticos de ...A importância da Gestão de  Processos nas Organizações: Exemplos Práticos de ...
A importância da Gestão de Processos nas Organizações: Exemplos Práticos de ...
 
Camunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdfCamunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #12 Rio de Janeiro - 21 Out 2022.pdf
 
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...
 
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning.  Aper...
Upskilling and Reskilling of IT-BPM Professionals in Lifewide Learning. Aper...
 
Camunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdfCamunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdf
Camunda User Group Brazil - Hybrid Meet-up #11 Cuiabá - 05 Set 2022.pdf
 
Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021
Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021
Camunda User Group Brazil - Remote Meetup #3 - 8 jun 2021
 
Process Mining e Digital Twin na Indústria 4.0
Process Mining e Digital Twin na Indústria 4.0Process Mining e Digital Twin na Indústria 4.0
Process Mining e Digital Twin na Indústria 4.0
 
Remote Camunda Meetup #1 - 9/Jun/2020
Remote Camunda Meetup #1 - 9/Jun/2020Remote Camunda Meetup #1 - 9/Jun/2020
Remote Camunda Meetup #1 - 9/Jun/2020
 
BPM Day Paraíba 2018 - Maurício Bitencourt
BPM Day Paraíba 2018 - Maurício BitencourtBPM Day Paraíba 2018 - Maurício Bitencourt
BPM Day Paraíba 2018 - Maurício Bitencourt
 
Melhores serviços com a modelagem e a automação de decisões
Melhores serviços com a modelagem e a automação de decisõesMelhores serviços com a modelagem e a automação de decisões
Melhores serviços com a modelagem e a automação de decisões
 
BPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEG
BPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEGBPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEG
BPM Day 2017 Porto Alegre - Otimização e Automação de Processos na WEG
 
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e DecisõesBPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
 
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e DecisõesTDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
 
TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...
TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...
TDC 2017 Porto Alegre - Da Modelagem à Execução de Processos, Casos e Decisõ...
 
Transformación Digital de Procesos, Casos y Decisiones
Transformación Digital de Procesos, Casos y DecisionesTransformación Digital de Procesos, Casos y Decisiones
Transformación Digital de Procesos, Casos y Decisiones
 
Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...
Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...
Transformação Digital da Gestão de Crédito - Apresentação da Fundacred no BPM...
 
Transformação Digital da Gestão de Crédito
Transformação Digital da Gestão de CréditoTransformação Digital da Gestão de Crédito
Transformação Digital da Gestão de Crédito
 
Melhoria e Transformação Digital de Processos, Casos e Decisões
Melhoria e Transformação Digital de  Processos, Casos e DecisõesMelhoria e Transformação Digital de  Processos, Casos e Decisões
Melhoria e Transformação Digital de Processos, Casos e Decisões
 
Segundo Fórum da Comunidade Serpro de Processos
Segundo Fórum da Comunidade Serpro de ProcessosSegundo Fórum da Comunidade Serpro de Processos
Segundo Fórum da Comunidade Serpro de Processos
 

Camunda em comparação com alternativas

  • 1. Camunda BPM em comparação com alternativas Maio de 2015 – camunda.com
  • 2. Índice Índice Comparações com alternativas���������������������������������������������������������������������� 2 Introdução: Vantagens da automação����������������������������������������������������������� 2 Automação de processos desenvolvida internamente�������������������������������� 3 Implementada dentro de uma aplicação pronta������������������������������������������ 5 Conjuntos BPM tradicionais���������������������������������������������������������������������������� 7 Camunda BPM�������������������������������������������������������������������������������������������������� 9
  • 3. 2 Comparações com alternativas Comparações com alternativas Introdução: Vantagens da automação A automação de processos é uma forma inteligente de organizar tare- fas de negócios em um processo. Existem razões óbvias para empresas adotarem esse método: ●● Custos mais baixos – com automação, menos tarefas precisam ser tratadas manualmente. ●● Processos mais rápidos – com a eliminação de tempo ocioso que ine- vitavelmente acontece com processamento manual. ●● Menos erros de processo – outra vantagem de reduzir as tarefas ma- nuais em um processo é que você terá menos erros. Para um negócio em expansão, processos de negócio desorganizados ou não documentados muitas vezes são um obstáculo para a escalabilida- de. Como consequência, a capacidade de crescimento da empresa fica prejudicada. Sem automação Desenvolvidas internamente Aplicações prontas Conjuntos BPM tradicionais Camunda BPM Menor custo de processo Execuções mais rápidas de processos Menos erros de processo Real transparência do processo Possivelmente Possivelmente Maior agilidade do processo Possivelmente Menor esforço de programação Processos feitos sob medida Integração na TI existente Sem necessidade de desenvolvedores espe- cíficos do fornecedor Sem ficar preso a um fornecedor Processos ponta a ponta Possivelmente
  • 4. 3 Automação de processos desenvolvida internamente Usando nossa experiência direta com projetos de clientes, bem como trabalhando com questões levantadas pelos próprios clientes, compila- mos uma crítica detalhada das opções disponíveis em termos de auto- mação de processos. Para dar algum contexto ao documento, é bom ter em mente que es- tamos fazendo nossas avaliações com base em empresas que realizam desenvolvimento de software e com disponibilidade de desenvolvedores apropriados. Automação de processos desenvolvida internamente Exemplo Muitas vezes uma empresa reconhece que alguns de seus processos manuais seriam melhores se fossem automatizados. Assim, alguém na empresa pode decidir passar algum tempo escrevendo um programa simples que automatize um processo comum. Os benefícios de automa- tizar processos manuais podem se tornar aparentes bem depressa. O programa simples pode ser expandido para incluir mais processamento. A conclusão lógica disso é um programa que funciona como uma caixa preta, na qual ele inicia, depois algo acontece e, em algum ponto, o pro- cesso se conclui ou falha. Infelizmente, há grandes desvantagens nesse método. Desvantagens Sem transparência no processo A lógica do processo é expressa diretamente no código fonte, o qual só é compreensível ou conhecido pelos programadores respectivos. Também não é incomum que se acrescente mais código sem atualização na do- cumentação. Os processos são muitas vezes modelados em documento de requisitos ou escritos num estágio posterior. No entanto, nunca se pode saber com certeza se essas representações criadas manualmente correspondem efetivamente à realidade. Isso se aplica tanto à questão fundamental de como os processos são executados quanto à questão de como um processo em particular (instância de processo) foi efetivamente executado em casos individuais. Isso pode ser um grande problema para setores que precisam obede- cer a uma regulamentação rígida. O cumprimento dessas normas nem sempre pode ser garantido. Sem agilidade no processo Tanto a implementação técnica inicial dos processos como a adaptação dos processos já implementados exigem comunicação intensa. Qual- quer implementação técnica exige uma complexa coordenação entre os especialistas da matéria bem como profissionais de TI, estando sujeita a
  • 5. 4 Automação de processos desenvolvida internamente erros e demandando tempo. Muitas vezes, os processos desejados são descritos pelo lado negocial em notação relativamente não vinculante, que o lado da TI terá que entender primeiro para conseguir produzir resultados significativos. Esses resultados são muitas vezes prejudicados por atrasos e erros em vários estágios em razão desse processo impreci- so de comunicação. Grande esforço de programação O desafio de automatizar processos de negócio é muitas vezes subes- timado. À primeira vista, parece ser tecnicamente simples programar uma sequência de atividades ao mesmo tempo em que se levam em consideração estruturas rudimentares de controle (se / então, etc.). No entanto, os desafios surgem com frequência quando se chega a estados de espera durante a execução. Por exemplo: Recebemos um pedido que precisa ser examinado por um atendente. Depois do exame, o item é enviado. Se o exame ultrapassar um determinado limite de tempo, um lembrete deve ser acionado e, se isso não for bem sucedido, será necessária uma realocação para ou- tro atendente. O estado de espera descrito neste exemplo (o processo aguarda a conclusão da tarefa), em combinação com o prazo apertado necessário para acionamento de dois níveis, é relativamente desafiador para programar. O esforço aumenta exponencialmente com a complexi- dade do processo: em processos reais ponta a ponta, muitas vezes exis- tem mais de 50 estados de espera e a mesma quantidade de atividades com dependência temporal. O exemplo acima é apenas a ponta do iceberg. Existem muitos outros desafios na automação de processos (por exemplo, no processamento assíncrono de transações, em articulações complexas de serviços, em processos de alto volume com as respectivas realocações, etc.). Esses muitas vezes não são conhecidos no começo de uma automação de processos seletiva e somente serão entendidos como tal quando já for tarde demais. Em suma, é bastante claro que o desenvolvimento interno de uma fer- ramenta de processo faz tão pouco sentido quando o desenvolvimento interno de um banco de dados ou de um sistema operacional. Conclusão De um modo geral, a automação de processos com desenvolvedores de software internos pode parecer um método lógico à primeira vista. Especialmente quando existe preocupação com “processo sob medida” e “independência de fornecedor” e com certeza na automação de proces- sos de negócios essenciais. Camunda consegue incluir as vantagens do desenvolvimento interno sem colocar os desenvolvedores numa posição de reinventar a roda.
  • 6. 5 Implementada dentro de uma aplicação pronta Implementada dentro de uma aplicação pronta Exemplo Há muitos processos que são comuns a muitas empresas e existem apli- cações prontas que tiram proveito desse fato (por exemplo, CRM, ERP etc.). Esses softwares tentam possibilitar o gerenciamento do processo de uma empresa de forma ampla, sem necessidade de desenvolvedores. Claro que esse método tem a vantagem de não exigir qualquer progra- mação, mas também há graves desvantagens a serem consideradas. Desvantagens Sem processos feitos sob medida Como esse tipo de aplicação visa a ser um produto “comprado pronto”, seu principal objetivo é ter um amplo atrativo. Esses processos mui- tas vezes não se encaixam na realidade específica de uma empresa. A automação de processos comuns de apoio, como solicitações de férias e emissão de faturas, mas a situação não é a mesma quando envolve os processos essenciais de uma empresa. Processos mais individualiza- dos, como acionamentos de seguro ou solicitação de telecomunicações possuem componentes específicos de uma empresa. Na realidade, a essência de cada negócio é, por princípio, exclusiva, para se diferenciar da concorrência. É aqui que uma ampla ferramenta de processamento de negócio perde todas as vantagens. Alguns fornecedores de aplicações prontas prometem resolver este problema com a “customização”, que é oferecer ajustes específicos dos processos para os clientes. Isso levanta a questão de se isso pode ser suficiente para refletir o grau de individualidade demonstrado no mo- delo de negócio. Nossa experiência demonstra que, muitas vezes, não é o caso. Mas mesmo que o fornecedor do software consiga obter essa customização, ainda existem duas grandes desvantagens para o usuário final: Sem agilidade no processo Em casos muito raros, os ajustes do processo podem ser feitos sem o envolvimento do fornecedor. Mas na grande maioria dos casos, a custo- mização é um serviço cobrado pelo fornecedor. Além dos custos asso- ciados com os ajustes, o prazo alocado para implementar uma mudança é determinado pelos próprios fornecedores. Restrições de tempo que a empresa possa ter não seriam levadas em consideração.
  • 7. 6 Implementada dentro de uma aplicação pronta Ficar preso a um fornecedor A utilização de aplicações prontas, que dependem do fornecedor para customização, sempre faz com que a empresa fique presa àquele fornecedor. Se o relacionamento com o fornecedor se deteriorar, se o fornecedor for comprado ou se tornar insolvente, isso pode resultar em sérios riscos para a empresa. Esse fato se tornará mais crítico o quanto mais profundamente os processos de automação estiverem envolvidos na atividade principal da empresa. Sem integração com a TI existente Outro caso muito raro é de que a aplicação comprada pronta seja o úni- co elemento no panorama atual de TI. Na maioria dos casos a situação requer o acréscimo de software à infraestrutura existente. Ocorre que as aplicações prontas não podem ser facilmente inseridas em estruturas técnicas existentes e só conseguem funcionar com trabalho adicional. Sem processos ponta a ponta Do ponto de vista do negócio, existe um problema mais crítico que surge do uso de aplicações prontas. A aplicação pronta normalmente repre- senta apenas uma fração do panorama do processo (por exemplo, ERP, CRM, etc.). Um verdadeiro processo ponta a ponta que abranja natu- ralmente múltiplos sistemas de aplicação nunca pode ser totalmente implementado nas aplicações prontas e isso só pode ser gerenciado, medido ou aperfeiçoado de forma holística. Isso resulta em muitos problemas posteriores. Por exemplo, o empre- gado envolvido muitas vezes trabalha com listas de tarefas múltiplas, já que todas as aplicações prontas vêm com suas próprias listas de tare- fas, as quais são – naturalmente – específicas do produto. Cada lista de tarefas funcionaria de forma diferente e variaria na funcionalidade que oferece. Conclusão O argumento para um produto “comprado pronto” parece forte à pri- meira vista. No entanto, deve-se ter em mente que os benefícios são predominantemente de curto prazo, enquanto as desvantagens têm impacto de longa duração. Uma empresa cujo modelo de negócio está implementado em TI deve estar ciente de que a TI é o coração da empre- sa e um fator crítico de sucesso para se diferenciar da concorrência. Essa percepção posteriormente demonstra que esse componente essencial não pode ser adquirido com pressa, mas deve ser desenvolvido de for- ma individual. Isso não significa que se tenha que reinventar a roda. Significa montar a sua própria automação de processos individual a partir dos compo- nentes existentes. Com esses componentes você tem significativamente mais controle do que teria com aplicações prontas. Camunda BPM ofere- ce esses componentes, os quais proporcionam controle completo sobre como os processos são elaborados e mantidos.
  • 8. 7 Conjuntos BPM tradicionais Conjuntos BPM tradicionais Exemplo Conjuntos BPM tradicionais são muito semelhantes a aplicações prontas em sua tentativa de atender a um grande público – seu objetivo é tentar agregar valor introduzindo um elemento de programabilidade ao sof- tware. Eles permitem modelagem individual e projeto técnico de proces- sos automáticos e semiautomáticos, e assim podem oferecer recursos de medição e melhoria sistemática. No entanto, na maior parte eles deixam de oferecer os benefícios associados com projeto determinado pelo modelo. Sendo forçados a modelar aspectos da aplicação de processos como máscaras, interfaces e similares, perde-se a facilidade de mapear o processo sem precisar conhecer a infraestrutura. Como consequência de querer proporcionar programabilidade, o desen- volvimento de software proprietário é naturalmente necessário. Isso, por sua vez, coloca na empresa a responsabilidade de aprender a desenvol- ver implementação de software específica do fornecedor. Em nossa ampla experiência com projetos BPM, descobrimos que, na verdade, é esse “benefício” percebido que causa a maioria dos proble- mas com conjuntos BPM de transição. O problema é especialmente acentuado quando já está ocorrendo desenvolvimento de software na própria empresa de forma estruturada, por exemplo, em Java ou JavaS- cript. Desvantagens Grande esforço de programação Como o desenvolvimento de software é específico do fornecedor, os desenvolvedores da própria empresa precisam aprender e praticar a plataforma específica do fornecedor. A despesa relacionada não é única, mas contínua, já que é necessário novo treinamento para assegurar que o conhecimento seja mantido. Qualquer conhecimento existente de desenvolvimento de software em Java ou JavaScript (por exemplo) não pode ser aplicado. Além disso, as atuais ferramentas, técnicas e me- lhores práticas de desenvolvimento de software (por exemplo, teste de unidade) não podem ser aplicadas ou podem apenas parcialmente. Isso limita bastante a produtividade dos desenvolvedores. Como consequên- cia, a implementação técnica é muito mais complexa do que aparenta à primeira vista. Incapacidade de se modelarem partes distintas de um processo Em razão de um método de desenvolvimento predominantemente determinado pelo modelo, as possibilidades de implementação técnica são limitadas. A seguinte comparação ilustra esse problema: Em uma tela em branco, um artista pode pintar um quadro exatamente como
  • 9. 8 Conjuntos BPM tradicionais ele imagina. Alternativamente, existe o princípio de “pintar por núme- ros”, em que mesmo um leigo pode criar imagens incríveis colorindo áreas predeterminadas. No entanto, eles só podem criar o que foi pré-elaborado. De forma semelhante às aplicações compradas prontas, o princípio de “pintar por números” em conjuntos BPM muitas vezes é flexível o sufi- ciente para processos padrão de suporte (por exemplo, solicitações de férias, emissão de faturas). No entanto, as possibilidades limitadas de implementação técnica são insuficientes para captar e implementar os processos do negócio essencial. Sem integração na TI existente Em nível operacional, as desvantagens das aplicações prontas também se aplicam a conjuntos tradicionais de BPM: não podem ser facilmente inseridos em estruturas existentes de TI. Necessidade de desenvolvedores especializados Como já citado, um método de desenvolvimento determinado pelo modelo é inevitavelmente específico do fornecedor. Então não há como fugir do fato de que você precisará de desenvolvedores treinados especi- ficamente para usar um conjunto BPM específico. Se eles não estiverem disponíveis, eles serão muito mais difíceis de encontrar do que desenvol- vedores em linguagens de programação populares como Java ou JavaS- cript. Ficar preso a um fornecedor Como consequência, há uma forte dependência do fornecedor, já que ele e seus parceiros são normalmente os únicos que possuem desen- volvedores com o nível necessário de conhecimento. Isso é aceitável no contexto de processos de suporte (por exemplo, solicitações de férias, emissão de faturas), mas representa um risco inaceitável ao captar e implementar processos de negócios essenciais. Conclusão Os conjuntos BPM tradicionais sofrem de um problema de estarem “presos no meio”. A usabilidade tem sua extensão forçada na tentativa de acomodar recursos de dois métodos diferentes. Eles são tão inadequados quanto produtos de aplicação comprados prontos para o desenvolvimento de software já existente em qualquer empresa e nem mesmo conseguem oferecer uma solução pronta para a automação de processos. Esse dilema resulta de uma busca infrutífera por uma conciliação entre os dois extremos, em grande parte, de um fluxo mais acadêmico da última década (desenvolvimento de software determinado pelo modelo). As baixas taxas de crescimento desses pro- dutos na última década parecem confirmar essa presunção.
  • 10. 9 Camunda BPM Camunda BPM Um breve exemplo Camunda não acredita na capacidade de soluções prontas para auto- mação de processos e não está tentando manter empresas presas a ela insistindo em nada de natureza proprietária. Esses fatos significam que tudo de que uma empresa precisa é conhecimento, habilidades e ferra- mentas para seus atuais desenvolvedores projetarem e executarem um gerenciamento de processo de ponta a ponta. Os padrões de modela- gem e integração Java ou JavaScript que Camunda utiliza são totalmente abertos e amplamente aceitos. Isso nos dá uma gama de vantagens em relação a outras opções de BPM, o que pode ser comprovado por exem- plos do mundo real. Vantagens Transparência e agilidade do processo Camunda segue à risca o padrão ISSO para modelagem de processo, o BPMN 2.0. Os processos que precisam ser automatizados podem ser documentados de forma gráfica pelos respectivos setores e executados no Camunda sem transformação adicional. Operacionalmente, os pro- cessos atuais podem ser visualizados de forma direta. O “código fonte” do processo também pode ser visualizado e facilmente entendido pelos setores de negócio. Esse fato, por exemplo, aumentou a agilidade dos processos na Zalando AG, como confirmado por Marko Lehn (Líder de Equipe de Engenharia de Software): Menor esforço de programação Os desafios técnicos vivenciados durante a automação de processos de uma solução desenvolvida internamente são resolvidos no desen- volvimento de Camunda BPM. A ferramenta de processo no âmago da plataforma é um componente maduro e estável com funções poderosas, que podem ser usadas para projetos imediatamente. »Nossos modelos de processo BPMN 2.0 são executados direta- mente, o que melhorou a comunicação entre os setores negociais e o desenvolvimento, e reduziu os ciclos de desenvolvimento.« Zalando AG Marko Lehn Líder de Equipe de Engenharia de Software
  • 11. 10 Camunda BPM Aplicações inseridas sob medida Ao contrário de conjuntos BPM tradicionais, Camunda é uma estrutura aberta que pode ser inserida sem problemas no atual ambiente técnico. Ela permite o uso de todo o ecossistema Java ou JavaScript para o desen- volvimento de aplicações de processo e não impõe restrições ao uso de outros componentes e estruturas (por exemplo, Spring, Java EE, etc.). A integração existente com Java EE foi um argumento essencial para o uso de Camunda BPM na Freenet AG: Isso já foi provado em um contexto desafiador na Lufthansa Technik, como explica Tobias Mohr (Líder de Equipe de Projetos e Sistemas de TI): Sem necessidade de desenvolvedores especializados ou de ficar preso a um fornecedor Camunda BPM é de código aberto e livremente disponível. Se necessá- rio, Camunda, como fornecedor, também oferece uma edição corpora- tiva Camunda BPM Enterprise Edition, suporte técnico com acordo de nível de serviço (SLA), atualizações, correções, manutenção evolutiva dentro da versão (patch releases) e funcionalidades extras de adminis- tração e monitoramento em grandes volumes de dados históricos. Essa combinação significa que qualquer Incorporador Java ou JavaScript pode trabalhar de forma produtiva em curto prazo com Camunda BPM e a dependência de Camunda como fornecedor é mínima. Esse fato foi decisivo para o uso de Camunda BPM na 11 Internet AG: »Em Camunda BPM encontramos uma plataforma enxuta e está- vel para nossos projetos ágeis de BPM/SOA em um complexo am- biente de processo. O desempenho e confiabilidade de Camunda BPM foram comprovados em vários projetos e confirmou nossa opção pelo produto.« Lufthansa Technik Tobias Mohr Líder de Equipe de Projetos e Sistemas de TI »Duas coisas são importantes para a automação de nossos pro- cessos essenciais: alta disponibilidade em um cenário de carga pesada e integração em nosso modelo de programação atual Java EE6. Ambos são fornecidos com Camunda BPM.«Freenet AG
  • 12. 11 Camunda BPM Conclusão ●● Camunda vs. Desenvolvimento Interno: Em termos de sistemas de automação de processos desenvolvidos internamente, Camunda BPM possui todas as vantagens desse método combinadas com uma maior transparência e escalabilidade de processos. ●● Camunda vs. Aplicações Prontas: Camunda BPM é muito superior à automação de processos que vem inserida em aplicações prontas. É ágil, pode ser completamente adaptada às necessidades da empresa e até mesmo totalmente integrada à infraestrutura existente de TI. ●● Camunda vs. Conjuntos BPM Tradicionais: Camunda BPM também oferece qualquer benefício aparente de um conjunto BPM tradicional sem ter que fazer o desenvolvedor sofrer com práticas proprietárias de desenvolvimento. ●● Finalmente, se você pretende ajudar uma empresa a manter coesão e escalabilidade à medida que cresce, é essencial implementar o Geren- ciamento de Processos de Negócio. Se você quer desfrutar de todos os benefícios disponíveis desse método você vai precisar de Camunda BPM. »Preferimos soluções de código aberto que nos proporciona controle total da tecnologia e permitem o desenvolvimento de adaptações específicas, se necessário. Camunda BPM veio a ser uma solução ideal para nós. Também vemos uma excelente opor- tunidade de compartilhar nosso conhecimento de processo com outros e nos beneficiarmos de uma comunidade ativa por trás de Camunda BPM.«11 Internet AG
  • 13. 12 Marca Marca Europa/Ásia Camunda Services GmbH Zossener Str. 55 10961 Berlin Alemanha Fone: +49 (0) 30 664 04 09 - 00 E-Mail: info@camunda.com www.camunda.de América Camunda Inc. 44 Montgomery St, Suite 400 San Francisco, CA 94104 Estados Unidos Fone: +1.415.548.0166 E-Mail: info@camunda.com www.camunda.com