Arquivos da Tag: processo de negócio

Um guia para iniciar estudos em BPMN (II): Gateways

-
(43) Comentários

No artigo anterior, iniciamos o estudo da notação BPMN apresentando os elementos task e sequence flow, utilizados para representar a sequência lógica de atividades a serem executadas para a realização do processo. Neste artigo estudaremos um novo elemento de fluxo.

Gateways são os elementos de BPMN responsáveis por controlar iterações do fluxo, criando caminhos alternativos ou paralelos no mapeamento do processo ou unificando fluxos para continuação em uma mesma sequência de atividades.

Gateways são elementos chave na modelagem de processos de negócio, pois permitem descrever não apenas o “dia feliz” do processo, em que as atividades acontecem sempre da mesma maneira ou na mesma sequência, mas prever possíveis exceções conhecidas do negócio, ou beneficiar a duração do processo através da paralelização de atividades.

O gateway é conectado ao fluxo através de setas de fluxo de sequência e é representado visualmente por um  losango. O símbolo interno do losango identifica a interpretação lógica representada.

 

Gateway exclusivo (Databased Exclusive Gateway)

Representa uma condição de fluxo exclusiva, em que apenas um dos caminhos criados a partir do gateway será seguido, de acordo com uma informação a ser testada.

Este gateway pode ser representado visualmente como o losango vazio ou com um marcador de “x”.

Quando o processo em execução atingir este gateway, o processo deverá verificar a condição indicada, e apenas uma das saídas do gateway dará seguimento. Semanticamente, este gateway funciona como um “ou”, já que ou um ou outro caminho será seguido – nunca mais de um.

Os conectores de sequência de saída deste gateway podem apresentar descrições que ajudem a identificar qual a condição para que o fluxo siga por aquele caminho.

Além de realizar separação de fluxos, o gateway também pode unificar fluxos distintos em uma única sequência de atividades. Neste caso, o gateway exclusivo implica no entendimento que, dos caminhos que convergem a ele, o primeiro que chegar dará continuidade no fluxo do processo.

No exemplo acima, o gateway “Resultado da avaliação” testará o resultado da atividade anterior. Se na execução da atividade “Avaliar artigo” o usuário aceitar o conteúdo, o fluxo seguirá pela saída superior “Conteúdo aceito”, e as atividades “Realizar revisão final do artigo” e “Publicar artigo” serão realizadas. Se o usuário rejeitar o conteúdo, o fluxo seguirá pela saída “Conteúdo rejeitado”, e apenas a atividade “Cancelar artigo” será realizada. Por fim, se o usuário optar por requerer ajustes, o fluxo seguirá a sequência “Requer ajustes”, iniciando a atividade “Ajustar artigo”. Ao terminá-la, note que o fluxo seguirá novamente para a atividade de “Avaliar artigo”. Ainda no exemplo acima, note a utilização do gateway exclusivo para convergir dois dos fluxos criados. Isto garante que a atividade “Comunicar partes interessadas” só aconteça depois que a tarefa “Publicar artigo” ou a tarefa “Cancelar artigo” for executada, de acordo com o fluxo iniciado pelo gateway anterior.

 

Gateway paralelo (Parallel Gateway)

A paralelização de trabalho em um diagrama BPMN é possível com a utilização do gateway paralelo. Este gateway representa a divisão de um fluxo em dois ou mais que serão executados paralelamente. Todos os caminhos que saem deste gateway são executados.

Este gateway é representado visualmente como o losango com um marcador de “+” dentro dele.

Semanticamente, este gateway funciona como um “e”, já que um e outro caminho serão executados.

Quando este gateway é utilizado para realizar a convergência de fluxos, ele garantirá que todos os fluxos paralelos sejam concluídos, chegando até ele antes de dar continuidade ao fluxo de saída.

No exemplo acima, o primeiro gateway paralelo produz dois fluxos que serão executados paralelamente. Enquanto a tarefa “Escrever artigo” é realizada, as atividades “Selecionar imagens” e “Tratar imagens” também podem ser executadas. Ainda no exemplo acima, o segundo gateway faz a convergência dos fluxos, garantindo que a tarefa “Realizar diagramação” só seja executada depois que “Escrever artigo” e “Tratar imagens” tenham sido finalizadas.

 

