Mais um editor BPMN free: Modelador do Bonita BPM

Em nosso artigo sobre 7 Ferramentas Gratuitas para Criar Diagramas de Processos com BPMN deixamos de fora o modelador do Bonita BPM por se tratar de uma ferramenta integrada ao BPMS da Bonitasoft. Porém, devido ao grande número de sugestões para que incluíssemos esse modelador em nossa análise, decidimos exibir aqui uma breve apresentação.

Em primeiro lugar, como já foi dito, a suite Bonita BPM Community deve ser instalada completamente para que se possa testar o modelador. Após a instalação padrão (que não permite nenhuma personalização além do diretório de instalação) você abre a aplicação e é exibida a tela de boas-vindas do BPMS. Ao clicar no item de menu <New Diagram>, o modelador de processos do Bonita BPM é exibido.

Bonita BPM Process Modeler

Modelador de processos do Bonita BPM

Como as demais ferramentas de modelagem, o modelador do Bonita BPM é composto por um barra de menu (contendo itens padrão), uma paleta de elementos BPMN, a área de modelagem e um conjunto de guias para documentação e configuração dos elementos dos modelos de processos.

A paleta de elementos, que foi um dos focos da nossa investigação, não contém todos os elementos da notação. Sentimos falta, por exemplo, das atarefas manuais (manual task) e tarefas de regra de negócios (business rule task), assim como os subprocessos embutidos/incorporados (embbeded): se você quiser fazer hierarquização de processos, abstraindo conjuntos de atividades relacionadas, terá de usar subprocessos reusáveis, que na ferramenta são identificadas como Call Activities.

Muitos outros elementos não estão presentes, mas pensando em automação de processos não fazem tanta falta – considere nosso artigo Um BPMN para cada propósito de modelagem de processos onde citamos o artigo de Muehlen e Recker intitulado “How Much Language is Enough?”.

Em resumo, na modelagem de processos para automação (que é a finalidade da ferramenta) o conjunto de elementos implementados pelo Bonitasoft parece ser suficiente, mas se você deseja usar o modelador para fazer modelos de negócio com todo o poder de expressão da BPMN 2.0, vai sentir falta de muitos elementos.

Quanto à usabilidade do software, nossa avaliação é de que o modelador de processos do Bonita BPM é eficaz, pois apesar da limitação dos elementos indisponíveis da notação a ferramenta permite modelar os processos com resultado similar às demais ferramentas já avaliadas. Também se mostrou uma ferramenta eficiente, com fluidez na tarefa de modelagem dos processos, especialmente no que se refere aos atalhos para outros elementos (figura abaixo) e ao alinhamento automático e manual dos fluxos de sequência, o que confere uma boa produtividade ao software.

Imagem dos atalhos para outros elementos

Atalhos para outros elementos

Como resultado, a satisfação com o uso do modelador só não é maior pela falta dos componentes da BPMN e pela falta de atributos de documentação dos modelos presentes em outras ferramentas.

Nossa conclusão é que se você pretende testar ou adotar o Bonita BPM, não precisará de outro modelador de processos como acontece com outros BPMS do mercado (ciente da ausência de muitos elementos da notação). Se, por outro lado, você não vai utilizar o Bonita BPM como BPMS e ainda assim quiser utilizar seu modelador para documentar processos de negócio, terá algum trabalho extra para modelar situações que seriam mais simples com os elementos BPMN faltantes.

De qualquer modo, a instalação é rápida, intuitiva, a versão Community é muito completa e é uma ferramenta que vale a pena conhecer. Mesmo que seja por puro benchmark.

DMN: uma notação para modelagem de decisões de negócios

Nos treinamentos sobre BPMN (Business Process Model and Notation) que temos ministrado na iProcess Education ensinamos que, diferentemente dos losangos utilizados nos fluxogramas, os gateways da BPMN não contêm em si mesmos a semântica de uma decisão. Eles servem, comparativamente, para desviar o fluxo dos processos de acordo com condições previamente estabelecidas ou identificadas, isto é, possuem a semântica de um desvio condicional no fluxo dos processos com base em uma decisão de negócio tomada anteriormente.

Decisões: fundamentais nos processos de negócios

Quando se trata de tarefas humanas (tarefas manuais ou tarefas de usuário) há a compreensão imediata de que uma ação ou decisão realizada por uma pessoa (através da conclusão de uma tarefa, do clique em um botão de um formulário eletrônico, etc) determinará o caminho a ser seguido pelo processo. Porém, quando nos referimos a tarefas automáticas, e em especial a tarefas de regras de negócio, essa compreensão não é tão óbvia.

BPMN disponibiliza uma atividade do tipo regra de negócio (Business Rule Task) para representar a comunicação de um processo automatizado com um motor de regras de negócios ou um BRMS (Business Rules Management System). Falando desta forma, pode-se ter a ideia de que a formalização de regras de negócio em um  BRMS é algo trivial ou de menor importância, que basta preencher um formulário ou cadastro de regras quando, na verdade, se trata de um aspecto essencial para os negócios.

Decisões de negócio: manuais ou automáticas?

As regras de negócio carregam as decisões do negócio, que são tomadas de acordo com modelos mentais e estratégias organizacionais e implementam uma lógica de negócios que orientam essas decisões. Por isso regras de negócio declaradas clara e corretamente, bem conectadas à lógica e à estratégia dos negócios e sendo compreensíveis por todos os interessados é de extrema relevância para o sucesso das organizações.

