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.

 

Lançamento do Orquestra 3.0

De Porto Alegre, Kelly Sganderla e Fabiano Dias

A iProcess foi conferir o Lançamento do Orquestra 3.0 em evento, realizado no Centro de Eventos CIEE-RS em Porto Alegre, onde foi apresentada a nova versão do BPMS da Cryo Technologies.

Na apresentação, foram demostradas  as inovações do produto, na qual destacam-se:


Nova Plataforma

A versão 3 do Orquestra foi totalmente reescrita sobre uma nova plataforma tecnológica propiciando a aplicação de uma série de melhorias.

Nova Interface

  • A interface do portal ganhou uma nova área de trabalho, mais atraente e moderna.
  • O “Meu Ambiente de Trabalho” está mais integrado. Além da tradicional lista de tarefas, foi agregada uma nova área de notificações que possibilita o acompanhamento das atividades dos processos em tempo real.
  • Novas funcionalidades permitem a customização visual de cores para a identidade visual do cliente de forma simples e prática.
  • Nova estrutura multilíngue, já preparado para espanhol e inglês. A troca do idioma pode ser realizado tanto na página de login como nas configurações, não sendo necessário a reinicialização do sistema.

Melhor experiência do usuário na execução do trabalho

  • Novos controles na tarefa para maior flexibilização na execução das atividades, com possibilidade de devolver o processo para uma tarefa já concluída, encaminhar tarefa para questionamento a terceiros, cancelar, salvar e fechar.

Nova funcionalidade de consulta a terceiros

  • Melhoria  da usabilidade de execução de tarefa.
  • Mecanismo de arraste-solte para incluir múltiplos arquivos nas tarefas.
  • Filtros avançados de processos com opção de salvar filtro e compartilhamento de relatórios com outros usuários.
  • Mais funcionalidades para relatórios, reescritos com tecnologias que propiciam gráficos melhores, como os relógios e o novo mapa de calor do processo (que aponta as tarefas onde ocorre maior atraso).

Novo mapa de calor do Processo

Desenhador de Fluxogramas padrão BPMN

  • Novo desenhador de processos agora está mais aderente à notação BPMN. Os componentes anteriores foram remodelados e adequados aos respectivos elementos da notação.

Desenhador de processos

  • A ferramenta de modelagem está mais rica em experiência do usuário, com auto-alinhamento e melhor organização dos elementos do fluxo do desenho.
  • Definição/detalhamento das tarefas e formulários agora está integrada diretamente ao desenho do processo, propiciando maior produtividade na preparação do processo automatizado.
  • Criação dos formulários está mais visual e tem com editor integrado de scripts e estilos.
  • Gerenciamento do controle de acesso do processo desde a sua criação.
  • Importa o desenho do fluxo a partir de arquivos de modelos XPDL (como BizAgi) e Visio 2013.

Social/Colaborativo

  • Perfil do usuário agora conta com foto, que é apresentada em todos os históricos, chats e notificações, facilitando a identificação dos processos e seus participantes.
  • A nova área de notificação em tempo real mostra atualizações de status de processos em que o usuário está envolvido.
  • Chat online com usuários conectados, possibilitando que os usuários possam realizar consultas rápidas a outros colaboradores durante a execução da tarefa.

Inovações tecnológicas

  • O produto segue em plataforma Microsoft .NET, agora atualizado para .NET 4.0.
  • Suporta bancos de dados SQL Server e Oracle, ambos em suas últimas 4 versões (em homologação para Oracle 12g).
  • Incorporação de plugins para controles de skins e customização visual mais facilitada.
  • HTML 5: Última versão de linguagem para estruturação e apresentação de conteúdo, que apresenta novas funcionalidades de semântica e acessibilidade.
  •  Minificação de arquivos como JS e CSS, reduzindo o tráfego e beneficiando o desempenho do produto.
  • Mobilidade e multiplataforma: Suportado nos principais browsers do mercado (Chrome, Firefox, InternerExplorer, Safari) e plataformas móveis (iOS, Android, WindowsPhone e BlackBerry).