Gateway inclusivo (Databased Inclusive Gateway)

Representa uma condição de fluxo inclusiva, em que pode haver uma combinação dos caminhos criados a partir do gateway, de acordo com uma informação a ser verificada.  Este gateway é representado visualmente como o losango com um marcador de círculo dentro dele.

Quando o processo em execução atingir este gateway, o processo deverá avaliar a condição relacionada, e uma ou mais das saídas do gateway poderão dar seguimento.

Semanticamente, este gateway funciona como um “e/ou”, já que o caminho a ser seguido pode ser um e/ou outro, de acordo com as informações e a lógica do negócio.

Quando este gateway é utilizado para realizar a convergência de fluxos, ele garantirá que todos os fluxos que estiverem em execução sejam concluídos, chegando até ele antes de dar continuidade à sequência de atividades.

No exemplo acima, o gateway “Documentos necessários” testará o resultado da atividade anterior. Se na execução da atividade “Identificar documentação necessária” o usuário identificar a necessidade de um, dois, ou três dos documentos requeridos, cada um dos fluxos será executado. Por exemplo, se para um processo em execução for identificada a necessidade da Negativa civil e Negativa criminal, mas não a de débitos, o processo seguirá pelas saídas “Negativa civil” e “Negativa criminal”, mas não pela “Certidão negativa de débitos”. Assim, as atividades “Anexar negativa civil” e “Anexar negativa criminal” deverão ser executadas. Em outro processo, pode ser possível que uma combinação diferente de documentos seja requerida. Ainda no exemplo acima, note a utilização do gateway inclusivo para convergir os fluxos criados. Isto garante que a atividade “Analisar validade dos documentos” só aconteça depois que todos os fluxos que forem iniciados pelo gateway anterior sejam executados, para então a atividade ser iniciada. No exemplo citado, a tarefa de analisar validade dos documentos só será iniciada depois que as tarefas “Anexar negativa civil” e “Anexar negativa criminal”, mas sem que ocorra a atividade “Anexar negativa de débitos”.

 

Algumas coisas importantes que devem ser observadas ao utilizar gateways:

  • Diferente dos diamantes dos tradicionais fluxogramas, os gateways em BPMN não são apenas pontos de divisão binária do fluxo. É possível (e muito mais vantajoso!) utilizá-los para realizar testes mais complexos do que o tradicional “sim/não”. Isto vale para todos os tipos de gateway nesta notação.
  • Nos gateways exclusivo e inclusivo, onde o fluxo é direcionado com base em uma condição, a informação a ser validada (para identificar que fluxo o gateway deve seguir) já deve ter sido obtida anteriormente no processo.
  • Embora a notação não coloque isto como uma regra obrigatória, é sempre uma boa prática descrever, nos conectores de sequência que saem destes gateways com decisão, que valor resultante da condição deve ser verdadeiro para que o fluxo siga por aquele caminho. (Veja nos exemplos aplicados como os conectores de sequência que saem dos gateways exclusivo e inclusivo possuem descrições associadas às suas linhas.) Isto deixará o diagrama mais claro para a leitura dos que venham a consultá-lo futuramente!

BPMN 2.0 possui outros tipos de gateways, como os baseados em eventos, por exemplo. estes gateways, entretanto, são utilizados em casos mais especializados (a partir do nível 2 – analítico, de acordo com a classificação de Bruce Silver).

Em nosso próximo artigo:
um estudo sobre os eventos e os principais gatilhos para início e fim de processos.

Confira todos os artigos deste guia de BPMN Nível 1:

Governança SOA – A chave para o sucesso de uma implantação

-
Comentar

Esse é o quinto de uma série de artigos do nosso blog que estão abordando o tema SOA, conceito antigo e atual que está enraizado nas atividades cotidianas da iProcess.

No primeiro post nós respondemos à pergunta: o que é SOA? Já no segundo definimos o que é um serviço e, no terceiro, trouxemos algumas estratégias que podem ser utilizadas na definição e na escolha de bons serviços candidatos.

O post seguinte abordou a relação entre SOA e BPM para garantir o sucesso da automação de processos. Neste artigo falaremos sobre Governança SOA como chave para o sucesso de uma implantação.

 

