BPMS na nuvem – uma visão geral

Por muito tempo as ferramentas de BPMS só poderiam ser utilizadas após serem instaladas no ambiente da organização. Era necessária então a instalação do software em um servidor, após esta instalação era disponibilizada uma URL para os usuários acessarem o ambiente através de um navegador Web (normalmente para execução e acompanhamento dos processos automatizados). Também era comum a necessidade de instalar algum software no computador dos usuários (normalmente para fins de modelagem e automação). Fornecedores de ferramentas costumam referenciar isto como a versão “on premises” (local) da ferramenta de BPMS.

Assim, mesmo que o objetivo fosse apenas realizar testes rápidos de usabilidade e recursos da ferramenta, existia um caminho tortuoso que precisava ser seguido:

  • Fazer o download da ferramenta, onde os arquivos de instalação em muitos casos eram grandes, exigindo uma boa conexão com a internet e um considerável tempo de download;
  • Disponibilizar um servidor em que a ferramenta pudesse ser instalada e configurada, onde normalmente são exigidas máquinas mais parrudas, com múltiplos processadores e grande quantidade de memória;
  • Realizar o  processo de instalação, que por vezes era desafiador, exigindo pessoas com conhecimento técnico (muitas vezes não existente na organização, então um treinamento ou auto-estudo era necessário), incluindo a disponibilização de um banco de dados existente, que a ferramenta possa utilizar para armazenar as informações.

Depois destes passos é que, finalmente, a ferramenta se encontrava disponível para utilização pelos usuários.

Note que os passos acima se referem apenas a disponibilização de um ambiente de desenvolvimento/testes. A situação fica mais complicada se estivermos falando de instalação em ambiente de produção, em que outros fatores devem ser levados em consideração e onde costuma ser necessário:

  • Mensurar o hardware adequado para suportar a utilização atual (e futura) da ferramenta na organização;
  • Avaliar questões relativas a backup/restore;
  • Avaliar estabelecimento de máquinas em cluster e ambiente de pronta disponibilidade;
  • Avaliar regras de acesso ao ambiente de fora da organização;
  • Definir Regras de segurança, SSL;
  • Avaliar critérios e regras para aplicação de patches e novas versões;
  • Etc.

Parece complicado, não? De fato é. E este cenário ainda é uma realidade em várias ferramentas existentes no mercado.

Mas o que acontece então se a organização não tem os recursos (humanos/tecnológicos/financeiros) para viabilizar a instalação local de uma ferramenta? Significa que a adoção de uma ferramenta de BPMS, na prática, só se aplica a grandes organizações, que dispõe de mais recursos e capacidade de investimento?

A boa notícia é que com a popularização de BPM, um novo tipo de ferramenta está sendo oferecido no mercado, como alternativas ao modelo “local” (on premises) tradicional. Estamos falando aqui de soluções de BPMS na nuvem.

Uma solução de BPMS oferecida na nuvem tem como principais características:

  • Nenhuma instalação local é necessária no ambiente da organização e nos computadores dos usuários;
  • O ambiente de BPMS é disponibilizado pelo fabricante em seus próprios servidores, onde normalmente são oferecidos critérios de alta disponibilidade, segurança, redundância e backup;
  • Todo o acesso à ferramenta é feito via internet através de um browser;
  • A configuração de usuários é normalmente feita dentro da área de administração da ferramenta. Dependendo da ferramenta, existem possibilidades de integração com repositórios de usuários da organização;

Mas quais seriam os benefícios que podemos ter com a adoção de uma solução em nuvem? Vejamos alguns dos principais:

  •  Baixo investimento inicial para adquirir a solução, visto que não é necessário disponibilizar uma infraestrutura interna para instalação e manutenção da solução, bem como não existe um produto a ser “comprado” (o que existe é um modelo de subscrição);
  • Patches de correção e melhorias da ferramenta são garantidas e executadas automaticamente pelo fornecedor, enquanto durar o licenciamento;
  • O licenciamento costuma ser por usuário, o que pode ser bastante interessante e gerar economia, dependendo da quantidade de usuários que irão utilizar a ferramenta;
  • Camadas mais claramente separadas da lógica do negócio e dos sistemas de informação, visto que em se tratando de ferramenta disponibilizada em ambiente web, normalmente temos uma solução mais amigável e menos técnica. Isto incentiva um maior envolvimento da área de negócio em todo o ciclo de modelagem e implementação de processos. Podendo chegar, inclusive, na  possibilidade das próprias áreas modelarem e automatizarem processos (veja aqui o post em que discutimos esta questão);
  • Projetos de implementação evolutivos, em que um processo pode ser rapidamente colocado para ser executado, permitindo que ao longo do tempo novas melhorias e integrações sejam disponibilizados;
  • O conceito “Quick wins” (ganhos rápidos) são potencializados na utilização de uma solução em nuvem: como não existe a preocupação com disponibilização e manutenção de infraestrutura, pode-se partir diretamente para os projetos, gerando resultados mais rapidamente.

Parece bom, não? Mas, como nem tudo são flores, achamos importante destacar também algumas das possíveis limitações deste formato:

  •  Com a solução em nuvem, existe a perda de controle em relação ao ambiente e aos dados  informados, podendo levar a questões relacionadas à auditoria e à segurança das informações, e onde os dados serão armazenados. Dependendo das políticas adotadas pela organização, isso pode até inviabilizar a contratação da solução;
  • Normalmente não existe acesso direto aos servidores da solução, então a capacidade de visualizar os logs pode ser limitada, o que leva a mais dificuldades para avaliar e solucionar problemas na execução dos processos, em relação a uma solução instalada localmente;
  • A aplicação automática de patches e evoluções pelo fornecedor pode eventualmente gerar problemas de compatibilidade em processos/projetos existentes;
  • Dependendo da quantidade de usuários que forem utilizar a solução, o licenciamento por usuário poderá elevar o valor da contratação, podendo inclusive a chegar a valores similares a contratação tradicional (on premises);
  • Nos casos das ferramentas de BPMS que também oferecem a versão on premises, a versão em nuvem costuma ser menos robusta e com menos recursos disponíveis (ao menos neste momento). As capacidades de integração dos processos com sistemas existentes também costumam ser mais restritas (normalmente se encontra disponível integração via webservices);
  • Como estamos falando do conceito de subscrição, não existe a opção de ser “dono” da solução e poder assumir totalmente a ferramenta no futuro, algo que pode ser importante para algumas organizações.