Durante muito tempo a definição das regras de negócio e sua lógica de decisão permaneceu sem o suporte de uma notação para modelagem que permitisse sua padronização, sua formalização e o gerenciamento dos modelos de decisão das organizações.

Modelo e Notação de Decisões – DMN

Devido ao crescimento das discussões sobre a necessidade das organizações dominarem a gestão de decisões de negócio, a Object Management Group (OMG) criou uma subcomissão com o objetivo de desenvolver esse campo de estudo e dessa iniciativa surgiu a especificação DMN (Decision Model and Notation). A especificação tem por objetivo fornecer uma notação para decisões compreensível para todos os públicos, incluindo o pessoal de negócios e técnicos, e é composta de cinco componentes principais:

  • uma notação no nível dos requisitos, que permite aos analistas de negócio identificarem requisitos iniciais de decisão;
  • uma notação no nível da lógica das decisões, que permite detalhar como as decisões serão tomadas;
  • uma linguagem de expressões chamada FEEL (Friendly Enough Expression Language – Linguagem de Expressões Suficientemente Amigável), que permite a expressão das diferentes lógicas de decisão de negócios;
  • níveis específicos de conformidade, que permitem a validação automática de modelos de decisão; e
  • um metamodelo de suporte, que permite a automatização de modelos de decisão e o intercâmbio desses modelos entre diferentes sistemas.

Um aspecto digno de nota sobre a DMN é que esta nova notação se conecta naturalmente aos modelos de processos de negócio, permitindo que sejam desenhados processos de negócio conscientes de decisão, ou seja, processos em que é feita a distinção entre as tarefas que executam o trabalho e aquelas que chegam a conclusões baseadas na lógica. Na figura abaixo, baseada do exemplo da própria especificação da DMN, a imagem da esquerda representa um diagrama de processo (modelado na notação BPMN) enquanto que na direita há diagramas de um modelo DMN relacionado.

Imagem com a relação entre diagramas DMN com diagramas BPMN

Relação entre DMN e BPMN

Ainda não há muitas ferramentas de DMN disponíveis (O diagrama e tabela da imagem foram criados usando um editor de textos), mas o artigo de Larry Goldberg e Barbara von Halle publicado no site ModernAnalyst.com aponta a participação de de importantes fabricantes de software na força tarefa para definição da notação. São citadas as empresas como IBM, Oracle e TIBCO, entre outras, e sua participação nesta iniciativa indica, segundo os autores do artigo, sua intenção em produzir software relacionado à DMN.

A notação DMN é um assunto que fará parte de nossas discussões nos próximos artigos, onde pretendemos apresentá-la em detalhes, e gostaríamos de convidá-lo a participar, desde já, dessas discussões através de seus comentários. A organização da qual você faz parte já utiliza modelos de decisão? Que notação é utilizada para representar esses modelos?

Regras de negócio em projetos de automação de processos

Em muitos projetos de automação de processos é comum que nos deparemos com uma confusão conceitual que pode atrapalhar o trabalho desde a documentação até a implementação dos processos: a definição das regras de negócio e requisitos de software como sendo a mesma coisa.

Como em muitas organizações a iniciativa de BPM tem origem na área de TI, é comum que templates de documentação de processos agrupem todas estas definições em um único documento ou seção onde tradicionalmente se definem os requisitos de software, apenas utilizando a nomenclatura “regras de negócio”.

Se por um lado essa simplificação pode fazer sentido na medida em que todos os requisitos e restrições deverão ser considerados pela equipe de desenvolvimento na implementação dos processos automatizados de forma coesa, por outro inviabiliza a manutenção compartimentada, por equipes diferentes e em momentos distintos. Mas se na arquitetura de software costuma-se utilizar camadas de abstração para criar domínios de responsabilidade e interdependência de forma flexível, por que não fazer algo similar em nossos projetos de automação de processos?

Assim como dividimos os elementos de um website em conteúdo, estilo e  comportamento, devemos utilizar uma especificação de processos que considere de modo similar o que são os requisitos do processo separadamente dos requisitos de software e das regras de negócio aplicáveis. Dessa forma, estaremos possibilitando uma validação separada entre a área de negócios (regras de negócio) o escritório de processos (desenho de processo) e a área de TI (requisitos de software).

Regras de negócio são ativos empresariais

Obviamente, a integração das necessidades destas diferentes áreas deve ser considerada pelos analistas de processos, mas ao tratá-las de forma distinta viabilizamos a gestão funcional, utilizando as competências específicas de cada área, facilitando a manutenção e proporcionando agilidade nas mudanças necessárias.

A ABPMP chama a atenção para esse importante requisito do processo, ao recomendar a consideração de aspectos importantes relacionados às regras de negócio no capítulo do BPM CBOK que trata da análise de processos. Devemos considerar porém que as regras de negócio podem referir-se a regras atômicas, comuns a diferentes tipos ou linhas de negócios de uma organização, sendo altamente recomendável seu tratamento como um ativo empresarial.