Objetivo: alinhamento com o negócio
A governança SOA consiste na definição de processos que garantam que os objetivos de SOA e da área de TI sejam atingidos. Para isso, a iniciativa deve:

  • definir um conjunto de instrumentos gerenciais que a instituição estabelece para garantir o sucesso e a sustentabilidade da iniciativa SOA;
  • definir claramente papéis e responsabilidades.;
  • avaliar a criação de estruturas destinadas a gerir a iniciativa de SOA.

Se os processos de governança não forem claros, a iniciativa SOA cairá em descrédito e rapidamente fracassará. Nesse sentido, seu principal desafio é gerencial e não técnico, e o ponto central sempre será o alinhamento dos processos com o negócio.

Os processos de governança
De acordo com a experiência da iProcess e a literatura disponível, podemos citar alguns dos principais processos de governança a serem criados. São eles:

  • capacitação das equipes em SOA;
  • identificação dos possíveis serviços a serem criados do ponto de vista corporativo (portfólio de serviços);
  • desenvolvimento de novos serviços;
  • análise do aproveitamento dos serviços existentes;
  • modificação/evolução dos serviços existentes;
  • desativação de serviços;
  • garantia do desempenho e estabilidade dos serviços em operação;
  • estimular/recompensar o reuso e a criação de novos serviços que tragam ganhos;
  • gestão da arquitetura corporativa (mesmo se a definição não precisa partir de SOA, SOA precisa disto);
  • planejamento das iniciativas SOA;
  • gestão de projetos SOA;
  • gestão da inovação;
  • definição de metodologia e padrões;
  • gestão dos acordos de nível de serviço (SLA).

Estrutura de trabalho
A governança também define, se necessário, as estruturas de trabalho para a sua equipe. Ela poderá conter um escritório SOA, uma área específica de arquitetura ou um núcleo de conhecimento. Também poderá centralizar a supervisão dos projetos SOA.

Outra opção é implantar um Centro de Excelência SOA. Trata-se de um comitê que conta com a presença de um conselho de especialistas no assunto (técnicos e de negócio) que auxiliam na tomada de decisão e encaminhamento das atividades de SOA.

Responsabilidades
Algumas das atividades que são responsabilidade da equipe de governança são:

  • gerência do repositório de serviços;
  • gerência do registro de serviços;
  • gerência da reutilização de serviços;
  • definição de boas práticas e metodologias;
  • treinamentos e atualização.

No caso de empresas que estão no estágio inicial de implantação de SOA, não é necessário pensar numa grande infraestrutura ou em soluções muito sofisticada para realizar as atividades de governança. A wiki corporativa ou mesmo planilhas podem ser suficientes para gerenciar e publicar as informações de governança.

Entre os documentos fundamentais a serem criados pela equipe de governança, sugere-se começar com a lista de serviços. Se essa informação não estiver disponível, existe um grande risco da não reutilização dos serviços já existentes.

SOA X Confiança
O sucesso de uma iniciativa SOA é baseada na confiança, já que quem consome os serviços conhece somente a sua interface e desconhece como ele foi implementado.

Nesse sentido temos um grande desafio de implantar SOA no Brasil, onde existe uma cultura muito forte da desconfiança no relacionamento entre desconhecidos. Se você não conhece tudo no detalhe, a premissa é desconfiar. É importante levar isso em consideração na hora organizar as ações de governança, inclusive criando alternativas para que isso não seja motivo de fracasso.

Estimando a duração de processos

-
(7) Comentários

Durante a análise de um processo, um dos trabalhos comumente realizados é a estimativa da duração do processo e suas atividades.

Apesar de ser um atributo importante para o entendimento de um processo, o tempo é uma informação  frequentemente avaliada de modo bastante displicente. A estimativa de tempo do processo acaba por ser realizada com base na percepção das pessoas em função do trabalho realizado, em geral na forma de “chute”. O resultado é uma avaliação que não condiz com a realidade – ou porquê foi superestimado, levando a crer que o processo possui um desempenho superior ao seu real potencial, ou subestimado, levando ao entendimento de que o processo não é eficiente pois está sempre atrasado.

Assim, uma avaliação de tempo realizada sem um estudo apropriado tende a impactar em diversas decisões equivocadas de melhoria, já que é um critério essencial para a avaliação do desempenho do processo.