Dados os prós e os contras, será que devo adotar uma solução em nuvem? Não existe uma resposta definitiva sobre isto. No final das contas cabe a cada organização fazer uma auto avaliação, pesar os pontos positivos e negativos, e avaliar que tipo de solução atende mais as suas necessidades, seja uma solução em nuvem ou local.

O que podemos afirmar é que a disponibilização de solução de BPMS em nuvem é um caminho sem volta. Grande parte dos fabricantes já oferece ou está procurando oferecer a sua versão da solução em nuvem, justamente pelo apelo e facilidade de utilização.

A tendência é de uma evolução e uma maturidade cada vez maiores das soluções de BPMS ofertadas na nuvem, oferecendo mais opções de escolha para as organizações, e por fim permitindo a um universo maior de organizações poderem desfrutar dos benefícios de BPM!

Usuários de negócio automatizando processos com ferramentas BPMS – será o adeus à TI?

Com múltiplas funcionalidades e novos recursos sendo incluídos periodicamente, as ferramentas de BPMS (Business Process Management Systems) tem se destacado como uma das categorias de software mais abrangentes disponíveis no mercado atualmente. A promessa de juntar num mesmo mundo a área de processos, de negócio e TI, através dos recursos de modelagem, análise, redesenho, automação e monitoramento de processos, certamente vem chamando a atenção de muitas organizações, que buscam melhorar seus processos e ter mais agilidade e competitividade.

Com a intenção de destacar a sua ferramenta das demais, é muito frequente nos depararmos com o discurso de fornecedores das ferramentas de BPM contendo frases de impacto marcantes, mais ou menos nesta linha (obs: nenhuma frase é real):

  • “Ferramenta de código zero! Não precisa de uma linha sequer de programação!”;
  • “Não dependa mais da TI!”;
  • “Coloque todo o poder nas mãos da área de negócio!”
  • “Dê aos usuários a possibilidade de alterar e modificar os processos em tempo real!”

Mas então… o quão próximos estamos da própria área de negócio começar a desenhar e automatizar processos, sem necessitar do envolvimento da TI?

De cara, vamos esclarecer um ponto bem importante: automação de processos ainda é, em grande parte, desenvolvimento de software. O que muda em relação ao desenvolvimento de software convencional é apenas a percepção do usuário final do que estaria pronto ou não. Se temos uma aplicação web sendo desenvolvida e elaboramos um protótipo HTML pra fazer uma apresentação preliminar ao usuário final, não raro o feedback recebido é: “Que legal, está pronto?”. Já num projeto de automação de processos, temos um lindo processo modelado em BPMN na ferramenta, o que com alguma frequência também leva os usuários a mesma conclusão: “Mas o processo já está todo desenhado na ferramenta! O que está faltando?”. Ora, pode estar faltando tudo! :-)

O fato de termos um processo modelado em BPMN dentro da ferramenta de BPMS, não significa que ele está pronto pra ser executado, ou que qualquer pessoa com conhecimento em BPMN tenha necessariamente condições de automatizá-lo. Isto ocorre por (dentre outros) vários motivos:

  • É necessário definir o modelo de dados do processo, que são todos os atributos/informações necessárias durante a execução do processo. Isto pode a princípio parecer uma tarefa simples de criar os mesmos campos que haveria em um formulário de papel ou numa planilha eletrônica, mas o processo precisará de mais informações do que isso. Desde informações dinâmicas que aparecem na lista de trabalho, a informações que aparecem no detalhamento das atividades ou mesmo atributos puramente técnicos, invisíveis ao usuário e que só servem para possibilitar a implantação de algum requisito;
  • É necessário conhecimento de integrações de sistemas, visto que em grande maioria dos casos, um processo automatizado tem integração com um ou mais sistemas, para buscar ou gravar informações que são manipuladas no processo. É possível automatizar um processo sem integrações, mas a sua inteligência ficará bastante limitada. Por exemplo, se um aprovador precisa de uma informação que já existe em outro sistema para tomar uma decisão, por quê não faríamos uma integração para buscar este dado, e mostrar a ele na hora de realizar a tarefa? Se já existe um cadastro de fornecedores, por que não fazer uma integração para buscar uma lista de fornecedores, facilitando o preenchimento de uma tarefa e evitando que o usuário tenha que ficar digitando todos os dados?
  • É necessário conhecer como fazer a atribuição dos papéis (roles) aos usuários na ferramenta, sendo frequentemente necessária integração com repositórios de usuários (ex: Active Directory). É possível fazer atribuição direta (“de/para”) de roles do processo para grupos de usuários criados na própria ferramenta de BPMS, mas em cenários reais de automação, muito provavelmente isto não será o suficiente e algum tipo de integração com sistemas ou repositórios de usuários será necessária;
  • É necessário conhecimento de como a ferramenta de BPMS implementa os padrões de workflow/BPMN. Por exemplo, como implementar um subprocesso multi-instance na ferramenta? O fato de marcar um “check” em alguma tela da ferramenta não significa que o comportamento esperado vai ser realizado. É necessário que o usuário de negócio saiba exatamente as implicações, em termos de automação de processos, de um subprocesso multi-instance;
  • É necessário definir e desenvolver todas as interfaces de usuário. A ferramenta de BPM pode oferecer recursos de criação de formulários eletrônicos amigáveis e com pouco código, o que na primeira vista possibilitará ao usuário a criação rápida de formulários eletrônicos. Mas em boa parte das soluções de BPMS é necessário conhecimento mais técnico para conectar este formulário ao modelo de dados do processo, plugar as integrações necessárias (sempre elas!) e definir regras de validação e interface, que não raro exigem a criação de linhas de código de software.

Talvez você agora esteja achando que a resposta para a pergunta do título seja “Não”, certo? Ou talvez esteja achando que os discursos de marketing das ferramentas coloquem uma pressão exagerada nas áreas de negócio, influenciando a tentar resolver todos os seus problemas sozinhas.

A boa notícia é: nem tanto ao mar, nem tanto a terra. Dependendo do BPMS sendo utilizado, se estivermos falamos de um processo simples, sem integração com sistemas externos, com regras de negócio e de interface básicas, então apenas o treinamento na ferramenta poderá sim permitir avanços por usuários de negócio.