Considere o exemplo da extinta CPMF (Contribuição Provisória sobre Movimentações Financeiras),  que era uma regra aplicável a diversos processos bancários entre 1997 e 2007. O que aconteceria se em cada um desses processos fosse definida uma regra de negócio para tratar daquela contribuição? Certamente haveria desalinhamento, cobranças indevidas, cobranças de valores incorretos, entre outros problemas. Agora imagine a dificuldade e a demora de realizar a manutenção em todos os processos quando essa regra de negócio era alterada ou quando foi ela extinta?

BRMS, o repositório para as regras de negócio

Armário para ferramentas
BRMS, o repositório para as regras de negócio

Como já foi dito em nosso artigo Business Rules e a Dinâmica do Negócio, o ideal é que se tenha as regras de negócio centralizadas em um BRMS (Business Rules Management System) e, na especificação de um processo de negócio, apenas se referenciem as regras aplicáveis que deverão ser consideradas pelos desenvolvedores na automatização. Devemos pensar nas regras de negócio como ferramentas que podem ser utilizadas em diversos projetos, mas que ficam em um repositório centralizado, uma coleção organizada, onde cada item possui uma funcionalidade específica e que será utilizado sob demanda.

Um fato que apoia essas recomendações é a existência, no BPMN, de um tipo de tarefa automática chamada Business Rule Task (leia nosso artigo sobre esse assunto), que permite tratar de forma um pouco mais autônoma a camada de negócio da aplicação que irá automatizar o processo.

E na sua organização, como são gerenciadas as regras de negócio utilizadas nos processos? Individualmente em cada processo? Utilizam um BRMS? Ou possuem formas híbridas para gerenciá-las? Compartilhe sua experiência e enriqueça a discussão desse importante tema.

Gerenciando o Desempenho de Processos

Quando se fala em Gerenciamento de Desempenho de Processos nas organizações é comum que muitos gestores, donos de processos, analistas e pessoal de negócios apressem-se a listar mentalmente todos os indicadores possíveis e imagináveis de seus processos de negócio. Isso é natural, mas uma tendência perigosa. Especialmente se levarmos em consideração a máxima que diz que “aquilo que não é gerenciado deteriora”.

Como não queremos que NADA deteriore nos nossos processos, nossos negócios e nossas organizações, é lógico esperar que se queira gerenciar TUDO. Porém, como lidamos com recursos limitados e necessidades ilimitadas, a pressa em responder à pergunta “Medir o quê?” e acabar logo a fase de pensar e passar rapidamente à fase do agir (construir gráficos, relatórios e produzir resultados) pode colocar em risco o gerenciamento do desempenho dos processos e a eficácia do próprio BPM.

Para não cairmos nessa armadilha, podemos organizar a implantação do gerenciamento de desempenho com a ajuda de uma velha e conhecida ferramenta, o ciclo PDCA (Plan, Do, Check, Act).

PDCA

Planeje a Gestão de Desempenho dos seus processos (Plan)

A prática de pensar pouco e agir rápido (que não é tão incomum) muitas vezes faz com que sejam negligenciadas as questões mais relevantes do Gerenciamento de Desempenho de Processos: o objetivo das medições (Medir para quê?) e o os respectivos públicos-alvo (Medir para quem?). Afinal, o gerenciamento é realizado por “alguém” e para atingir algum “objetivo”.

Medir para quê?

Quando tentamos responder diretamente à pergunta “Medir o quê?”, comprometemos o sucesso do gerenciamento do desempenho por utilizar o foco incorreto. Parece uma obviedade, mas muitas organizações respondem da seguinte forma à pergunta “Medir para quê?“:

(1) Devemos medir o desempenho dos processos para garantir sua eficiência!

Mas não deveria ser tão simples. Se nos contentarmos com essa resposta, estaremos desconsiderando o maior dos propósitos da Gestão por Processos de Negócios: entregar valor aos clientes. Se o objetivo primordial de BPM é entregar valor ao cliente, então a resposta deveria ser mais ampla e com o foco correto:

(2) Devemos medir o desempenho dos processos para gerenciá-los a fim de garantir a satisfação dos clientes com os produtos e serviços resultantes desses processos e, assim, fidelizá-los.

Você pode até argumentar, mas a diferença entre as respostas (1) e (2) pode dar rumos totalmente diferentes ao gerenciamento do desempenho dos processos da sua organização, pois determinarão o foco dos esforços empreendidos em estabelecer indicadores, instrumentos de medição e os planos de ação necessários.

Medir para quem?

Naturalmente, o esforço da gestão de desempenho não deve apenas focar na percepção do cliente, que possui apenas a visão de fora da organização. Isso por que a percepção de satisfação dos clientes com os produtos de sua empresa se dá em uma base muito restrita de valores (qualidade, preço, prazo, disponibilidade, etc), enquanto internamente a percepção de desempenho deve considerar aspectos que não estão visíveis ao cliente, como relações trabalhistas, relações pessoais, cultura e estratégia organizacionais, aspectos legais, concorrência, tecnologia e muitos outros.