Para se estimar o tempo envolvido na realização de um processo, é necessário compreender os conceitos de: duração, execução e trabalho.

Esquema de espera, execução, trabalho e duração da atividadeO trabalho, ou esforço,  é o tempo que o participante da atividade leva, efetivamente, na realização do trabalho a ser executado. Em uma tarefa, é possível que o trabalho seja realizado em partes antes da mesma ser considerada como concluída.  Por exemplo, o preenchimento de um formulário, a pesquisa de dados adicionais e a complementação do mesmo. Portanto, o tempo de trabalho é a soma do tempo dispendido em ações necessárias para que a tarefa seja concluída.

A execução é o tempo dispendido deste o início do trabalho até o mesmo ser concluído, inclusive o tempo entre as partes do trabalho. Por exemplo, do momento em que a pessoa iniciou o preenchimento do formulário, até o momento em que o mesmo foi completamente preenchido.

A duração é o tempo calculado desde o momento em que a tarefa esteve disponível para o participante responsável pela atividade. Por exemplo, desde o momento que o formulário foi deixado na caixa de entrada do participante,  mais o tempo de espera que levou para que a pessoa tomasse o formulário em mãos para iniciar o trabalho, até o seu completo  preenchimento.

Analisar a execução de um processo requer conhecer o tempo de trabalho, execução e duração de cada atividade envolvida.

Ao se calcular a duração de um processo, entretanto, não basta somar as durações das atividades envolvidas. Em um processo executado manualmente (ou seja, sem o controle por um BPMS), a duração é afetada também pelo handoff, que é a espera dispendida no transporte das informações do processo entre os participantes das atividades.

Esquema de espera, execução, trabalho e duração de processo manual

Um exemplo clássico do tempo de espera em transporte é, por exemplo, o tempo levado para que um formulário preenchido em uma atividade seja disponibilizado para o participante da próxima atividade.

Assim, a duração do processo é a soma da duração das atividades mais a soma das esperas entre atividades.

Estimar corretamente os tempos de um processo pode levar a várias ações de melhoria, como:

  • Definir níveis de serviço (SLA) realistas;
  • Definir indicadores que apoiem na identificação de gargalos em atividades, baseados no tempo de espera que uma atividade leva para ser iniciada;
  • Melhorar a distribuição de recursos para realizar as atividades de acordo com o volume de trabalho;
  • Melhorar as ferramentas utilizadas pelos participantes das atividades a fim de agregar velocidade à realização do trabalho;
  • Avaliar melhoria de desempenho simplificando-se ou removendo-se tempos de transporte (handoffs), ou mesmo buscando métodos de transporte mais eficazes.

A automatização de processos é uma alternativa para a busca de desempenho e solução para o transporte das informações entre as atividades. Em geral, há dois benefícios comumente identificados na automatização relacionados ao tempo de execução do processo:

  1. Eliminação do tempo de handoff, já que o motor do processo disponibiliza as informações ao próximo participante imediatamente após a conclusão da atividade anterior;
  2. Eliminação do tempo de espera em atividades executadas pelo sistema (como serviços de busca ou gravação de informações, por exemplo), já que a execução das mesmas é realizada imediatamente  quando a atividade é disponibilizada.

Esquema de espera, execução, trabalho e duração de processo automatizado

Seja executado por controles manuais ou automatizado com um BPMS, compreender a análise dos tempos na avaliação da duração de atividades e processos é uma ferramenta de gestão fundamental rumo à melhoria do desempenho dos processos da organização.

Leia mais sobre o cálculo da duração de processos no artigo complementar Estimando a duração de processos II – processos não lineares.

BPMN: Diferenças entre eventos de Link, Message e Signal

-
(37) Comentários

Um dos componentes mais poderosos, e mais difíceis de aprender em BPMN, são os eventos e seus gatilhos (triggers). A especificação BPMN descreve diversos tipos de gatilhos para os eventos, mas não esclarece como ou quando devem ser utilizados.

De forma especial, uma dúvida comum são as diferenças entre estes três gatilhos de eventos de BPMN: link, message e signal.