Mas não podemos deixar de comentar que os melhores resultados são obtidos quando TI e negócio trabalham juntos, ou seja, existe colaboração na automação de processos. A boa notícia é que as ferramentas de BPMS tem evoluindo muito para reforçar este trabalho colaborativo, onde usuários de negócio podem iniciar o trabalho definindo os processos, quem sabe até mesmo desenhando algumas interfaces de usuários (o que no passado era uma atribuição exclusiva da TI), e no momento adequado a TI poderá “entrar em cena” e colaborar, se encarregando das tarefas mais técnicas.

Esperamos ter colocado um pouco mais de luz sobre esta situação. Pra finalizar, não podemos deixar de louvar o empenho e sucesso dos fornecedores de ferramentas de BPM em deixar as ferramentas cada vez mais produtivas e amigáveis. Temos hoje ferramentas com quase zero código, montagem de formulários eletrônicos de forma intuitiva e configuração visual de integrações. São recursos que certamente incentivam os fornecedores a elaborar este discurso de marketing. :-)

Convite para webinar: Automação de Processos pela Área de Negócio: Oportunidades e Desafios

Sobre este webinar:

A necessidade de se reinventar exige das organizações melhorias constantes em seus processos em prazos cada vez menores. Nesse contexto, a recorrente de falta de recursos da TI e a complexidade cada vez maior dos sistemas de informações levam as organizações a buscar alternativas simples e leves de desenvolvimento que possam ser conduzidas pela própria área de negócio.

A automação de processos através de BPMS oferece esta alternativa, mas será que esta promessa realmente pode ser cumprida? Até onde uma área de negócio consegue conduzir com um projeto de automação e em que momento ela volta a necessitar da TI? Que funcionalidades uma ferramenta de automação deve oferecer para atender a estes requisitos? Quais as características ideais de um processo a ser automatizado pela área de negócio?

Participe deste webinar, apresentado ao vivo em colaboração da iProcess e Lecom BPM, e conheça a resposta a estas e outras perguntas relevantes a quem deseja buscar soluções de automação com pouca dependência da TI.

Como funciona?

É simples: inscreva-se no webinar através do link do evento e você receberá um e-mail de confirmação:
Finalizado! Em breve publicaremos o vídeo e a apresentação do evento.

Na data e horário do evento, acesse o link indicado no e-mail usando um computador com fones e aguarde a seção começar.
Durante a apresentação, você poderá interagir com o instrutor enviando perguntas via chat, que serão respondidas ao final do seminário.

Webinares anteriores:

Confira as postagens do blog com os vídeos de nossos webinares anteriores!

Achou interessante?
Compartilhe este convite com seus colegas por Email, Linkedin, Twitter, Facebook e outras redes sociais!

Webinar – Do Modelo TO BE para a Automação – o que é preciso repensar sobre o processo

Neste webinar, apresentado por Kelly Sganderla em 25/08/16, compartilhamos nosso expertise e experiência sobre a importância de realizar um redesenho tecnológico do TO BE, considerando aspectos importantes sobre a visão de processo e visão sistêmica da Solução.

Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

Os slides utilizados na apresentação também estão disponíveis no SlideShare:
http://www.slideshare.net/iProcessBPMeSOA/webinar-iprocess-do-modelo-to-be-para-a-automao-um-repensar-sobre-o-processo

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: Para automatizar processos e adotarmos um BPMS, temos uma etapa que é a escolha da ferramenta BPMS. Devemos ter ações paralelas para definir junto ao cliente qual BPMS a ser adotado, caso o cliente não tenha definido qual a ferramenta a utilizar? Que dificuldades afetam o projeto (redesenho e automação) na escolha da ferramenta?
Certamente uma etapa importante na automatização de processos é a escolha de uma da suíte de BPM (BPMS). Dificilmente, porém, a organização irá adquirir um BPMS para automatizar um processo específico, pois este tipo de ferramenta é uma plataforma para automação e controle dos processos da organização. A escolha da plataforma para a gestão de processos é uma decisão corporativa. Cada solução disponível no mercado tem seus pontos fortes e fracos, e seus recursos precisam ser avaliados em relação às necessidades da organização, como sua estrutura, cultura organizacional e planos atuais e futuros para os processos da empresa. A escolha da ferramenta pode impactar diretamente no projeto de automação, pois de acordo com os recursos e funcionalidades disponiveis no produto, o redesenho tecnológico do processo pode mudar.
A iProcess Education lançou recentemente um Kit de Avaliação de plataformas de BPM com vídeo aulas e planilhas de templates para comparação e avaliação de aderência de produtos a centenas de requisitos que precisam ser considerados nesta avaliação, entre as quais os recursos que o produto disponibiliza para o desenvolvimento da automatização do processo.
Para saber mais, visite a página: www.iprocesseducation.com.br/avaliacao_plataformas_BPM

 

Pergunta: Trabalhar o TO-BE significa custo, para empresa como o todo, ainda mais como o TO-Be tecnologico que aparentemente gera mais custo. Tem algum valor de beneficio entre o TO-BE e o TO-BE tecnologico?
A melhoria de processos não deve ser vista como um custo, mas como um investimento. Assim, não devemos avaliar o valor e os benefícios do redesenho de processos pelo custo deste trabalho, e sim pelo seu potencial de retorno do investimento. O redesenho tecnológico possibilita criar uma nova visão de futuro (TO BE) que ao ser comparada com a situação atual nos apresentará que ganhos teremos no processo em termos de redução de custos da sua execução, redução da duração do processo e melhoria na qualidade e produtividade. Isto é fundamental para o cálculo do ROI do projeto – um tema que trabalhamos muito fortemente nos nossos treinamentos do Ciclo BPM.

 

Pergunta: Se a TI não conhece a ferramenta a empresa auxilia neste trabalho a 4 mãos?
Se a equipe que fará o desenvolvimento para a automação do processo não conhece a ferramenta, há um risco bastante elevado de definições sobre o processo não serem viáveis de automação com o produto escolhido, ocasionando necessidades de mudança do processo e do escopo de trabalho durante o projeto – o que no final das contas poderá aumentar o seu custo de implementação. Neste caso, o ideal é contar com um apoio do fabricante ou de consultoria especializada que conheça bem o produto, para realizar este redesenho tecnológico do TO BE.

 