Ao planejar o gerenciamento de desempenho dos processos, é fundamental estabelecer o objetivo da medição adequado para cada parte interessada. Isto varia de acordo com a natureza e o tipo de cada processo:

  • Processos primários devem focar primariamente (mas não exclusivamente) a satisfação do cliente em relação aos resultados dos processos com base em seus aspectos relevantes.
  • Processos de suporte devem ser medidos com foco em uma visão holística da organização e dos processos primários para os quais gera seus resultados, sem tirar do horizonte a visão do cliente.
  • Processos gerenciais devem ser medidos com o foco da administração (planejamento, organização, direção e controle) do trabalho e dos recursos (financeiros, humanos e materiais) da organização. Igualmente o foco do cliente deve ser um direcionador.

Medir o quê?

Para todos os tipos de processos, de qualquer natureza, as medições devem ser realizadas nas três dimensões de desempenho: eficiência, eficácia e efetividade. Assim, devemos nos perguntar:

  • Quais são os indicadores que permitem avaliar a eficiência do processo?
    A resposta será uma lista de indicadores que contemplem informações relativas a tempo, recursos, etc.
  • Quais são os indicadores que permitem avaliar a eficácia do processo?
    A lista de indicadores deverá ser composta por itens que apresentem informações que relacionem ao “contrato” firmado entre o cliente e a sua organização, isto é, o que foi prometido e o que foi entregue pelo processo.

Lembre-se de que
Não há nada mais inútil que fazer com grande eficiência algo que não deveria ser feito“. (Peter Drucker)

  • Quais são os indicadores que permitem avaliar a efetividade do processo?
    Estes indicadores deverão relacionar as entregas do processo com as reais necessidades dos clientes.

Quantas vezes você comprou Coca-Cola por que o restaurante não trabalhava com a marca Pepsi e vice-versa?

CocaxPepsi

Pode ser Coca?

 

Você entregou o que foi prometido, no prazo esperado, com o preço de mercado. Isso é o que se pode esperar dessa relação empresa-cliente. Só que não era o que o cliente queria, de fato. Você vendeu um substituto e o cliente vai encontrar outro restaurante que venda exatamente o que ele quer. Isso pode não parecer um problema se for visto como um problema pontual, mas pode ser um indicativo de tendência de mercado.

 

Execução do Monitoramento de Desempenho (Do)

Uma vez elaborada a lista de medições, com todos os atributos e seus respectivos planos de ação (se for o caso), é o momento de executar o processo e realizar as medições definidas.

Em processos executados manualmente, essas medições deverão ser realizadas também de forma manual, com ou sem o auxílio de recursos computacionais. Os atributos dos indicadores (conhece 5W2H?) determinarão as circunstâncias em que as medições deverão ser realizadas.

Nos casos de processos automatizados, entretanto, ferramentas de monitoramento dos indicadores como gráficos, relatórios, BAM (Business Activity Monitoring), entre outros, realizarão a coleta de dados, alimentação de indicadores e podem até realizar algumas ações automáticas, como enviar email, disparar processos de contingência e etc.

Monitoramento (Check)

Para realizar o monitoramento dos indicadores, algumas ferramentas podem ser utilizadas. Ferramentas como BAM são recomendadas, devido à orientação ao acompanhamento instantâneo dos negócios. Mas seja com o uso de BAM, BI, Excel ou soluções menos usuais, o principal é disponibilizar aos responsáveis e impactados pelo desempenho dos processos o acesso às informações necessárias para que possam atuar quando um desvio de desempenho é identificado.

Uma questão primordial é a definição do público para o qual devem ser disponibilizados os painéis de monitoramento. Quanto mais indicadores, quanto mais telas e atividades necessárias para realizar o monitoramento da atividade do negócio, menos controle efetivo será realizado. Dessa forma, devemos evitar a mistura de indicadores de processo primários e gerenciais, ou processos de negócio de diferentes linhas de produtos, de forma desnecessária.

dashboards

Foco no essencial

Outra preocupação relevante é a sensibilidade das informações. Deve-se garantir que as partes interessadas tenham acesso apenas às informações para as quais possuem permissão, evitando assim falhas de segurança e acessos não autorizados.

Planos de Ação (Act)

Quando um desvio no desempenho de um processo é identificado, o gerente e/ou dono do processo deve tomar medidas que restabeleçam o desempenho esperado. Não estamos falando em melhoria, mudança ou transformação de processos. Essas situações devem ser consideradas nos casos em que os planos de ação não sejam suficientes para realizar os ajustes de desempenho necessários ou caso os desvios sejam ocasionados por fatores externos à organização e que não possam ser resolvidos pelos meios previstos.

Hora de agir

Hora de agir

Considerando que o desenho do processo contemple a capacidade necessária para a realização do negócio, e considerando que os indicadores de desempenho tenham sido definidos com base nessa capacidade (de outro modo ou o desenho do processo é inadequado ou os indicadores o são), as causas dos desvios podem ser associadas a três aspectos: tecnologia, pessoas e recursos.

Tecnologia:
Se estivermos considerando processos automatizados ou que de alguma forma dependam de infraestrutura tecnológica para serem executados, não tem jeito: precisamos ter plano de contingência para a realização manual do trabalho, registro de interesse e processos de retorno/resposta ASAP, etc. Ou alguém considera aceitável interromper um processo de venda por que faltou energia e não é possível imprimir a Nota Fiscal?

Recursos:
Recursos, em geral, são o aspecto mais controlável do problema. Se eles foram mapeados corretamente, a cadeia de fornecimentos foi prevista, então os problemas estarão relacionados à disponibilidade ou à qualidade dos recursos utilizados. Desvio em um destes aspectos poderá causará impacto na execução dos processos. Os planos de ação devem estar relacionados ao restabelecimento da disponibilidade ou qualidade dos recursos.