Link é um elemento de ligação que ajuda a abstrair conexões de sequência em um mesmo processo. Alguns profissionais sugerem que o link seja usado para dar seguimento do desenho do processo em outra página, como em uma documentação, por exemplo. Este é um uso possível, mas dado que a maioria das ferramentas de modelagem atualmente não faz paginação (o diagrama é desenhado em uma única área de trabalho) esta não é a única situação de utilização.

Uma das principais utilidades do evento de link, ao meu ver, é a de abstrair a sequência entre atividades que estão distantes no mapeamento, evitando conectores de fluxo de sequência longos que cruzem inúmeros outros.

No exemplo, os eventos de link com o mesmo nome conectam "virtualmente" pontos distantes do processo, fazendo com que após a atividade 'Verificar condições de férias' o processo siga em sua execução, iniciando a atividade 'Avaliar solicitação de férias'. Com isso, a sobreposição de sequence flows foi evitada, deixando o processo mais legível.

O link só é usado como evento intermediário, e por significar uma sequência implícita não pode ser usado para ligar processos diferentes. Isto significa que, no caso de processos desenhados utilizando pools, não podemos usar eventos de link para fazer com que um processo em uma pool dê continuidade à execução de um outro processo, em outra pool.

Assim, a principal diferença entre o evento de link e para os de message e signal reside no fato de que o primeiro é usado para conectar a sequência de um mesmo processo, enquanto os dois outros tratam da comunicação entre processos.

Entre estes dois eventos – message e signal -, a diferença é um pouco mais discreta. Ambos podem ser utilizados para a comunicação entre processos distintos.

O evento de message é usado para a transmissão/recebimento de informações entre processos. Esta troca de informações, de acordo com a especificação BPMN, pode ocorrer por qualquer meio: verbal, escrita, via email, ou até mesmo sistemática. O foco está no aspecto de que há um emitente (demonstrado através do evento throw message) e um destinatário (demonstrado através do evento catch message). O emitente conhece o destinatário, assim como o destinatário sabe de quem receberá a mensagem (mesmo que os dois processos que se comunicam não estejam desenhados no mesmo diagrama).

Neste exemplo, há uma transmissão de informação de um processo para o outro, representado através da Comunicação do número de participantes do Processo de Inscrições para o Processo de Logística de Treinamentos.

Para mais dicas sobre como modelar corretamente diagramas com comunicação entre processos, veja a postagem BPMN: Modelando corretamente o fluxo de sequência de atividades.

Signal também pode ser utilizado para a comunicação intra e entre processos. A diferença é que enquanto a mensagem tem um destinatário específico, o sinal pode ter um emitente e inúmeros destinatários – e eles não necessariamente se conhecem. O funcionamento do signal é como um broadcast: o throw signal emitirá o sinal (como um apito) e todos os processos que estão aguardando aquele sinal (catch signal) o captarão, dando sequência aos seus fluxos.

Além disso, não há transmissão de informações no envio de sinal. Ele é realmente apenas como um apito, alertando que o evento ocorreu, e que quem estivesse aguardando por ele, agora pode prosseguir com seu processo.

Os diagramas acima demonstram um conjunto de processos sincronizados através de Signals para apoiar o Processo de Monitoramento das Linhas de Comunicação de uma operadora de crédito, que disponibliza as "maquininhas" de cartão nas lojas. O Processo de "Monitoramento da Comunicação" possui uma atividade recorrente que monitora, constantemente, se as linhas telefônicas utilizadas estão todas disponíveis. Se for identificada falha em uma linha de comunicação, o processo dispara um evento de sinal "Erros em linhas de comunicação". Esse sinal é o gatilho de disparo para dois processos: "Processo de Restabelecimento da Comunicação" e "Processo de Contingência da Comunicação". O Processo de restabelecimento inicia um conjunto de atividades para buscar o restabelecimento do serviço. Enquanto isso, o Processo de contingência aguarda algum tempo para verificar novamente se as linhas foram restabelecidas antes de iniciar as ações de contingência (possivelmente porque a contingência tem um custo mais elevado, de forma que a esperar algum tempo para o restabelecimento das linhas pode ainda ser mais viável para a empresa). Depois que as linhas forem restabelecidas pelo "Processo de Restabelecimento da Comunicação", este processo emite o sinal "Linhas de comunicação restabelecidas" e dá seguimento para o cálculo da multa com a operadora de telefonia. O sinal emitido faz com que o Processo de Contingência dê seguimento ao seu fluxo para desligar a contingência (já que a operação voltou ao normal), e também dispara o processo de "Avaliação de SLA do Cliente", no qual são analisados os clientes impactados pela falha no serviço e realiza-se a negociação de possíveis multas pela quebra do nível de serviço.