Pergunta: Eu gostaria de rever os slides que falam sobre analista de negócio e de TI agora do final da apresentação.
Os slides utilizados na apresentação estão disponíveis no link do slideshare acima e você também pode rever esta parte da apresentação no vídeo gravado!

10 pontos chave a considerar na hora de estimar um projeto com BPMS

Com um largo know-how em automação de processos e já tendo realizado algumas centenas de implementações nas mais diversas ferramentas, a estimativa de esforço para a automação de um processo é quase que uma prática diária na iProcess.

Como somos muito questionados sobre como fazemos isso, e neste artigo indicamos algumas diretrizes para auxiliar nossos clientes a fazer avaliar a sua estimativa.

1. Estimativa de implementação é somente uma parte da Estimativa do Projeto

Falaremos neste artigo sobre o esforço direto de um programador para pegar um processo desenhado e detalhado funcionalmente e implementa-lo em uma ferramenta de BPMS. Contudo, isso costuma ser menos da metade do esforço de um projeto!
Um projeto de automação bem elaborado precisa que se faça o levantamento do processo, sua modelagem para automação, projeto técnico, roteiro de testes, preparação de dados de sistemas legados, execução e ajustes da sua validação, homologação com o usuário, elaboração de documentação, elaboração de planos de instalação, instalação em ambiente de homologação e produção, acompanhamento em produção, suporte dos primeiros dias, gerência de projeto, gerência de configuração, gestão de requisitos, entre outros!
Evidentemente que tudo isso é um mundo a parte, e dependerá das características do processo, da cultura da organização e do seu processo de desenvolvimento. Contudo, são atividades que não podem ser desprezadas, pois garante a qualidade do resultado da entrega da automação.

2. Estimativa de Processos não é Estimativa de Software

A estimativa de software convencional utiliza métodos como Pontos de função (PF) ou Unidades de Casos de Uso (UCP) para realizar a estimativa de esforço. São técnicas que utilizam como referência a complexidade da interface de usuário. Na automação de processos é diferente, pois a complexidade está ligada diretamente aos elementos BPMN que compõem o seu processo e a complexidade em implementá-los​ no BPMS adotado​. Logo, estas técnicas não tem aplicação direta para estimar esforço de automação de processos.

3. Você deve conhecer o seu processo (ou projetar como ele deveria ser)

Não tem jeito: você não tem como estimar um processo que você não​ o​ conhece. O esforço de implementação de um processo está ligado diretamente às suas características, elementos necessários e respectivas complexidades. Logo, você precisará levantar o processo.
Caso não haja esta possibilidade, você deverá inferir esta complexidade e assumir o risco no momento da automação de ter que realizar ajustes para mais ou para menos.

4. Cada ferramenta de automação possui uma produtividade diferente

Não existe um número mágico que traga o esforço de implementação de um processo em todas as ferramentas. Cada ferramenta possui suas peculiaridades: algumas são mais produtivas, outras são mais completas e outras são mais complexas. Em algumas uma atividade humana é feita com muita facilidade, mas uma integração com um webservice ou um banco de dados dá muito trabalho.
Por isso, você deve antes de mais nada escolher a ferramenta em que será feita a automação para somente depois avaliar o seu esforço.

5. Identifique o modelo de dados do Processo

O que diferencia uma instância de processo de outra em execução são os dados em que elas manipulam. Cada processo tem atrelado a si um modelo de dados específico, que determina quais informações são manipuladas, incluídas ou consultadas ao longo do processo.
A complexidade do modelo de dados de um processo está ligado diretamente ao número de informações que são manipuladas e as suas características: se existem dados mestre-detalhe, se é feita a manipulação de arquivos, entre outros fatores.
A estimativa de esforço deve levar em consideração este montante e complexidade para projetar o esforço de manipulação destas informações ao longo do processo.

6. Identifique os elementos de processo que são implementados na sua ferramenta

O esforço de automação de um processo está ligado diretamente aos elementos que ele possui. Um processo com 2 atividades humanas e 2 gateways tende a ser 4x mais rápido de ser desenvolvido do que um processo com 8 atividades humanas e 8 gateways por exemplo.
A estimativa de automação de processos está ligada diretamente ao número de elementos que o seu processo possui, e é por isso que você deve conhecê-lo para poder estimá-lo.

7. Identifique os fatores de complexidade de cada elemento

Contudo, somente identificar os elementos não é o suficiente, pois um mesmo elemento pode ter uma implementação fácil ou complexa. Por exemplo, você pode ter
um gateway que somente testa se na atividade anterior houve uma aprovação ou reprovação (simples) ou um gateway que valida uma complexa regra de negócio;
Uma integração que passa o número do CNPJ e recebe o nome do cliente ou o cadastro de uma nota fiscal ​e seus itens ​em um ERP;
Uma atividade humana que informa ao solicitante que seu pedido chegará em 20 dias ou uma atividade distribuída para o ator mais produtivo entre uma série​,​ que possui um SLA rígido, controle de prazos e alertas e escalonamento caso a mesma não seja realizada em até 3 dias úteis antes do prazo final do processo.
Para mapear estas condições, você deve criar critérios de complexidade e atribuir um esforço para cada nível de complexidade.

8. Classifique o seu processo de acordo com estes fatores

Uma vez entendido os fatores para a projeção de complexidade de implementação de um processo, o processo escolhido deverá ser classificado: seus elementos contados, a complexidade de cada elemento avaliada e o esforço da sua implementação calculado.

9. O desenvolvimento das telas das atividades são parte significativa do esforço

​Mesmo com estes cuidados, as coisas não são tão fáceis como parecem, e apesar de estarmos falando de desenvolvimento de processos, eles possuem um componente importante chamado de interface de usuário das atividades humanas.
Na iProcess estimamos que o desenvolvimento de interfaces exige em média um esforço de 40% a 70% do esforço de desenvolvimento de um processo e depende muito dos recursos visuais e da linguagem de programação que cada ferramenta disponibiliza para a implementação das suas interfaces.
Existem soluções de BPMS cuja interface é “engessada” (no sentido que você define poucas coisas em termos de layout e comportamentos) enquanto que outras você pode fazer tudo o que qualquer linguagem moderna de programação web permite.
Por isso, você deve também mapear a complexidade de desenvolver cada interface e realizar uma contagem exclusiva para as mesmas.

10. Elabore uma planilha para calcular o esforço