Pessoas:
Por último, mas não menos importante, os desvios podem estar relacionados às pessoas que executam o trabalho propriamente dito. Processos automatizados costumam ser menos sensíveis a esse aspecto, visto que permitem um maior controle, monitoramento e auditoria do trabalho realizado. Em alguns casos, a própria substituição de atividades de baixo valor agregado por sistemas automatizados proporcionam redução de falhas associadas às tarefas humanas.

Se os planos de ação associados aos indicadores não forem capazes de restabelecer o desempenho esperado, o dono do processo deverá iniciar ações que deverão considerar, inclusive, alteração no desenho do processo de negócio.

Este artigo, obviamente, não pretende esgotar o assunto sobre Gerenciamento de Desempenho de Processos, mas dar uma boa visão geral sobre esta importante atividade relacionada à Gestão por Processos (BPM). Em artigos futuros, iremos detalhar aspectos que carecem de mais divulgação sobre melhores práticas e experiências recentes. Acompanhe.

5W2H: Ferramenta para a elaboração de Planos de Ação

timetoplan“Qualquer medição de desempenho deve começar com a identificação de o quê vai ser medido, o porquê de ser medido e qual valor será usado para comparação”.

Esta é uma recomendação do BPM CBOK v3.0 que culmina com a proposição de um instrumento para levantamento de medições, em forma de tabela (página 192), a serem realizadas nos processos, onde deverão ser considerados:

  • os objetivos da medição
  • os itens a medir
  • os parâmetros de comparação
  • os locais ou pontos onde as medições serão realizadas
  • o que deve ser medido
  • como serão realizadas as medições e
  • os responsáveis pelas mesmas.

É interessante perceber que BPM utiliza conceitos, termos e terminologia já consagradas e de uso tão popularizado como o 5W2H, oriundo da Gestão da Qualidade. Afinal, processos têm tudo a ver com qualidade, eficiência e desempenho. Nenhuma novidade de fato, pois BPM também assimila outros conceitos da administração, de disciplinas como a Reengenharia e Qualidade Total.

Muitas pessoas da área de processos, porém, possuem formação na área de tecnologia e tais conceitos podem não ser muito familiares. Por isso resolvemos chamar a atenção para essa ferramenta, os conceitos envolvidos e sua utilização.

5W2H é uma ferramenta para elaboração de planos de ação que, por sua simplicidade, objetividade e orientação à ação, tem sido muito utilizada em Gestão de Projetos, Análise de Negócios, Elaboração de Planos de Negócio, Planejamento Estratégico e outras disciplinas de gestão. De origem atribuída a diferentes autores, que vai desde os trabalhos de Alan G. Robinson, Rudyard Kipling, Marco Fábio Quintiliano até Aristóteles, essa ferramenta baseia-se na elaboração de um questionário formado por sete perguntas:

5W2H

As sete perguntas essenciais

Note que a sigla 5W2H origina-se nas letras iniciais das perguntas que devemos realizar.
O conceito por trás do termo significa que uma ação é influenciada por sete circunstâncias e que, ao elaborar um plano de ação, devemos responder, de modo formal, às seguintes questões:

  • O que deve ser feito? (a ação, em si);
  • Por que esta ação deve ser realizada? (o objetivo);
  • Quem deve realizar a ação? (os responsáveis);
  • Onde a ação deve ser executada? (a localização);
  • Quando a ação deve ser realizada? (tempo ou condição);
  • Como deve ser realizada a ação? (modo, meios, método, etc);
  • Quanto será o custo da ação a realizar? (custo, duração, intensidade, profundidade, nível de detalhamento, etc).

Aproveitando o clima da Copa do Mundo no Brasil, vamos exemplificar elaborando um plano de ação para organizar um evento de confraternização mensal para os funcionários de uma empresa, com o tema do campeonato mundial, em uma hipotética final entre Brasil e Argentina. (clique para ampliar)

Final Brasil x Argentina

Final Brasil x Argentina

Está claro que a ordem dos eventos pode ser alterada de acordo o tipo de evento, de organização, de contratação e etc. Colocamos as ações do plano em ordem cronológica (coluna Data) considerando uma possível dependência entre atividades. Mas essa é apenas uma abordagem.

É possível verificar, também, que as colunas “Custo” e “Local” não são tão úteis nesse caso, por ser um plano simples e por haver pouca variação nessas variáveis. Devemos considerar todas as sete circunstâncias descritas para elaborar o plano de ação, mas em casos em que uma destas circunstâncias seja fixa (como uma mesma data de realização, por exemplo) podemos deixar de representá-la em uma coluna de nossa tabela.

Da mesma forma, pode haver situações em que sejam necessárias ou desejáveis informações adicionais em nossa tabela. Além das circunstâncias normais, previstas na ferramenta 5W2H, podemos adicionar informações não necessariamente ligada às circunstâncias, mas que qualificam a própria ação ou seus resultados.

No exemplo abaixo, baseado na tabela  para levantamento de medições do BPM CBOK citada no início do artigo, percebe-se uma correspondência dos nomes dos atributos de medição com as questões do 5W2H:

Tabela para levantamento de medições

Levantamento de medições com 5W2H

No exemplo, as perguntas “O quê”, “Por quê”, “Onde”, “Como” e “Quem” são respondidas pelos atributos “Item a medir” + ” O que medir”, “Objetivo da medição”, “Onde medir”,  ”Como será medido” e “Responsável pela medição”, respectivamente.

Note que foram suprimidas as questões “Quando” – visto que a medição deverá ser executada automaticamente pelo processo ou sistema – e “Quanto”, pois não se aplicam a este caso. Também foram adicionados dois atributos de medição que não corresponde a nenhuma das 7 questões da ferramenta: “parâmetro de comparação” e “polaridade do indicador”.

Se você ainda não utiliza 5W2H em suas tarefas diárias, comece a pensar quais os planos de ação você poderia formalizar com esta ferramenta e coloque em prática na primeira oportunidade. Você perceberá que se trata de um excelente modo de formalização do planejamento, detalhamento da ação, comunicação de prazos e responsabilidades. E lembre-se de compartilhar nos comentários as suas experiências e dicas.

Medidas, Métricas e Indicadores na Gestão de Processos

Em muitos projetos de implantação de BPM que têm como foco principal a automatização de processos é comum que as organizações deixem de prestar a atenção devida a um aspecto essencial: o gerenciamento do desempenho de processos.

Nos eventos sobre BPM dos quais participamos, sempre que se perguntou quais dos participantes eram oriundos da área de TI, vimos muitas mãos serem levantadas. A maioria, na verdade. De fato, é sabido que em muitas organizações a adoção de BPM é consequência de iniciativas da área de tecnologia, seja em iniciativas próprias da TI (para fazer benchmarking, por exemplo), seja pela percepção incompleta de que BPM se trata de um conjunto de tecnologias que apoiam a TI no desenvolvimento e monitoração de processos de workflow e aplicativos.

Não perca o alvo

Talvez por isso a preocupação principal nesses projetos seja a correta implementação de BPMS, BRMS, SOA e todo o dicionário de siglas tecnológicas envolvidas, relegando os aspectos relacionados ao negócio (e o gerenciamento de desempenho, consequentemente) a um plano secundário.

Mas não percamos o alvo, o motivo de ser do BPM é a letra “M”.

Um importante ponto para realizar o gerenciamento do desempenho de processos é a definição de bons indicadores de desempenho. Esses indicadores devem ser capazes de permitir o monitoramento do negócio pelos gestores e servirem de gatilhos para a tomada de ação quando o processo apresentar uma performance diferente da esperada.

MEDIDAS x MÉTRICAS x INDICADORES

Antes de tudo, é necessário desfazer uma confusão comum na utilização dos termos “medida”, “métrica” e “indicador”, que muitas vezes são equivocadamente tomados como sinônimos.

Medida

Segundo o BPM CBOK – versão 3.0,

“Medida é a quantificação de dados em um padrão e qualidade aceitáveis (exatidão, completude, consistência, temporalidade).”

Medida é a avaliação de uma grandeza por meio da comparação com outra grandeza da mesma espécie tomada como unidade. Quando se mede o comprimento de um material ou peça, por exemplo, pode-se utilizar o metro como unidade, isto é, o objeto medido é representado como uma fração (ou múltiplo) do metro.

Medida representa um dado.

Métrica

A definição do BPM CBOK, diz que:

“Métrica é uma extrapolação de medidas, isto é, uma conclusão com base em dados finitos.”

Segundo essa definição, uma métrica pode ser entendida como a relação entre duas medidas de grandezas iguais ou diferentes.  Um exemplo seria o número de defeitos identificados em um lote de produtos finalizados (defeitos [número] / total do lote [número]).

Outro exemplo poderia ser a razão entre o número total de atendimentos realizados por um Serviço de Atendimento ao Cliente (SAC) e o número de horas trabalhadas pelos atendentes (atendimento [número]/ horas trabalhadas [tempo]).

Métrica representa uma informação.

Indicador

De acordo com o BPM CBOK,

“Indicador é uma representação de forma simples ou intuitiva de uma métrica ou medida para facilitar sua interpretação quando comparada a uma referência ou alvo.”

Indicadores representam informações a partir das quais é possível avaliar uma situação e sua evolução histórica. Contudo, indicadores mal definidos podem levar a conclusões equivocadas. Por exemplo, tomar somente a quantidade de reclamações de clientes, mês a mês, ao longo do ano, e verificar que o número absoluto de reclamações cresceu no período não indica, necessariamente, uma piora nos negócios. Está claro que se a sua empresa efetuar 1.000 vendas em dezembro e ter 10 reclamações de clientes é uma situação melhor que ter efetuado 100 vendas em janeiro e ter recebido 5 reclamações. Proporcionalmente, o número de reclamações terá caído de 5% (5/100) para 1% (10/1.000), embora em números absolutos elas tenham dobrado.

É claro que números absolutos podem ser bons indicadores, a depender do que se queira avaliar. Mas indicadores que relacionam diferentes métricas e medidas permitem relativizar a realidade e fazer melhores comparações, como no exemplo acima, pois embora o número de reclamações tenha crescido em termos absolutos, a situação, na verdade, melhorou.

Dois gráficos com interpretações comparadas