Signal também pode ser utilizado para a sincronização de um processo com múltiplas instâncias de um outro processo. É o caso do excelente exemplo apresentado no artigo A case for BPMN Signal, por Anatoly Belychook no blog Process is the Main Thing.

Resumindo:

  • Link events são usados para abstrair sequência de atividades em um mesmo diagrama de processo, e por isso só podem conectar uma ponta de um processo a outra de um mesmo processo.
  • Message events são usados para abstrair a comunicação entre processos, e portanto não devem ser utilizados para demonstrar sequência de atividades. Os eventos de message possuem emitente e destinatário conhecidos.
  • Signal events são usados para realizar broadcast de sinal, onde o emitente envia o sinal sem conhecer seus destinatários.

Avaliando o real custo-benefício de BPMS livres ou de baixo custo

-
(3) Comentários

No nosso último post falamos sobre os motivos que tornam a escolha de uma plataforma de BPMS tão difícil (veja aqui).

Aprofundando a questão da seleção de plataformas, um equívoco muito comum está no fato dos profissionais acreditarem que soluções de BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas. Por vários fatores que veremos a seguir esta premissa nem sempre é verdadeira, sendo fundamental que os seguintes fatores sejam analisados:

  1. Investimento total na ferramenta no longo prazo: Nem sempre o custo de licenciamento é o maior custo na aquisição de uma solução BPMS, principalmente quando visto a médio ou longo prazo. Muitas vezes, o custo de um contrato de suporte e manutenção de uma ferramenta gratuíta é significativamente maior ao final de 3 ou 5 anos do que a soma dos custos de licenciamento e contrato de manutenção de outras ferramentas, de modo que este custo não pode ser analisado somente no primeiro ano.
  2. Requisitos disponibilizados pela ferramenta: Para evitar que o barato saia caro, analise o quanto a solução escolhida é aderente às necessidades da sua empresa. Caso existam requisitos obrigatórios ou opcionais que ela não atenda, verifique qual será o impacto da solução escolhida não ter estas funcionalidades.
  3. Benefícios (reais) de uma solução Open Source: A escolha de uma solução open source (quando o fabricante disponibiliza o acesso ao código fonte do produto) nem sempre traz o benefício esperado pela organização. Via de regra, fornecedores que dão suporte e manutenção às suas ferramentas não permitem, durante o período de vigência do contrato, que seus clientes alterem o seu código fonte, pois isso inviabilizaria o contrato de suporte.
  4. Características do suporte oferecido pelo fabricante: É fundamental verificar como é o nível de suporte fornecido pelo fabricante: Questões como a existência de suporte no país, a língua em que é prestado o atendimento, a possibilidade de se obter um atendimento no local, a disponibilidade 24×7, a existência ou não de um limite de abertura de chamados e o tempo de atendimento à produção devem ser analisados de modo a verificar se o suporte irá atender às expectativas.
  5. Existência de mão de obra qualificada: Uma ferramenta de BPMS, por si só, é uma caixa vazia: não tem nenhuma utilidade enquanto os processos não forem desenvolvidos. Assim, a disponibilidade de mão de obra capacitada para realizar este desenvolvimento torna-se um fator crucial.
  6. Esforço para a formação de um profissional apto a operar com a plataforma: Uma alternativa para uma eventual falta de mão de obra qualificada é a organização investir na formação de pessoal capacitado. Aqui, torna-se fundamental avaliar qual a complexidade desta formação: Quais os pré-requisitos mínimos de conhecimento de um profissional que venha a se capacitar? Como é a qualidade do material de capacitação fornecido pelo fornecedor? Existem instrutores disponíveis para realizar esta formação? Ou existe uma material de auto-estudo que permita esta capacitação? O quão rico é este material?
  7. Verifique o custo da mão de obra especializada: De nada adianta a organização economizar em licenciamento e gastar muito mais a cada projeto de automação que for realizar. Desta forma, é importante que se avalie qual o custo da mão de obra especializada em operar a ferramenta de BPM.
  8. Qual a produtividade oferecida pela plataforma: Finalmente, a produtividade também é um fator essencial na análise de custo entre plataformas distintas. Semelhante à questão do custo da mão de obra, uma plataforma que render uma produtividade significativamente superior às outras pode ter o seu custo de licenciamento pago rapidamente ao final de um primeiro ou segundo projeto de automação.