Se você chegou até aqui, deve ter visto que são muitas variáveis e informações a serem consideradas. Em processos de complexidade média ou alta, com dezenas de atividades e subprocessos, levantar e calcular todas estas informações à mão torna-se quase impossível.
Logo, sugerimos que você elabore uma planilha com todos estes cálculos e utilize-a como ferramenta para realizar a estimativa do seu processo.

Activiti x Camunda BPM: o peso da comunidade

O mercado de soluções para BPM está repleto de produtos, comerciais e também software livre.

Entre as ferramentas BPMS disponíveis no mercado no formato de código aberto, dois produtos têm um passado em comum: o Activiti e o Camunda BPM.

O Camunda BPM surgiu em 2013, criado a partir de uma bifurcação do software Activiti da Alfresco. No artigo “Camunda Forks Alfresco Activiti”, Charles Humble da InfoQ explica o nascimento do Camunda BPM e apresenta também uma divergência de opiniões da época a respeito do futuro das duas ferramentas.

Na prática, de uma solução surgiu a outra, e ambas seguem em constante evolução. Este artigo vem comparar o peso das duas comunidades.

Para essa comparação, tivemos que elencar algumas características principais sobre a ferramentas e suas comunidades, e foram elas:

Colaboração – Quantidade de pessoas envolvidas ativamente no desenvolvimento do código-fonte
Atualização – Frequência de melhorias realizadas no software (commits and releases)
Documentação – Facilidade de acesso e diversidade de documentos disponíveis
Integração – Possibilidade de integração com outras tecnologias e exemplos e tutoriais para tal
Relacionamento – Atividade nos fóruns para desenvolvedores

Para essa pesquisa, utilizamos a leitura das documentações disponíveis, seguindo pela busca dos códigos fontes nos repositórios e principalmente de exemplos de utilização e tutoriais. Fizemos algumas estatísticas com base nos contribuintes do código fonte, frequência das últimas alterações e quantidade de desenvolvedores que acompanham as evoluções das duas ferramentas.

Seguimos observando as perguntas realizadas nos fóruns para desenvolvedores e principalmente na existência e qualidade das respostas, acompanhamos também as redes sociais de cada ferramenta e finalizamos observando as questões encontradas na internet de um modo geral (uma boa parte no site StackOverflow).

O resultado da pesquisa gerou insumos suficientes para elaborarmos um quadro comparativo que segue. O quadro permite observar pequenas diferenças na participação da comunidade.

Seguindo a vertente do software livre, lançaremos uma série de artigos falando mais detalhadamente sobre algumas ferramentas disponíveis, como JBPM, Intalio e outras incluindo também o Activiti e Camunda BPM, porém com um enfoque diferente, comparando a arquitetura de BPMS de cada solução.

Fontes da pesquisa:
http://camunda.org/
https://github.com/camunda
https://groups.google.com/forum/#!forum/camunda-bpm-dev
http://activiti.org/
https://github.com/activiti
http://forums.activiti.org/forums/activiti-developers
http://www.infoq.com/news/2013/03/Camunda-Forks-Activiti

Na hora de escolher a plataforma de BPM…

"Mas o que é mesmo que nós precisamos?"

O fato da iProcess ser uma consultoria com longa história, construída no estudo e implementação de soluções para processos através de tecnologias como workflow e BPMS, nos coloca em uma posição bastante interessante em relação ao mercado: entendemos como as soluções de automação funcionam, como é a sua arquitetura, o que as faz iguais e diferentes.

Isso possibilita dizermos então que nossa ferramenta favorita é, na verdade, a solução que mais se encaixa nas necessidades organizacionais, financeiras, culturais e tecnológicas dos nossos clientes.

É por isso que, quando as pessoas nos comentam que estão testando as soluções X, Y e Z e nos perguntam qual indicaríamos, ou qual é o melhor, a nossa resposta é “depende”. Depende porque, em nossos anos de experiência automatizando processos, chegamos à seguinte conclusão: não é uma questão de qual software é melhor comparado a outro software, mas qual é o software que melhor se encaixa às reais necessidades da organização.

Descobrir a solução que apresenta a melhor relação de custo e benefício em BPM requer uma análise que vai além de verificar funcionalidades que uma tenha e a outra não. Ela passa por questões como:

      • “Qual o tamanho da organização em termos de usuários e sistemas que integram os processos de negócio, e qual a perspectiva de crescimento para os próximos anos?”
      • “Como a companhia está estruturada – ela existe em um local centralizado ou se espalha por diferentes locais e regiões? Qual o impacto disso nos usuários dos processos automatizados? Precisamos de um software que suporte multi-línguas e multi-moedas?”
      • “A infraestrutura de TI da organização já tem um direcionador de plataforma tecnológica que pode impactar nesta decisão?”
      • “O que mais a organização precisa deste software além da simples automação dos passos a serem executados no processo automatizado? Monitoramento e ação em tempo real? Arquitetura dos processos de negócio? Ferramentas e metodologias de análise de processos? Posso ter isto em apenas um software ou precisarei de múltiplas ferramentas para cobrir meu ciclo de melhoria contínua de processos?”
      • “Que tipo de processos planejamos automatizar? Quantos? Com que frequência eles são executados, e o software está preparado para gerenciar a quantidade de instâncias?”
      • “O processo que modelamos é o processo que será executado, ou precisa ser transformado em outras linguagens antes de rodar, como do EPC para BPMN, ou do BPMN para BPEL, ou ainda de uma notação gráfica para algo que só o BPMS entende? Consideramos isto aceitável?“
      • “Que outras soluções de software precisarão ser integradas: ERP, BRM, BAM, ECM, etc?”
      • “Que tipo de suporte o fornecedor da solução está preparado para oferecer enquanto desenvolvemos a automatização do processo e após a implantação?”
      • “Onde encontramos profissionais que conheçam o software com a profundidade suficiente para implementar as complexidades naturais dos processos, que vão além do simples workflow de sequência de atividades?”
      • “O quão sólida é a empresa por trás do software – quais os riscos do mesmo ser adquirido por outra empresa gerando mudanças e mais mudanças na plataforma?”

Você percebe que dependendo da organização, o peso e a resposta a essas perguntas podem gerar avaliações bem diferentes?

São tantas questões que precisam ser consideradas neste processo de escolha – e que vão além da simples comparação de funcionalidades, que já consolidamos uma planilha de avaliação com centenas de critérios a avaliar (e que inclusive faz parte do nosso treinamento e pacote de consultoria em Seleção de Plataformas de BPM).