Duas interpretações de uma mesma realidade

 

INDICADORES DIRECIONADORES x INDICADORES DE RESULTADOS

Ao definir indicadores com o objetivo de monitorar o desempenho dos processos, muitas organizações definem seus painéis de monitoramento com base em métricas que focam apenas no resultado desejado e perdem, assim, a valiosa oportunidade de monitorar não apenas o resultado do processo, mas a sua execução. Dessa forma, o resultado é conhecido apenas quando não há mais nada a se fazer para que a conclusão do processo seja favorável à organização.

Para evitar essa situação, é necessário definir dois tipos de indicadores:

  • Indicadores direcionadores (drivers), que monitoram a causa antes do efeito e caracterizam-se pela possibilidade de alterar o curso para o alcance de um resultado.
  • Indicadores de resultados (outcome), que monitoram o efeito e não permitem mais alterar um dado resultado.

Um bom painel de monitoramento deve conter indicadores direcionadores e indicadores de resultados de forma balanceada. Note no exemplo abaixo a combinação de gráficos do tipo Gauge, que são normalmente utilizados para acompanhar um indicador direcionador, através de monitoramento instantâneo, e de análise histórica, como os gráficos de área.

Painel de indicadores

Painel de indicadores balanceados

Pense em uma companhia de seguros que estabelece uma meta mensal de 40 apólices de seguro por agente. Assim, cria um indicador de resultados para demonstrar as vendas por mês.

A empresa observou o histórico do processo e identificou que, para cada quatro contatos realizados por um agente com clientes potenciais, um negócio é fechado. Logo, conclui que o resultado das vendas de apólices está relacionado ao número de contatos realizados pelos agentes. Portanto, define outra meta: 160 contatos por mês, por agente. Esse é um indicador direcionador, pois permite uma melhor administração dos esforços para o alcance das metas através de ações de correção de curso, como campanhas de final de semana, plantões de vendas e outras medidas contingenciais.

Esperamos que tenha ficado clara a diferença entre medida, métrica e indicador, e o benefício de utilizar não apenas indicadores de resultado mas também indicadores direcionadores de forma balanceada.

Tem um exemplo prático que gostaria de compartilhar? Comente este artigo e contribua para a discussão e o conhecimento dos demais leitores.

Oracle BAM – Monitoramento instantâneo do negócio

Algumas tecnologias viram moda tão rapidamente que muitas empresas as adotam antes mesmo de o pessoal de negócios aprender o significado das siglas que as denominam. Este é sem dúvida o caso do BAM (Business Activity Monitoring) que muitas pessoas confundem com outras ferramentas como BI (Business Intelligence) e CEP (Complex Event Processing).

Mas o que é BAM e para que serve?

Business Activity MonitoringBAM é uma ferramenta de monitoramento da atividade do negócio através do acompanhamento em tempo real de indicadores. Isso possibilita a tomada de decisão de forma ágil a partir da análise desses indicadores assim como a execução de planos de contingência baseado em gatilhos previamente definidos, seja através do envio de alertas, execução de webservices, ou outras ações. Nesse artigo, vamos apresentar um visão geral do Oracle BAM.

 

Oracle BAM é um produto da suite Oracle Fusion Middleware que permite integração flexível com outros sistemas através de ODI (Oracle Data Integrator), webservices e conexões a diferentes bancos de dados, entre outras formas.

Uma grande vantagem do Oracle BAM é seu poder de manipulação de grandes volumes de dados, através do ADC (Active Data Cache), que podem ser capturados de diferentes bases de dados, de processos BPM e diversas outras fontes de informação.

Traduzindo todas estas informações e mudanças em elementos visuais, relatórios e alertas, o Oracle BAM tem sido utilizado por muitas empresas para monitorar desde ocorrências operacionais em ambientes de TI e infraestrutura (Service Desk, por exemplo), acompanhamento do volume de transações comerciais, alertas em desvios de processos de negócios, controle e execução de prazos de projetos complexos, entre muitos outros casos de sucesso.

A ferramenta foi idealizada para permitir a separação entre níveis de operação e acesso. Assim, suas funcionalidades principais são divididas basicamente em três visões:

BAM Architect é a interface onde o arquiteto de dados cria e gerencia os objetos de dados que contém as informações utilizadas nos gráficos e relatórios. Os objetos de dados são uma representação virtual das diversas origens de informações possíveis de forma consolidada. Também permite a utilização de cálculos de baixa e média complexidade sobre os dados, facilitando a apresentação e agrupamento das informações de interesse para o negócio.

 

BAM Active Studio é um ambiente de desenho onde os gráficos, os alertas, as conexões com webservices e o agendamento do envio de relatórios são realizados. A personalização da interface não é um ponto forte da ferramenta, mas o uso dos diversos templates e a combinação de diferentes estruturas existentes garantem, em conjunto, sua utilização em projetos de todos os tamanhos e para qualquer tipo de necessidade.

 

 

BAM Active Viewer é a ferramenta para a visualização dos relatórios e gráficos. É o painel de monitoramento propriamente dito, onde é realizado o controle de acesso por usuário, por relatório, por pasta de relatórios, etc.

 

 