Qual o melhor BPMS do Mercado?

-
(1) Comentário

Frequentemente, clientes e prospects perguntam aos consultores da iProcess qual é a melhor ferramenta de BPMS existente hoje no mercado. Infelizmente não existe uma resposta única para esta questão e a dificuldade em respondê-la advém de inúmeros fatores.

Nesse post procuramos elencar alguns dos motivos pelas quais a escolha de uma plataforma de BPM é uma escolha tão difícil.

  1. Por ser uma escolha corporativa: soluções de BPMS não são soluções departamentais: assim como os processos, que possuem uma natureza transversal na organização, uma solução de BPMS tende a ser utilizada por toda a organização.
  2. Pela necessidade de atender diferentes necessidades: sendo uma escolha corporativa, a escolha da solução de BPMS deve atender a um conjunto amplo de demandas: caso contrário, corre-se o risco de se deixar alguma necessidade organizacional à descoberta. Isso exige que um amplo levantamento de expectativas deve ser realizado antes da sua seleção, de modo a evitar uma quebra de expectativa após a escolha da solução.
  3. Pelo enorme conjunto de funcionalidades disponíveis: Existem hoje mapeados na iProcess mais de 600 requisitos que podem ser avaliados na escolha de uma ferramenta de BPMS. Obviamente nenhuma ferramenta atende a estes 600 requisitos, e tão pouco é comum as empresas terem demandas tão complexas a ponto de necessitar todos estes requisitos sejam atendidos como obrigatórios. Desta forma, o casamento entre o que a empresa precisa e o que a plataforma disponibiliza é um fator crítico de sucesso na escolha da plataforma.
  4. Pelo número de alternativas que existem hoje no mercado: Existem hoje centenas de ferramentas de BPMS disponíveis no mercado. Só no Brasil são fabricadas dezenas, sem contar tantas outras que possuem escritórios de representação instalados no país.
  5. Pelo enfoque dado pelo fabricante ao conceber o seu produto: Via de regra os produtos de BPMS possuem categorias de funcionalidades que se destacam dos demais devido a forma como surgiu o produto. Produtos de BPMS se originaram de diferentes segmentos tecnológicos, tais como a gestão de conteúdo, a colaboração, a integração entre sistemas, a edição de formulários, …
  6. Pela enorme variação de valores financeiros envolvidos: Existem atualmente produtos para todos os bolsos e gostos: desde aqueles que são totalmente gratuítos (mas que possuem contratos de suporte e manutenção) até aqueles cujo o licenciamento pode chegar à centena de milhares de dólares. A forma de licenciamento também tem o impacto direto na sua precificação, sendo os tipos mais comuns as licenças por usuário ou processador.
  7. Pelas plataformas tecnológicas existentes na organização: As plataformas tecnológicas disponíveis dentro da organização podem facilitar ou inviabilizar a escolha de uma plataforma de BPM. Questões como, por exemplo, o sistema operacional utilizado nos computadores clientes e servidores (Windows, Linux, Unix, …); o banco de dados da organização (Oracle, DB2, Postgress, SQL Server, …); o servidor de aplicação disponível (IIS, Apache, WebLogic, Websphere, …); a linguagem de desenvolvimento utilizada (Java, .NET, PHP, …) podem ser fundamentais na análise de aderência de uma ferramenta de BPMS à plataforma atual.

A escolha certa de uma plataforma de BPM passa por uma análise detalhada de cada um destes fatores. É importante ter em mente que a escolha inadequada de uma solução de BPMS pode inviabilizar a execução de alguns processos de negócio da sua organização e, em última análise, até mesmo as suas iniciativas de gestão por processos.

[Atualizado] Leia também: ferramentas BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas?

Até lá.