É claro que boas opiniões de quem já usa a ferramenta são essencialmente importantes. É parte do processo de escolha de uma plataforma, mas pode não ser a resposta para a organização.

Há tanto software de BPM sendo oferecido no mercado, que recomendamos sempre que antes de escolher uma ou outra solução para “testar”, por sorte ou porque alguém disse que era boa, considere as reais necessidades da organização – e então escolha aquelas sobre as quais realmente vale a pena investir tempo na avaliação.

Nossa equipe já atuou em projetos utilizando diferentes soluções de BPM. Todas elas são muito boas. É apenas uma questão de entender quais as verdadeiras necessidades da empresa.

Veja mais artigos sobre o tema da escolha de plataforma de BPM publicados aqui mesmo no blog da iProcess:

 


Entendendo o Quadrante Mágico do Gartner para iBPMS

Todos os anos o Gartner, empresa americana de pesquisa e assessoria em tecnologia da  informação, analisa o mercado de tecnologia para mais de 60 tipos de diferentes de software – entre eles as plataformas tecnológicas para BPM. Os relatórios anuais buscam oferecer uma análise qualitativa do mercado, suas tendências, maturidade e participantes, gerando insumo importante para avaliar as soluções oferecidas, e tem sido uma importante ferramenta para apoiar a avaliação e escolha de tecnologia de suporte às iniciativas da gestão por processos.

O relatório Gartner para o mercado de BPMS/iBPMS

Até 2011, o Gartner avaliava todas as soluções para controle automatizado de processos como “BPMS” (Business Process Management Suites). Em 2012, a organização vislumbrou uma tendência de negócio que implicou em uma nova oportunidade de utilização para estas ferramentas. No relatório “The Trend Toward Intelligent Business Operations”, a instituição relata que gestores têm sido requisitados a tomar decisões mais rápidas e assertivas “fazendo menos com mais” em um contexto de negócio dinâmico e em constante mudança. Assim, para superar o desafio criado pela necessidade de melhorar a visão organizacional sobre suas operações e ambiente de negócios, as organizações tem buscado desenvolver a capacidade de tornar suas operações de negócios mais inteligentes, integrando análise aos seus processos e às aplicações que os sustentam.

Assim, o Gartner identificou a operação inteligente de negócios (ou IBO, Intelligent Business Operations) como um novo cenário de uso para as suítes de BPM. Mas para atender estas necessidades, estes produtos precisam evoluir a uma nova geração de software, que a organização chamou de iBPMS (Intelligent Business Process Management Suite).

De acordo com o Gartner, um iBPMS deve conter todas as 10 capacidades chave a seguir:

  • Um motor de orquestração da execução do processo para guiar o progresso do trabalho estruturado ou não estruturado.
  • Um ambiente de composição baseado em um modelo para o desenho do processo, suas atividades e artefatos
  • Gerenciamento da interação com o conteúdo para suportar o progresso do trabalho baseado em mudanças no próprio conteúdo do processo (como documentos, imagens e áudio)
  • Gerenciamento da interação humana para possibilitar que as pessoas possam interagir naturalmente com os processos em que estão envolvidas
  • Conectividade entre processos e recursos que controlam, como pessoas, sistemas, dados, ocorrência de eventos, objetivos e indicadores de desempenho (KPIs)
  • Análise ativa (em alguns casos denominado continuous intelligence, ou ”inteligência contínua”) para monitorar o progresso das atividades, analisar atividades e mudanças no processo e o que mais estiver envolvido
  • Análise sob demanda para possibilitar suporte à decisão ou decisões automáticas baseadas em análise preditiva ou otimização tecnológica
  • Gestão de regras de negócio pra guiar e implementar agilidade ao processo e garantir aderência ao negócio
  • Gestão e administração para monitorar e ajustar aspectos técnicos do iBPMS
  • Um registro/repositório para busca e reuso de componentes de processos.

Com esta revisão, o número de soluções avaliadas mudou sensivelmente de 27 em 2011 para 13 fornecedores em 2012. Em 2014, o relatório aponta 14 soluções avaliadas.

Em geral, os relatórios do Gartner Group são comercializados e requerem permissão para serem distribuídos.
O relatório do Quadrante Mágico para iBPMS de 2014 foi publicado pela instituição em março e pode ser obtido neste endereço: https://www.gartner.com/doc/2684315.

O Quadrante Mágico para iBPMS

Um dos principais componentes do relatório do Gartner é o Quadrante Mágico (ou MQ, de Magic Quadrant), que mostra as posições relativas dos concorrentes do mercado avaliado.

O Quadrante Mágico é um gráfico formado pelo cruzamento dos eixos horizontal e vertical, que formam quatro áreas. O eixo vertical representa a capacidade do produto de executar aquilo a que se propõe (hability to execute), enquanto o eixo horizonal representa o quão completa é a visão aplicada ao produto da empresa em relação a tecnologia (completeness of vision).

Para identificar a capacidade de executar de um produto, são avaliados critérios como:  a composição do produto ou serviço, a viabilidade da solução a longo prazo, o formato de vendas e precificação, capacidade de resposta ao mercado e concorrentes, execução mercadológica, experiência dos usuários e operações.

A completude de visão (completeness of vision) é medida através dos critérios de entendimento do mercado, modelo de negócio, estratégias de marketing, de vendas, de oferta do produto, de atendimento a segmentos de mercado, de distribuição geográfica e capacidade de inovação.

As áreas formadas pelo cruzamento desses eixos classificam as soluções em:

  • Challengers (desafiadores): Soluções com boa capacidade de execução mas que não agregam tanto em inovação;
  • Leaders (líderes):Soluções que possuem maior grau de inovação e entregam o que prometem.
  • Niche Players (fornecedores de nicho de mercado): possuem produtos em geral focados em um nicho específico, apresentando baixo nível de inovação e de entrega.
  • Visionaries (visionários): soluções que possuem alto nível de inovação mas menor capacidade de entregar o que se propõem.

Através do gráfico fica mais fácil realizar uma análise comparativa das soluções, uma vez que quanto mais para cima e para a direita, melhor está posicionada no quadrante. Além do quadrante, porém há outras informações importantes nestes relatórios que precisam ser levadas em conta:

Observe o progresso da solução através dos relatórios.
Os relatórios são emitidos anualmente, e possibilitam assim identificar as soluções melhor posicionadas, mas também, comparando-se os quadrantes dos relatórios anteriores, identificar o quanto o fabricante está investindo em estabilizar ou melhorar sua solução.

Entenda o que levou ao posicionamento de cada solução no quadrante.
Além do gráfico, cada solução é descrita pelo Gartner apontando seus pontos fortes e pontos de atenção, que podem fazer a diferença em relação às expectativas do cliente.

Considere a presença da empresa no Brasil.
Os relatórios do Gartner analisam soluções com perfil global, o que muitas vezes não se reflete no mercado brasileiro. Muitas das empresas avaliadas pelo Gartner têm pouca (ou nenhuma) base instalada no Brasil, o que pode implicar em dificuldades para se obter suporte e atenção do fornecedor durante a execução dos projetos – sobretudo quando começam a surgir as complexidades dos processos.

Existem boas soluções além do MQ.
Muitos outros BPMS e iBPMS existem além dos que são mostrados no Quadrante Mágico, em geral porque são fornecedores de menor porte, ou porque são novos no mercado e possuem uma base de clientes em produção reduzida, ou porque não atingiram todos os critérios da nova classificação. No Brasil sabemos que há soluções muito boas de BPM que não foram avaliadas pelo Gartner. Entenda os critérios de corte relatados pelo Gartner e considere se podem ser aplicados à sua situação.

Fazendo uma boa escolha de aquisição de BPMS/iBPMS

O relatório do quadrante mágico do Gartner é uma ferramenta muito interessante de análise comparativa de soluções oferecidas no mercado, mas uma aquisição segura não deve se restringir a esta avaliação.
Confira estes artigos para entender mais sobre os pontos de atenção a serem considerados na hora de escolher que solução adquirir para a organização.

Está avaliando uma plataforma de BPM para sua organização? Conte com a experiência da iProcess!
Saiba como podemos ajudá-los através de:
- Workshop de Seleção de Plataforma de BPM
- Consultoria de apoio à Seleção de Plataforma de BPM.

Gerenciando a execução de processos com (ou sem) um BPMS

A tecnologia é sem dúvida um dos aspectos que podem gerar melhor contribuição para agilidade e qualidade na execução dos processos de negócio.

Através de projetos para automatizar processos com um BPMS, fica mais fácil definir claramente um evento para iniciar o processo, possibilita que as informações fornecidas nas atividades de processo possam ser acessadas pelos próximos participantes, todas as etapas ficam registradas para acompanhamento e auditoria e a coleta de dados para alimentar indicadores de desempenho pode ser automática. Também unifica a forma como os processos são executados e controlados, já que a plataforma de um BPMS é feita justamente para possibilitar o gerenciamento de múltiplos processos da organização. Esses e outros benefícios de usar um BPMS para automatizar processos já foram discutidos aqui no blog em artigos como Benefícios da Automação de Processos e Automatização de Atividades.

Entretanto, automatizar em um BPMS não é para todo e qualquer processo. No artigo Automatizar o processo (ou não)? Eis a questão!, chegamos a discutir algumas características de processos que não são bons candidatos a serem automatizados, baseado em um caso real.

Existem outras formas de se controlar processos com suporte tecnológico, mesmo sem um BPMS:

  • Sistemas tradicionais: pode-se desenvolver um sistema tradicional, baseado em um determinado processo, que garanta que a sequência de atividades seja realizada como prevista. Em geral não apresenta muitos benefícios em relação à automatização com um BPMS, já que terá que desenvolver, além das telas de interação com os usuários, controles de estados (para garantir a sequência de atividades), armazenar dados específicos daquele tipo de processo de negócio, coletar indicadores, controlar autenticação de usuários vs. seu papel no processo (para que uma pessoa não faça o trabalho da outra) e disponibilizar recursos para acompanhar o processo e seu histórico – tudo funcionalidades que já são nativas do BPMS.
  • Ferramenta de gestão de projetos: Alguns processos tendem a ser melhor gerenciados como projetos. Neste caso, a sequência de atividades, suas dependências e os papéis responsáveis são transformados em uma EAP (Estrutura Analítica de Projeto) e cada nova instância do processo se transformaria em um projeto gerenciada e executada em uma ferramenta de gestão de cronogramas. Com isso é possível gerenciar os recursos e prazos e monitorar o andamento da execução do processo. (A iProcess faz isso, por exemplo, com o processo de desenvolvimento de software: temos nosso processo de desenvolvimento formalmente modelado em BPMN, mas a cada nova “instância” o GP gera uma EAP baseada no processo e passa a executá-lo em nossa ferramenta de gerenciamento de projetos).
    Este tipo de controle funciona melhor para alguns processos em que a sequência de atividades precisa ser flexibilizada (as atividades do processo passam por uma adequação às necessidades da instância), mas requer maior envolvimento do gestor e constantes auditorias para confirmar que os processos estão sendo executados conforme o modelo do processo. Muitas dessas ferramentas permitem exportar dados de execução que podem ser utilizados em uma aplicação de relatórios para monitorar o desempenho do processo.
  • Aplicações de gestão de atividades: Algumas ferramentas como Redmine e Jira permitem determinar uma sequência de atividades baseada em uma máquina de estados criando dependências entre elas. O administrador “configura” a sequência de atividades baseada no fluxo de processo, e as instâncias obedecem a sequência, que é controlada pelo estado do mesmo. Funciona bem para processos de workflow puramente humano e geralmente possuem alguns relatórios para monitoramento, mas não permitem acionar serviços de outros sistemas para buscar dados de algum cadastro existente, por exemplo.
  • Software de pacote: Existem processos que já são considerados commodities. Por exemplo, existe pouca variação em processos de help desk (atendimento a cliente) ou de empréstimo de livros/obras (biblioteca). Para estes casos é comum adquirir um software de pacote que já possui um processo “embutido”. Em alguns casos este tipo de software permite customizações para se adequar ao processo da empresa, mas em geral é a empresa que acaba adequando seu processo ao que a solução possibilita fazer.
  • Aplicação de rastreamento do processo físico: Em alguns casos, os processos precisam continuar existindo fisicamente, através de “pastas de documentos”. Apesar do conteúdo digital já ser uma realidade (prova disso é a Nota Fiscal Eletrônica), muitas organizações ainda demandam que processos baseiem-se em documentos físicos, de papel. Para estes casos, a organização pode manter uma aplicação de histórico no qual, cada vez que um participante vai passar a pasta física “para frente”, ele registra que está finalizando a atividade e para onde os documentos do processo estão indo, possibilitando rastrear a execução do processo.