Além da limitação de acesso a determinados relatórios por usuário, inclusive de forma integrada a servidores LDAP, o Oracle BAM permite ainda restringir a visualização de dados dos relatórios por usuário ou pelos grupos dos quais o mesmo faz parte. Assim, é possível permitir que um gerente acesse o mesmo relatório da direção da empresa, porém exibindo somente as informações da sua filial ou região.

Duas grandes funcionalidades que merecem destaque são o envio agendado de relatórios por email e o disparo de alertas, com diversas ações associadas (envio de relatórios e informações por email, invocação de serviços externos para objetivos específicos, execução de cenários ODI, etc), periodicamente ou atendendo à condições específicas previamente definidas (quando determinado índice atinge um nível mínimo, por exemplo).

Essa pró-atividade e resposta instantânea às mudanças sensíveis ao negócio são os instrumentos de gestão que conferem a agilidade e assertividade na tomada de decisões, bem como a execução de planos de contingências no momento apropriado.

SLA – Service Level Agreement

O setor de serviços é o que mais cresce na maioria das economias do mundo – em 2012 foi o único setor a ter alta no Brasil – e na área de TI isso é particularmente verdade, como indica a projeção da  Abradisti – Associação Brasileira dos Distribuidores de Tecnologia da Informação, que prevê um crescimento de 9% em 2013 para o mercado nacional.

O crescimento do mercado de serviços, especialmente na área da tecnologia da informação, e o consequente aumento da quantidade de contratos de prestação de serviços cada vez mais complexos e representando negócios cada vez mais vultosos (no Brasil, cerca de R$ 212,5 BI em 2012) , um maior controle sobre a qualidade dos serviços prestados se faz cada vez mais necessário.

Com esse objetivo, o CCTA – Central Computer and Telecomunications Agency, órgão público do Reino Unido, ainda na década de 80, tomou a iniciativa que originou o ITIL – Information Technoloy Infrastruture Library, uma biblioteca que reúne os conhecimentos reconhecidos mundialmente como as melhores práticas no gerenciamento de serviços de TI, fruto da compilação de décadas de experiência obtidas de empresas públicas e privadas.

ITIL FundationO ITIL descreve e recomenda a utilização de um instrumento, o SLA – Service Level Agreement,  para a celebração de um acordo entre um provedor de serviços de TI e um cliente. Nesse documento devem ser expressas as metas do nível de serviço e devem ser especificadas as responsabilidades de ambas as partes na execução do contrato de prestação de serviço.

SLA – Service Level Agreement

An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers.” 

O SLA, portanto, é um documento amplo que serve para balizar a execução de um contrato de prestação de serviços, servir de base para auditoria e fiscalização da execução desse contrato, assegurar os direitos e determinar as responsabilidades de ambas as partes, contratante e contratado.

Erroneamente, o termo SLA tem sido usado para referir apenas o aspecto de prazo de um acordo de nível de serviço. Perguntam “- Estamos dentro do SLA?”, querendo dizer “- Estamos cumpindo o prazo de atendimento de acordo com o combinado no aspecto de PRAZO definido no SLA?”.

Isso em si não é uma incorreção, apenas uma simplificação. A incorreção é que, devido à simplificação, muitos profissionais realmente não sabem que SLA é muito mais que simplesmente o cumprimento prazo de atendimento do incidente.

Some-se a isso o fato de que alguns contratos de prestação de serviços de TI têm como aspecto mais importante o cumprimento de prazos – um outsourcing de suporte técnico, por exemplo – e o acordo de nível de serviço parece ficar restrito apenas a esse aspecto, como se nenhum outro fosse importante. Logo o SLA vira sinônimo de PRAZO, simplesmente.

Entretando, um SLA bem elaborado, na sua integralidade e totalidade, deve:

  • identificar e definir as necessidades do cliente;

  • fornecer uma base para a compreensão do negócio entre as partes;

  • simplificar questões complexas;

  • Reduzir áreas de conflito;

  • promover o diálogo em eventuais disputas;

  • eliminar expectativas irrealistas.

Para tanto, deve contemplar uma ampla faixa de assuntos, tais como (mas não restritos a):

  • serviços a serem entregues;

  • desempenho, monitoramento e relatórios;

  • gestão de problemas;

  • conformidade legal e resolução de disputas;

  • direitos e responsabilidades do cliente;

  • segurança;

  • confidencialidade;

  • direitos de propriedade intelectual;

  • cláusulas rescisórias.

Não é a intenção desse artigo esgotar o assunto, apresentar ITIL ou definir de modo completo como deve ser um SLA – há muitos bons artigos disponíveis, inclusive com templates. Mas se a partir de agora você utilizar o termo SLA corretamente, não apenas em referência ao prazo de atendimento do chamados mas a todos os importantes aspectos do acordo negociado entre cliente e provedor, a leitura desse texto terá sido proveitosa.


Referências:

http://www.itsmf.com.br/portal/?page_id=74
http://www.ifmh.org.uk/inform/13_3.pdf
http://www.itsmnapratica.com.br/5-passos-para-definir-um-bom-acordo-de-nivel-de-servico-sla/
http://www.sla-zone.co.uk
http://www.studyitil.com/images/stories/studyitil/files/ITIL%20V3%20Glossary.PDF
http://www2.valoronline.com.br/empresas/2924854/desaceleracao-da-economia-nao-atinge-setor-de-ti-dizem-associacoes#ixzz2HaiTv7eS