Apesar das inovações, empresas que já utilizam o Orquestra 2.x não deverão ter impactos na migração para a nova versão.

O release oficial está previsto para o dia 9 de setembro de /2013.

A partir do lançamento, o posicionamento da Cryo é acompanhar a implantação e uso do Orquestra 3 para avaliar o impacto das inovações e definir as próximas prioridades no roadmap do produto.

Conclusões
Percebemos no Orquestra 3 uma  evolução especialmente na melhoria da experiência do usuário na interação com o sistema – um aspecto chave para que a automação de processos possa ganhar mais adeptos dentro da organização.
Também vislumbramos um possível ganho em produtividade no desenvolvimento dos processos com o novo desenhador, que passou a seguir o padrão BPMN na representação dos processos e a integração da criação de formulários ao modelo do processo.
O investimento na criação de um ambiente mais social, com notificações em tempo real e chat, parecem ser uma boa aposta para o produto, já que esta vem se demonstrando uma tendência para o mercado dos BPMS.

Nesta sexta, 30/8, a Cryo realiza um webcast de apresentação do produto.

Para maiores informações sobre o Orquestra 3, visite o site do produto: http://www.cryo.com.br.

Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

Recentemente um de nossos leitores nos escreveu sobre seu entusiasmo em iniciar uma experiência prática em BPM. Ele compartilhou conosco um desenho de processo (que discutiremos neste artigo, com a permissão do leitor) cujo objetivo era ser automatizado com dois propósitos: servir como base para a monografia e também validar o BPMS como tecnologia para automatizar processos na empresa de varejo no qual atua na área de TI.

O argumento da escolha do Processo de Pré-venda para esta primeira experiência foi: que fosse pequeno (poucas atividades) para viabilizar a automação no curto tempo para a monografia, mas que ao ser desenvolvido seria usado como piloto para provar a tecnologia na empresa e, dando certo, o processo evoluiria para as etapas seguintes da venda. Portanto, havia uma expectativa de que a automatização dele pudesse demonstrar bons resultados para a organização, a ponto de convencê-los que valeria a pena investir na adoção da solução e a implementação do restante do processo (e eventualmente de expandir a iniciativa para todos os processos da organização).

Embora ter processos executados e controlados por um BPMS (ou um motor de workflow) possa ser parte do ciclo da gestão por processos, não significa que a empresa tenha adotado Business Process Management como filosofia de gestão. Mas, dependendo do contexto organizacional, muitas vezes a iniciativa nasce dentro da TI, em situações como esta.

A questão é: seria este um bom processo para demonstrar resultados iniciais que possam alavancar uma iniciativa maior BPM (e em uma monografia, apresentar resultados satisfatórios)?

É aqui que este artigo realmente começa :-)

A notação BPMN é excelente para representar atividades de um processo de negócio. Mas a especificação não esclarece exatamente o que é o escopo de um processo de negócio, e nem o nível de granularidade, ou mesmo um método de uso. Apenas dispõe os elementos e as regras de uso visando uma padronização no entendimento de um processo mapeado.

Analisamos juntos o processo e percebemos que este diagrama não é um processo de negócio. É apenas uma parte dele, praticamente o fluxo de ações de uma atividade.

Os benefícios típicos da automatização aparecem quando o processo de negócio :
- Envolve mais de uma área da empresa (melhoria da comunicação)
- Permite extrair indicadores que demonstrem o desempenho do processo (melhoria do controle)
- Deve ser controlado para que sua execução siga integralmente o fluxo modelado
-Possibilita  apresentar informações de tempo do processo que possam apoiar as decisões que levarão à sua evolução (quanto tempo o processo leva hoje e quais atividades devem sofrer alguma melhoria para que esse tempo possa ser reduzido).
[Veja mais sobre benefícios típicos da automação de processos no artigo de Paulo Capiotti, Benefícios da Automação de Processos]

Ao analisar o diagrama, desaconselhamos a sua automatização, pois a mesma não obterá nenhum benefício significativo. Justificamos isto apontando alguns argumentos que usamos quando estamos avaliando a viabilidade/ganho ao se automatizar um processo para um cliente:

I. Este processo tem apenas um usuário. No diagrama original há duas lanes, a do vendedor e a do cliente, mas o fato é que o único a interagir diretamente com a interface humana do BPMS, neste caso, será o vendedor. Se ajustarmos o diagrama para representar apenas as atividades que serão automatizadas (conforme abaixo) e colocando o cliente em uma outra pool (já que ele não irá interagir diretamente com o BPMS) isto se torna bastante visível:

II. Todos estes passos acontecem em um curto espaço de tempo. Pelas tarefas mapeadas, percebe-se que elas ocorrem com o cliente ali, na frente do vendedor. Neste caso, ao automatizar cada uma destas tarefas separadamente, poderá gerar um impacto negativo no aspecto da interface, porque para cada “passo” o usuário (vendedor) terá que: procurar a tarefa na lista de trabalho, clicar para abrir, realizar as ações necessárias na tela, finalizar a tarefa (para que o BPMS registre que aquela tarefa foi concluída e verifique qual a nova tarefa, criando um novo item na lista de trabalho), aguardar o refresh da lista de trabalho e então realizar novamente estes passos para cada uma das atividades do fluxo. Em termos de usabilidade, isso se torna desgastante para o usuário porque faz com que ele tenha que dar inúmeros cliques para fazer uma sequência de ações que possivelmente poderia ser condensada em uma única tela. Em outras palavras, esta sequência de ações poderia compor um Caso de Uso (artefato típido da análise de sistemas tradicional).

III. Além disso, se este processo já é executado manualmente, possivelmente há alguma flexibilização na ordem em que estas tarefas ocorrem (por exemplo, em algum caso o vendedor poderia verificar o cadastro do cliente antes de incluir os itens de compra). É importante considerar isso, pois ao automatizar o fluxo no BPMS, ele sempre será executado como foi modelado. Isso implica que nada pode ser feito antes nem depois do previsto – tudo tem que seguir a ordem das tarefas no diagrama. O que é tradicionalmente um benefício da automatização de processos (garantia da integridade da execução), neste caso poderia ser um aspecto negativo, pois não é o engessamento das etapas que queremos (e toda vez que algo precisar ser levemente diferente os usuários dirão que não é possível porque “o sistema não permite”).

Então percebemos que o processo escolhido é, na verdade, apenas uma atividade de um processo de negócio muito maior.

Fica fácil nesta análise perceber que o sucesso de projetos pilotos para a adoção de um sistema de gestão de processos não depende apenas da qualidade do produto, mas também da escolha de um processo com tarefas que possam efetivamente demonstrar bons resultados.

Ao leitor, sugerimos ampliar um pouco mais a abrangência do processo – o que não significa necessariamente que será mais trabalho. Para um piloto como este, recomendamos mapear, em um nivel macro, todo o processo (não apenas esta etapa da pré-venda), e como primeiro esforço de automação identificar pontos de controle que poderiam ser automatizados (seis ou sete tarefas onde o processo muda de status ou há alguma alteração na rota do fluxo).

Alguns desses pontos de controle podem até ser obtidos de sistemas que já existem hoje na empresa, o que demonstraria ainda mais benefícios na automatização do processo. Por exemplo, no sistema que controla os pedidos, fazer com que o processo siga adiante quando a entrega for despachada. Poderia ser agregado ao processo uma tarefa de serviço para buscar essa informação no sistema.

Com um piloto assim, os indicadores podem demonstrar informações muito mais significativas para a organização do que conhecer, por exemplo, quantos minutos está levando a pré-venda. Será possível identificar onde ocorrem os gargalos, que estapas são críticas e estão atrasando o processo, possivelmente até instigar a empresa em investir na análise,  melhoria e medições mais abrangentes, e quiçá em adotar por completo uma filosofia de gestão por processos.

Implantação de BPMS não substitui os sistemas da empresa