Na maior parte dos projetos de implantação de processos, entretanto, os benefícios em utilizar um BPMS para controlar, gerenciar e monitorar a execução apresentam um retorno muito melhor para o investimento.

 


Aprenda a analisar processos de negócio para a automatização com a equipe da iProcess, que tem mais de 13 anos de experiência em soluções para gestão de processos!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

Arquitetura típica de BPMS

Os BPMS (Business Process Management Suite, ou System) são uma categoria de software com a capacidade de coordenar a execução de processos de negócio.

Apesar de apresentarem variações, podendo conter ou não alguns componentes, os BPMS essencialmente apresentam uma arquitetura básica comum:

Arquitetura típica de um BPMS (iProcess, 2009/2013)

 

Modelagem

O componente de modelagem é a ferramenta que auxilia o analista a documentar o processo de negócio.

Podem ser utilizadas diferentes notações pela ferramenta de modelagem, embora a mais comum seja BPMN, pela sua facilidade de transformação no modelo que poderá ser implementado tecnicamente para a automação.

Muitas ferramentas dispõem na ferramenta de modelagem recursos como documentação detalhada, integração com a estrutura hierárquica organizacional, funcionalidades de apoio à análise e simulação dos processos.

Desenho Técnico

O componente de desenho técnico é a área de trabalho do desenvolvedor, que irá implementar o processo modelado.

Em alguns BPMS, a ferramenta de desenho técnico pode ser a mesma ou estar integrada à de modelagem. Em outros casos, as ferramentas podem ser distintas.

A ferramenta de desenho técnico pode implementar o processo na mesma notação do processo modelado (em geral BPMN) ou eventualmente poderá requerer uma transformação para outra notação ou linguagem, como BPEL por exemplo.

Motor de Processos (Process engine)

O motor de processos é o componente onde a mágica do controle e execução do processo automatizado acontece.

Quando o modelo do processo implementado está pronto, ele é disponibilizado para o motor de processos. As informações do modelo são armazenadas na base de dados da ferramenta, que passa a usá-las como base para controlar cada etapa da execução.

O motor de processos é responsável por:
  • interpretar o modelo do processo,
  • controlar a execução de acordo com o modelo do processo,
  • interagir com os participantes humanos do processo,
  • invocar e integrar-se com aplicações externas,
  • manter automaticamente atualizada a base de dados de execução do processo.
Quando uma nova instância do processo é disparada, o motor de processos interpreta a próxima etapa, identificando quem deve executar, que dados devem ser fornecidos como entrada, que dados são esperados como saída da sua execução.

O framework de tarefas humanas é o responsável por gerenciar as atividades executadas por usuários, disponibilizando as informações configuradas para a tarefa ao ator responsável através de mecanismos como a lista de trabalho (ou lista de tarefas). Quando um usuário finaliza sua atividade, o framework de tarefas humanas repassa o resultado ao motor de processos, que dá seguimento à execução do processo.

O framework de integração é o responsável por gerenciar o acionamento de mecanismos automáticos, executando serviços, APIs ou scripts de busca ou envio de dados para sistemas de informação como sistemas legados, ERPs ou serviços de agentes externos. Em geral apresenta melhor desempenho quando estas integrações são gerenciadas através de uma arquitetura SOA (para saber mais, leia os artigos “SOA – Arquitetura Orientada a Serviços” e “SOA – A relação com BPM no sucesso da automação de processos“).

Alguns produtos dispõem também de um framework de regras, que gerencia a invocação de regras de negócio. Neste caso, as regras de negócio são mantidas em uma solução denominada BRMS (Business Rules Manager System), viabilizando que gestores do negócio tenham controle sobre os parâmetros que definem a regra, cabendo ao processo apenas executá-la para obter o resultado.
(Leia mais sobre BRMS no artigo Business Rules e a Dinâmica do Negócio)

Repositório de documentos

É natural que em muitos processos de negócio haja o envolvimento de documentos.
Documentos podem ser o gatilho de um processo de negócio, bem como atividades no decorrer da execução do processo podem requerer que documentos sejam associados a ele.

Assim, a maior parte das soluções de BPM disponibilizam mecanismos para vincular documentos a processos em execução, mas elas podem se diferenciar basicamente de duas formas. Muitas soluções viabilizam mecanismos simples de vínculo de documentos, em que os arquivos são armazenados no sistema de diretórios do servidor e oferecem formas de interação simples (anexar, abrir, remover).
Outras soluções mais robustas incorporam ferramentas mais completas de gerenciamento de conteúdo – ECM (Enterprise Content Management), contemplando uma gestão plena sobre o documento, com funcionalidades como versionamento, busca por metadados ou por conteúdo, gerenciamento de validade e expiração, controle de acesso ao conteúdo, entre outros.

Dados de Desempenho e Monitoramento

Sem monitoramento não há gerenciamento. Assim, todo BPMS mantém uma base de informações da execução de cada instância de processo que pode ser usada na geração de dados de desempenho do processo.

Os dados de desempenho são utilizados por ferramentas que possibilitam o monitoramento através de indicadores reportados em relatórios ou painéis gráficos.

A forma como estes dados são disponibilizados para o monitoramento também pode apresentar variações entre as soluções disponíveis no mercado.

Enquanto algumas soluções disponibilizam relatórios tabulares e gráficos para acompanhamento dos indicadores (muitas vezes inclusive com alto grau de customização e personalização), outras ferramentas apresentam componentes mais robustos de Monitoramento Ativo – BAM (Business Activity Monitoring), que possibilitam não apenas visualizar indicadores mas interagir com processos problemáticos.

 

Com tantas variações, como escolher o BPMS certo para minha organização?

Selecionar um BPMS para uso em uma organização passa por compreender a robustez dos componentes disponibilizados pelas soluções de cada fornecedor e avaliá-las frente às necessidades atuais e futuras da organização, levando também em conta aspectos econômicos e culturais. Leia o artigo “A difícil tarefa de escolher uma plataforma BPM para uma organização” para compreender as complexidades envolvidas nesta escolha e estruturar um projeto de seleção.