Num artigo anterior deste blog, procuramos abordar as diferenças entre BPM e Workflow, com a intenção de minimizar a confusão existente com relação a este dois termos. Neste sentido, achamos interessante continuarmos a desmitificar outros mitos que se referem a BPM no que tange o aspecto da tecnologia.

Hoje, vamos falar de um dos mitos que mais escutamos durante os nossos projetos: a idéia de que a implementação de BPM irá “substituir” total ou parcialmente os sistemas atuais, e passar eventualmente a ser o repositório central das informações da organização. Ou, como já ouvimos algumas vezes, que o BPMS vai passar a ser o “ERP” da organização!

Em uma iniciativa BPM, uma organização automatiza processos para aumentar seu nível de controle e monitoramento na execução dos processos. Neste sentido, um BPMS atua como orquestrador da execução dos processos entre pessoas e sistemas, definindo o fluxo do trabalho e da informação entre estes participantes. Mas então, vem a pergunta: quem é o dono da informação numa automação de processos? Vamos primeiramente analisar 2 dos cenários mais frequentes de automação de processos.

1) Automação de processos que originalmente eram executados em papel, pouco/nenhum apoio de sistemas:

Neste caso, a organização não dispõe de sistemas para apoiar a execução destes processos, ou dispõe de sistemas que atendem apenas a uma parte do processo.

Normalmente são criados formulários eletrônicos que são responsáveis pelo início e execução do processo (ex: num processo de solicitação de viagem, o formulário inicial conteria os dados da viagem desejada pelo usuário). Durante a execução destes processos, usualmente existem pontos de integração com sistemas existentes na empresa (ex: sistema financeiro, contábil, etc). Neste cenário, eventualmente o BPMS poderá servir como repositório de algumas informações, normalmente sendo o repositório das “solicitações” em si (ex: solicitações de compra, solicitações de viagem, etc), e não dos dados de negócio de fato. Mas na experiência que temos, com bastante frequência as informações originadas/geradas pelos processos automatizados são enviadas para gravação em sistemas existentes da organização, como por exemplo ERP ou sistemas legados, que são de fato os responsáveis por armazenar e manter aquelas informações.

2) Automação de processos com apoio de sistemas:

Neste caso já existe um ou mais sistemas que apoiam a execução de parte ou todo um processo, mas o fluxo de execução das atividades não é orquestrado e controlado, ou seja, os sistemas e usuários responsáveis por aquele processo estão desconectados uns dos outros, o que gera então a necessidade de automação.

Neste cenário, com frequência as atividades do processo automatizado são executadas nos próprios sistemas, cabendo ao processo automatizado basicamente controlar o início e término das atividades, e a comunidação dos envolvidos nos pontos onde há necessidade de alguma intervenção humana. Assim, as atividades na lista de trabalho meramente direcionam os usuários para os sistemas onde estes deverão efetivamente realizar as atividades. Outro cenário bastante frequente é a busca, pelo processo automatizado, de informações armazenadas em sistemas existentes, de forma a apoiar os usuários na execução dos processos. E, como não poderia deixar de ser, neste cenário é ainda mais frequente e usual a necessidade de, em diversos pontos do processo automatizado, enviar as informações geradas durante a execução do processo para armazenamento em sistemas existentes.

Com base nos cenários visto acima, retomamos então a pergunta. Quem é realmente o dono da informação numa automação de processos?

Note que, em qualquer um dos casos que citamos até agora, normalmente o BPMS não é a fonte principal dos dados sendo manipulados, mas atua principalmente como integrador destas informações, buscando e enviando dados para outros sistemas durante a execução dos processos.

Podemos concluir, então, que a implementação de um processo automatizado de forma nenhuma significa a descontinuidade dos sistemas existentes!

Estimando a duração de processos

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.

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

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?

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á.

Até onde vão os benefícios da automatização de processos “zero-code”?

Quando buscamos soluções de BPMS (Business Process Management System), um dos argumentos mais sedutores lançados pelas equipes de vendas dos produtos é o de “zero-code”, ou “código zero”. Zero-code é a promessa de que o produto permite que um usuário de negócio possa modelar seu processo e disponibilizá-lo para execução automatizada sem a necessidade de desenvolver código de programação.

Esta proposta vem de encontro a uma percepção geral do negócio em relação à TI. Num cenário em que as organizações possuem inúmeros sistemas, nas mais diferentes plataformas e tecnologias, e em que o suporte tecnológico encontra dificuldades em atender com agilidade as necessidades do negócio para acompanhar às mudanças estratégicas do mercado, as empresas já não querem mais TI. Querem resultados.

Assim, a expectativa de poder modelar seus processos e executá-los sem requerer o envolvimento de analistas de sistemas e desenvolvedores soa extremamente atraente.

Mas o que significa de fato “zero code” e até onde um processo pode ser implementado com esta visão?

Parte desta impressão é alimentada pela adoção de uma “linguagem” de modelagem de processos em comum: a notação BPMN (Business Process Model and Notation). BPMN permite que a documentação de um processo em nível de negócio possa ser complementado para adquirir profundidade técnica à medida que é preparado para a implementação. Assim, o processo de negócio modelado pela área de negócio pode ser o mesmo a ser implementado no BPMS adotado pela organização.

O fato de BPMN permitir que usuários de negócio possam mapear e detalhar seus processos, leva muitas ferramentas vislumbrar a participação destes usuários de forma mais ampla do que a simples definição e detalhamento para o desenvolvimento de aplicações tradicionais. O usuário de negócio capacitado pode: definir a cadeia de atividades e suas dependências, definir regras de negócio para manejar fluxos alternativos, detalhar o que deve ser solicitado a cada participante nas atividades para que as mesmas sejam consideradas como concluídas, definir quem são os responsáveis por realizar o trabalho de cada tarefa.

Para tanto, existem algumas premissas básicas na realização de um projeto como este:

I. O(s) usuário(s) de negócio precisa(m) ter alto domínio sobre tecnologia e sobre a ferramenta para compreender e aplicar corretamente cada um de seus recursos;

II. O(s) usuário(s) de negócio deve(m) ter noções de construção de telas/formulários através do qual os participantes irão interagir com o processo em suas atividades;

III. O processo deverá ser essencialmente humano e restrito às informações coletadas em sua execução.

O resultado do processo sem envolvimento da TI está de certa forma limitado às funcionalidades mais básicas da solução de BPM, produzindo um workflow de atividades humanas com baixo nível de (ou sem) inteligência. Sem programação não é possível utilizar-se da inteligência que a organização já possui e que está distribuída nos seus sistemas sob a forma de informação.

Um dos aspectos mais importantes do processo é a informação. Naturalmente, durante o desenho do processo de negócio são identificadas necessidades de informações que precisam ser reunidas de fontes diferentes e eventualmente transformadas para sustentar a execução do processo.

Assim, inevitavelmente a participação de profissionais de TI acaba sendo necessária. Não apenas para o resgate e armazenamento de informações no decorrer do processo, mas a própria questão da interface do usuário nas atividades do processo – que muitas vezes requer mais do que oferece o formulário básico que pode ser construído com os recursos disponibilizados pela ferramenta.

O que ocorre então é a necessidade da própria TI rever seu papel, sobretudo do Analista de Sistemas. O novo analista deve ajudar a construir o processo, identificando juntamente com o negócio os componentes de software que precisam ser desenvolvidos para:

  • coletar informações do processo para alimentar os sistemas legados;
  • buscar informações de sistemas legados para disponibilizar aos participantes do processo, minimizando  a necessidade de acessar a diferentes sistemas para isso;
  • identificar melhorias de interface que reduzam o esforço de interação do usuário com o processo (como busca de valores existentes, cálculos, etc);
  • identificar validações que possam ser feitas pelo sistema para garantir a integridade do processo;
  • identificar formas mais eficazes de realizar o balanceamento de atividades em grupos.

Automatizar atividades humanas sem fazer uso inteligente dos recursos computacionais da empresa no que se refere à obtenção de informações agregará pouco ou nenhum valor ao processo e como consequência apresentará retorno do investimento muito abaixo das expectativas.