Como realizar projetos de BAM?

No artigo BAM – Uma visão Geral, que publicamos recentemente aqui no blog da iProcess, passamos uma visão geral do BAM (Business Activity Monitoring), onde demonstramos as características, arquitetura comum e principais cenários de uso deste tipo de ferramenta.

Talvez agora o assunto seja do seu interesse, e você acha que a sua empresa pode se beneficiar da utilização desta ferramenta.

Mas neste caso, por onde começar?

A realização de um projeto de implantação de BAM pode ser caracterizada, usualmente, pela execução das seguintes grandes etapas:

1. Definição da ferramenta de BAM a utilizar: conforme citamos no artigo anterior, existem ferramentas de BAM que fazem parte de suítes de BPMS, e outras que são produtos independentes. Dependendo do tipo de ferramenta de BAM escolhida, a integração com sistemas externos poderá ter maior ou menor flexibilidade. No caso de uma ferramenta de BAM que faz parte de uma suíte BPMS, é necessário avaliar se é possível integrar a mesma com outros sistemas, pois em alguns casos só é possível a exibição de dados relacionados apenas aos processos sendo automatizados na própria suite.

Ressaltamos que a escolha do BAM não deveria ser uma escolha de um projeto, ou seja, a empresa não vai adotar uma nova ferramenta de BAM a cada processo implantado. Deve ser uma decisão corporativa e que permanecerá a longo prazo, então a escolha do BAM deve ser cuidadosa, tendo atenção a questões como aderência às necessidades de processos de toda organização (e não apenas de uma área) e que possua interface de comunicação com o BPMS utilizado para gerenciar a execução de processos automatizados.

2. Definição dos indicadores e gráficos de monitoramento necessários: é necessário discutir funcionalmente com os usuários de negócio quais são os indicadores e dashboards de monitoramento desejados, regras de segurança e acesso as informações (ex: num dashboard que será disponibilizado para todas as unidades, pode se definir que os usuários só poderão visualizar informações relativas à sua própria unidade), bem como alertas e ações sobre os alertas (se for o caso). Usualmente, esta é uma ação que está alinhada com a própria fase de modelagem, análise e melhoria de processos, onde estão sendo discutidos os processos e seus indicadores de desempenho. Assim, deste trabalho normalmente são extraídos requisitos de BAM, que permitirão  aos usuários realizar o acompanhamento dos novos processos. É importante ressaltar, no entanto, que um projeto de BAM pode ser uma ação mais “isolada” e até independente de outras iniciativas de BPM.

3. Análise técnica da origem dos dados: definidos quais são os indicadores e dashboards desejados, é necessário verificar como estes dados podem ser obtidos para serem enviados para a ferramenta de BAM. Via de regra, além dos dados de execução dos processos provenientes do BPMS, podem ser necessários dados de diferentes sistemas de informação existentes na organização (ex: ERP, sistemas legados). Assim, é necessário envolver as equipes técnicas responsáveis por estes sistemas para avaliar como estes dados devem ser obtidos, bem como a forma de integração sugerida. É importante, para isto, conhecer as possibilidades de integração que a ferramenta de BAM oferece, pois cada uma pode disponibilizar diferentes formas de integração (ex: Web Services, Filas, etc).

4. Desenvolvimento dos dashboards: após a análise técnica da origem dos dados, é necessário realizar a construção técnica dos dashboards e alertas de monitoramento (caso existam). Esta é uma etapa que irá envolver os desenvolvedores e arquitetos que conhecem a ferramenta de BAM, bem como as equipes técnicas responsáveis pelos sistemas de origem das informações. Nesta etapa a origem dos dados pode, caso necessário, ser “simulada” através de input manual de informações diretamente na ferramenta do BAM (se a ferramenta permitir).

5. Homologação dos dashboards: finalmente, nesta etapa serão testados os dashboards pelos usuários finais, já com a integração com os sistemas de origem funcionando, para verificar que estão exibindo as informações corretamente. São também testados os alertas de monitoramento e ações de contingência definidas (se for o caso), bem como as regras de segurança e acesso às informações.

Pela nossa experiência, a fase que costuma ser mais trabalhosa é a “Análise técnica da origem dos dados”. Isto porque, com o crescimento da organização e aquisição de diversos sistemas, muitas vezes existe replicação de dados em fontes diferentes, e não há uma visão de qual é a origem mais apropriada para determinadas informações. Além disso, a falta de uma governança de TI e padrões de integração também pode dificultar a escolha da melhor forma de integração com a ferramenta de BAM.

Podemos notar então que, no que se refere as macro etapas necessárias, um projeto de implementação de BAM não difere muito de projetos convencionais de implementação de TI. Porém, olhando no detalhe, é possível perceber que um projeto BAM tem diversas características e desafios próprios, que exigem uma equipe com conhecimentos específicos, sem falar na mudança cultural que a adoção da ferramenta pode trazer para a organização.

Abaixo, listamos alguns cuidados básicos que devem ser tomados durante a realização de um projeto de BAM:

  • Limitar o número de gráficos num dashboard: tente limitar o número máximo de gráficos num mesmo relatório,  para um desempenho mais otimizado e melhor ocupação da área disponível. Um número máximo de 4 a 6 gráficos por dashboard é geralmente recomendado.
  • Usar filtros: utilize quando possível filtros, de forma que o usuário possa restringir a quantidade de dados sendo exibida e assim minimizar os recursos de processamento necessários.
  • Avaliar a necessidade de histórico de dados: evite armazenar dados antigos na ferramenta de BAM, para fins de histórico. Caso realmente necessário, considere a criação de um repositório específico para este fim. Mas lembre-se que uma ferramenta de BAM tem o foco no presente (informação em tempo real) e não para ser uma referência para avaliações históricas.
  • Utilizar o recurso de drill-down: o termo drill-down (em português “detalhar”) refere-se à ação de clicar em alguma seção de um gráfico para obter o detalhamento de informações referente àquela seção. Podemos pensar, por exemplo, num gráfico de pizza que mostra a quantidade de solicitações em aberto por região do país. Ao clicar numa fatia, o usuário é direcionado para uma lista de solicitações especificamente daquela região. Assim, procure construir os seus dashboards de maneira a mostrar inicialmente apenas as informações mais abrangentes e relevantes, para que os usuários possam ter um rápido entendimento da situação atual. E então disponibilize a navegação drill-down para níveis com maior detalhamento, que poderão ser consultados se o usuário achar necessário.
  • Avaliar o ambiente de exibição dos dashboards: deve ser avaliado de que forma os dashboards serão acessados. Serão acessados através de desktops e notebooks? Ou através de telas maiores? Frequentemente os dashboards são previstos para serem exibidos em telões/televisores, posicionados em lugares estratégicos no ambiente de trabalho, de maneira que possam ser vistos a uma certa distancia pelos usuários. Então, se for este o caso, será necessário limitar a quantidade de gráficos e  informações sendo exibidas, prestando atenção a detalhes como resolução da tela, disposição dos gráficos, tamanho e cores das fontes utilizadas.

Como vimos, os projetos de BAM tem suas próprias características e desafios, que devem ser levados em consideração durante o planejamento. Levando estes fatores em consideração, não temos dúvida que uma ferramenta de BAM pode se tornar uma ferramenta de inestimável valor para o acompanhamento do seu negócio!

Você se interessou pelo assunto? Falamos mais de BAM no nosso treinamento “Modelagem de Processos para Automação” e oferecemos um treinamento específico da ferramenta “Oracle BAM“. Ambos os cursos são oferecidos pela iProcess Education.

Muito prazer, o CLIENTE! (Visão Outside in e Inside out)

Começamos com uma pergunta direta: QUEM É O CLIENTE?
Parece ser uma pergunta um tanto obvia, mas saber exatamente quem é (ou quem são) os seus clientes é fundamental para atender as suas necessidades.

Poderíamos afirmar que:

“Na perspectiva de BPM, cliente é somente aquele que se beneficia da geração de valor e está externo à organização.” (BPM CBOK 3.0, pag.47)

Mas, de uma forma geral, todos nós somos clientes, pessoas comuns que levantam pela manhã para trabalhar, que fazem compras no mercado, utilizam os serviços da rede bancária, que pagam contas, cidadãos que dependem do transporte público para chegar ao seu destino, ou seja, consumidores!

Todos nós, como cidadãos, por exemplo, somos clientes que dependem dos serviços públicos como o acesso à água e a luz, saneamento, limpeza pública e segurança.

Clientes que muitas vezes não têm as expectativas atendidas!

Ao mesmo tempo, quantas vezes, como cidadãos, somos questionados pelo prestador de serviços para saber o que achamos do serviço prestado?

Organizações estão empenhadas em oferecer o melhor valor agregado aos seus produtos e serviços, só que nesta tentativa, trabalham muito mais focados em otimizar e reduzir custos dos seus processos internos e esquecem de avaliar as expectativas dos consumidores destes produtos e serviços.
Assim, saber quem são seus clientes é o caminho para entender suas necessidades, expectativas e o que eles valorizam, e poder produzir e entregar aquilo que seus clientes esperam.

COMO ERA ANTES

Durante décadas organizações determinaram o que seus clientes necessitavam e definiam como seus produtos e serviços seriam disponibilizados. Até então, o cliente era pouco exigente. O foco era: aumento da eficiência na produção.

Esse cenário, de foco na otimização do processo em detrimento às expectativas do cliente, se percebe concretamente nesta célebre frase de Henry Ford, sobre a fabricação do modelo Ford T:

“O carro é disponível em qualquer cor, contanto que seja preto.”

O objetivo de Henry Ford era tornar o carro acessível a todos, aumentando a procura mas ao mesmo tempo reduzindo custos.

Conforme as empresas foram crescendo, foram surgindo novas oportunidades. As empresas foram criando novos planos de expansão e com isto os clientes começaram a impor o que queriam e como queriam. Sendo assim, as estruturas organizacionais e modelos de negócios começaram a tomar novas formas, mas persistia a visão de “dentro para fora”, ou seja, a busca pela eficiência na entrega de valor ao cliente.

OLHAR DE DENTRO PARA FORA OU DE FORA PARA DENTRO?

“Olhar de dentro para fora”: visão conhecida também por Inside out ou ainda por Foco NO Cliente.

É a visão sob o ponto de vista da organização. Se preocupa com o “de dentro”, com foco em seus produtos e serviços. É a organização que determina o que agrega valor para seus clientes e cria a cadeia de valor idealizado por Michel Porter.

Este modelo fazia sentido em sua época, onde a interação com o cliente não era algo comum, pois este ficava em segundo plano. A preocupação das organizações era em fazer as coisas certas. O foco era a eficiência, o controle de custos e a redução de erros.

Atualmente, as organizações estão focadas muito mais na eficácia, ao grau em que os resultados de uma organização correspondem às necessidades dos seus clientes.
Hoje a exigência está muito maior, principalmente no que se refere não apenas a qualidade ou preço dos produtos, mas principalmente ao atendimento real às suas necessidades.

“Olhar de fora para dentro”: visão conhecida também por Outside in ou ainda por Foco DO Cliente.

É a visão sob o ponto de vista do cliente, se preocupando com o que vem de fora, onde o foco é sempre o cliente. É o cliente que determina através de suas experiências aquilo que é importante para a empresa, o que gera valor para concepção dos seus produtos e serviços. A visão do cliente consiste em conhecer a organização pelo lado de fora, tem a ver com o valor percebido, se o cliente está ou não satisfeito.

O gerenciamento de processos consiste na experiência do cliente como ponto de partida para o desenho e implementação de processos. Os processos são desenhados em torno deste relacionamento do cliente com os produtos, serviços e pontos de contatos (momentos da verdade) que devem ser conhecidos pela organização para alcançar a real necessidade e satisfação de seus clientes.

Mas você pode estar se perguntando, como entender de fato as necessidades do cliente? Existe uma fórmula mágica para isto?

O que existe hoje são técnicas e métodos utilizados para “trazer o cliente” para análise e redesenho dos processos, através de coleta de informações como pesquisas de opinião, avaliação dos comentários e reclamações do SAC, comentários enviados por pessoas através de sites como o “Reclame aqui”, e até mesmo workshops e entrevistas envolvendo o cliente. Redesenho é um repensar sob a ótica do cliente, é uma nova visão do negócio. Isso é transformação (construir processos com foco do cliente).

Não se trata mais de apenas oferecer um produto para um cliente, mas de entender a sua real necessidade. O foco assim é a percepção de valor do cliente, o que ele acha que é importante. Esta experiência de consumo leva o cliente a participar da criação do processo ponta a ponta, e permite a organização identificar atividades, que pela visão de “dentro para fora” (inside out), não seriam identificadas.

Vejamos o exemplo da tão conhecida IBM. Empresa de 103 anos de vida, que já passou por altos e baixos em sua história e ainda está no topo das empresas de TI. Mas como explicar sua longevidade? Como ela pode estar viva e próspera em um setor caracterizado pela inovação e a mudança? Dois pontos nos chamam a atenção: a cultura e a mudança.


Thomas Watson
, fundador da IBM, criou sua empresa baseado em três crenças básicas. Achamos relevante destacar uma delas: “Prestar o melhor serviço ao Cliente”. Tinha por base a satisfação e desejo do cliente, ou seja, a crença é direcionada ao cliente e as suas necessidades.

O segundo ponto relevante e mais significativo foi à busca pela mudança, pela transformação.
Em 1991 foi apresentada como a “Nova IBM”, voltada para a visão do mercado atual e obcecada pela qualidade. Segundo a própria IBM, a mudança foi causada pelo aumento do nível de exigência dos seus clientes, o que gerou a necessidade de criar valor para seus clientes.

A IBM de hoje não se considera uma empresa de tecnologia, mas uma empresa que resolve business problems usando a tecnologia. Segundo a IBM, ela não vende “brocas”, vende ferramentas para produzir “buracos na parede”, a IBM é focada nos trabalhos que seus clientes precisam que sejam realizados.

Quem já assistiu o filme “Quero ser Grande” (Big, 1988) estrelado Tom Hanks, percebe uma ligação da história com a visão “outside in”.

No filme, Josh (Tom Hanks) se torna adulto da noite para o dia, e conhece o Sr. MacMillan, dono de uma empresa que fabrica brinquedos (naquela clássica cena do The Big Piano). Confira aqui a cena do filme.

O dono da empresa comenta com ele sua preocupação de que não estão obtendo boas vendas, e Josh acaba ganhando o emprego porque começa a expor para a empresa a visão do cliente (ele como criança em corpo de um adulto).

Com o foco do cliente, os produtos desenvolvidos pela empresa se tornam muito mais atraentes aos consumidores, e a empresa volta a gerar crescimento.

O foco hoje não pode ser mais o produto ou o lucro que este lhe proporciona, mas a experiência vivida pelo cliente ao consumi-lo. O cliente de hoje procura ser compreendido e ter suas expectativas atendidas. Para a organização fica a responsabilidade de conhecer seu cliente e entender porque ele procura pelo seu produto ou serviço. Conhecer o cliente e atender suas necessidades é um desafio, e deve ser encarado como uma grande oportunidade de crescimento para a empresa e para a geração de novas soluções inerentes ao mercado atual.

BPM como ferramenta para melhoria do nosso dia a dia

Muito se fala sobre modelagem, análise e redesenho de processos para melhorar e otimizar os processos das organizações.

Aqui mesmo no blog já falamos muito destes temas. Em se tratando de organizações tradicionais, contudo, é natural que as iniciativas de BPM sejam voltadas para objetivos mais “ortodoxos”, como por exemplo:

  • Redução de custos (objetivo clássico);
  • Redução dos tempos de execução (também clássico);
  • Melhorar o acompanhamento e controle do processo (extremamente clássico);
  • Melhor atender as necessidades do cliente (este deveria ser o objetivo final de tudo, não é?).

Mas… é possível aplicar também a melhoria de processos para melhorar o meu dia a dia, e a minha interação com as pessoas e empresas que prestam serviços para mim? A resposta: É claro que sim!

Num país com tantas deficiências, onde necessidades básicas muitas vezes não são atendidas, as oportunidades de melhoria saltam aos nossos olhos como… pipocas em uma panela aberta.

Podemos afirmar que o grande benefício, e ao mesmo tempo uma grande fonte de frustração de quem começa a praticar BPM é que isso não muda somente a sua visão dos processos e da sua empresa… Muda também radicalmente a sua visão de mundo, para sempre.

Tenha a plena certeza: após ser pego pela “febre” do BPM, a pessoa vai ser pega adotando técnicas de análise e melhoria de processos em todos os lugares:

  • Na fila do supermercado: pensando que as regras de distribuição dos empacotadores entre os caixas não está clara e bem definida, e precisa ser seguidamente orientada por um supervisor. E que, na sua opinião, este supervisor deveria destinar seu tempo a objetivos mais nobres (como verificar porque um cliente está com cara de zangado discutindo com o caixa ao lado);
  • Na fila de um banco: pensando porque se forma uma fila de 10 pessoas e existe apenas UM caixa atendendo no horário do almoço (justo o momento em que o banco tem mais movimento?);
  • No restaurante: pensando porque a fila está liberada nos dois lados do buffet, mas os pratos não se repetem nos dois lados, e não existe como pegar um prato do outro lado sem ter que entrar na fila de novo;
  • Ao telefone num auto-atendimento: pensando porque eu preciso repetir todo o meu problema cada vez que sou repassado de uma área pra outra, e por que RAIOS sempre pedem pra repetirmos informações que já foram passadas no começo da ligação? Porque preciso ser repassado de uma área pra outra, aliás?

É por isto que ter o hábito de utilizar técnicas de análise e melhoria de processos pode algumas vezes ser frustrante para o praticante de BPM. Pois este praticante passa a ter uma outra visão sobre as coisas, e adquire a habilidade de enxergar processos defeituosos e oportunidades de melhoria a todo momento, muitas vezes com pouco ou nenhum acesso para viabilizar alguma mudança.

Talvez seja neste momento a pior parte, que é ter a coragem de apontar as oportunidades de melhoria, criticar e sugerir. E não somente para as empresas privadas que nos prestam serviços. Para os órgãos públicos também, afinal seu propósito é servir o cidadão, e deveriam ter preocupação fundamental em melhorar seu atendimento.

Nós, profissionais do processos (ou você que está estudando e querendo ser tornar um), muito discutimos o “foco no cliente” ou “foco do cliente” na teoria de BPM, e como sempre deveríamos considerar a visão do cliente para realizar a melhoria em um processo.

Mas se quisermos fazer a diferença não somente para a nossa empresa, mas para a sociedade e o nosso país, temos que dar um passo além: vestir a casaca do analista de processos, enquanto clientes e cidadãos, e ajudar a melhorar todos os processos que temos contato: sugerindo melhorias, criticando, apontando problemas e soluções. E quem sabe, com uma pequena melhoria aqui e outra acolá, isso não pode deixar o seu dia a dia (e o de outras pessoas também) um pouco melhor?

Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2

No primeiro artigo da série (veja aqui) falamos sobre os métodos Pesquisa, Entrevista e Observação Direta. Neste segundo e último artigo da série abordaremos o restante dos métodos utilizados para coleta de informações para o trabalho de modelagem.

WORKSHOP ESTRUTURADO

Workshop estruturado é um método utilizado para a coleta informações através de reuniões com os representantes dos papéis envolvidos no processo, reunindo diferentes pontos de vista, visando o detalhamento e a modelagem do processo de modo interativo.

photo credit: juhansonin via photopin (cc)

Agendamento do workshop

A escolha correta dos envolvidos é crucial para uma reunião produtiva, mas afinal como escolher as pessoas certas para a reunião?

  • Especialistas: Ninguém melhor para explicar um determinado processo do que as pessoas que trabalham nele. São os executores do processo, usuários do sistema ou membros de equipes operacionais com profundo conhecimento sobre certas funções ou operações de negócio. Quando em grande número são representados por usuários-chaves que se fazem presente no workshop. Representados normalmente pelos papéis de Representantes Funcionais ou Gestores Funcionais.
  • Liderança: Outro papel de importância na reunião é o do Dono do Processo, este é o responsável pelo processo ponta a ponta. Defende as prioridades e assegura que o processo atenda às expectativas de desempenho esperado pelo cliente. Não podemos esquecer também do Patrocinador, representado usualmente pela liderança executiva, gestores, diretor ou gerente da área responsável pelo processo. Apesar de não se envolver de forma integral, participa geralmente de reuniões estratégicas que determinam o caminho que o processo irá trilhar. Estes papéis possuem uma visão macro do processo.
  • Facilitador: Normalmente representado pelo Analista de Processos ou Designer de Processos. É o responsável pela condução adequada da reunião e por garantir que todos os participantes sejam ouvidos. Para isto deve ter a habilidade para lidar com pessoas, resolver conflitos e manter o foco no objetivo do workshop.

A divisão apresentada acima contendo especialistas, liderança e facilitador compreende uma abordagem mais estruturada e pode variar de empresa para empresa, levando em conta a sua maturidade em BPM. O mesmo vale para as convenções de nomenclaturas para os papéis descritos.

Outras questões que devem ser levadas em conta para escolha dos envolvidos:

  • O participante do workshop deve ter a competência e o conhecimento necessário para descrever suas atividades e se posicionar quanto suas divergências.
  • Os envolvidos devem ter bom relacionamento, para isto o facilitador deve se informar sobre conflitos de interesses e embates políticos entre gestores e equipes.
  • Disponibilizar uma agenda viável para todos os participantes.

Vantagens

  • Redução do tempo de desenvolvimento do modelo devido ao entendimento comum criado entre os participantes.
  • Resolução de conflitos no momento do workshop.
  • Redução do número de intermediadores evitando futuros problemas de comunicação.
  • Redução do tempo do acompanhamento das partes envolvidas na evolução do modelo final.
  • Facilitador com habilidades de técnicas de modelagem.
  • Facilitador com apoio de Designer de Processos (trabalho em dupla) na modelagem do processo; principais impactos na redução do tempo de execução e validação do modelo com processo aprovado na mesma reunião.

Desvantagens

  • Desgastes em deslocamentos / viagens – Participantes muitas vezes encontram-se em locais físicos distintos.
  • Altos custos de viagens.
  • Conciliar agenda dos participantes.
  • Custo com hora/homem  – 100% do tempo de todos ao mesmo tempo em reunião.
  • Evitar paralisia por análise – Seleção do escopo e escolha do processo e profundidade da análise devem ser definidos com muita clareza.

CONFERÊNCIA VIA WEB photo credit: JulianBleecker via photopin (cc)

A Conferência via web ou Videoconferência como também é conhecida, é um método semelhante ao Workshop Estruturado. Utilizado quando os participantes estão em locais físicos distintos e sem a disponibilidade para viagens.

Vantagens

  • Redução de custos de deslocamentos e viagens.
  • Redução no tempo de deslocamentos entre unidades.
  • Utilizado para se buscar um consenso sobre um mesmo processo desenvolvido em diferentes unidades.

Desvantagens

  • Não funcionam muito bem com grupos grandes.
  • Dificuldade de conduzir a participação individual dos participantes.
  • Baixa qualidade de áudio e vídeo.

Atenção para a infraestrutura tecnológica requerida que dependerá da necessidade de cada projeto/empresa. Alguns pontos devem ser observados:

  • Disponibilidades de equipamentos/periféricos de áudio e vídeo.
  • Qualidade de velocidade de banda da internet para transmissão, disponibilização de vídeo e eventuais imagens, acompanhamento em tempo real do processo que está sendo modelado.
  • Softwares apropriados para conferência.

FAZER EM VEZ DE OBSERVAR

photo credit: ColorTime via flickr (cc)

Método conhecido também como “aprendizado do aprendiz”, muito utilizado em tarefas repetitivas. Consiste em aprender o que é feito e então executar o processo.

Ao ensinar as atividades, podem surgir informações de tarefas e passos que ocorrem de forma inconsciente, isto permite que o observador tenha um conhecimento mais detalhado das tarefas realizadas.

A execução do processo pelo observador pode ajudar a coletar alguns detalhes das atividades que de outra forma não seriam observados. Sempre que possível, é interessante ter um segundo membro da equipe observando o processo de aprendizagem para auxiliar na identificação de detalhes das atividades.

ANÁLISE DE VÍDEO photo credit:  Flickmor via flickr (cc)

Similar à observação direta  (veja mais sobre o método Observação Direta no artigo anterior), a análise de vídeo auxilia na identificação de evidências à distância e permite que o executor realize suas atividades de forma mais natural.

A presença de um equipamento de gravação permite uma adaptação mais rápida do que a de um observador ao seu lado.

Outra vantagem é que os vídeos podem ser mais tarde assistidos pelo executor e este narrar suas atividades e ações executadas fora do campo da lente, isto auxilia na identificação de informações não vistas pelo observador.

SIMULAÇÃO DE ATIVIDADES

photo credit: Wonderlane via flickr (cc)

A simulação de atividades é utilizada para identificar possíveis falhas humanas e desvios na execução do processo. Uma forma de simulação seria, durante a entrevista ou workshop, a realização de uma análise apurada do comportamento de cada atividade do fluxo do processo. Esta análise consiste em avaliar o que dispara esta atividade (entradas), seu resultado (saídas) e regras estabelecidas para execução desta atividade.

 

Como falamos nos dois artigos, cada método tem suas vantagens, desvantagens e o esforço necessário para que possa ser realizado. Questões como tempo requerido, altos custos de viagens, conciliar agenda dos participantes, suporte à infraestrutura tecnológica e habilidades em técnicas de modelagem são apenas alguns pontos a serem observados antes de optar pelo método a ser utilizado no levantamento de informações.

Não há um método único que seja melhor, cada projeto de modelagem ou análise de processos deve considerar quais métodos de coleta de informações são mais apropriados e eficazes para o processo que está sendo estudado.


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

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.

Métodos para levantamento de informações na Modelagem e Análise de Processos

Em projetos envolvendo modelagem e análise de processos de negócio é imprescindível que a equipe tenha a compreensão correta dos processos ponta-a-ponta da organização para uma visão precisa do negócio. Esta compreensão pode ser obtida com uma coleta de informações realizada ao longo do esforço de forma consistente, caso contrário alguma informação importante poderia faltar, e seria difícil fornecer uma visão clara do negócio.

Existem diversos métodos especializados para levantamento destas informações. Falaremos sobre isto em uma série de artigos, trazendo as diversas formas de captura de informações para a realização do trabalho de modelagem.

Neste artigo, iniciaremos falando dos métodos Pesquisa, Entrevista e Observação Direta.

PESQUISA

A pesquisa serve para obter o contexto inicial do processo, serve também para complementar o entendimento do negócio e para preencher algumas lacunas na documentação do processo que não foram obtidas por outros métodos.

Pode ser pesquisado todo o tipo de documento, desde formulários, manuais dos sistemas da empresa, políticas da organização, registros de auditorias, documentação de processos, descrições escritas das partes interessadas e autores do processo, etc.

Esforço: O empecilho fica por conta do tempo requerido para realizar estes levantamentos, que muitas vezes não é suficiente para conciliar diferenças de opinião e informações levantadas versus o trabalho realizado na prática.

ENTREVISTA

Entrevista é um “processo de comunicação fundamental entre pessoas que se caracteriza pela realização direta, face a face, que se estabelece entre o profissional e o usuário” (Ballestero-Alvarez, 1997).

A entrevista é um método muito utilizado para a coleta de informações. Ela pode ser realizada de forma individual ou em grupo, conduzida por um facilitador. Pode ser presencial, por telefone, conferência web ou e-mail.

Participantes: Devem ser entrevistados os integrantes do processo, que contribuem com informações sobre as atividades que executam, assim como seus líderes. Podem também ser pessoas responsáveis pelo desenho, execução e desempenho do processo, não esquecendo daqueles que fornecem entradas ou recebem saídas do processo.

Ponto de atenção: A realização da Entrevista (em grupo) é muitas vezes confundida com outro método, o Workshop.
A diferença básica destes dois métodos é que no caso da entrevista em grupo os participantes limitam-se em falar das suas atividades (seu papel no processo), é algo mais pontual. Por exemplo: Entrevistar três operadores de empilhadeira de um CD (Centro de Distribuição). Ambos operadores realizam atividades referentes a movimentação de porta pallets da área de armazenagem para a área de separação.

Já o Workshop  consiste em reunir diferentes pontos de vista sobre o processo com representantes de todos os papéis envolvidos para discutir o processo. Falaremos mais sobre este método em nosso próximo artigo sobre o assunto.

Vale ressaltar que nada impede que outros métodos sejam aplicados juntamente com a entrevista, servindo assim como complemento para coleta de informações não obtidas com esta técnica.

Perfil do entrevistado: A avaliação do perfil do entrevistado é crucial para uma coleta consistente, portanto antes da escolha do entrevistado, verifique seu nível de atuação dentro da empresa e se o seu papel condiz com o nível de informação exigida.
Por exemplo: Analista marca uma entrevista com o Gestor do Centro de Distribuição para mapear atividades operacionais do setor de coleta de encabidados da sua unidade. Neste caso, o que poderia dar errado? Possivelmente o gestor simplificará as atividades operacionais, e com isto detalhes das atividades poderão ser perdidos, pois só quem executa é que conhece as atividades e muitos problemas que hoje acontecem não serão relatados.
Desta forma, concluímos que a escolha pelo gestor não seria a mais apropriada, pois a definição e manutenção de procedimentos de nível operacional fica em posse do auxiliar de operação, além é claro daqueles detalhes práticos, tarefas e passos executados no dia-a-dia que não são documentados e não passam pelo conhecimento do gestor.

Esforço: A entrevista pode exigir um grande esforço do analista para obter o grau de detalhamento satisfatório, isso deve-se a forte dependência das informações fornecidas pelos entrevistados. Esta dinâmica pode ser ineficiente caso o entrevistado não compartilhe, por algum motivo, as informações de como suas atividades são executadas de verdade. Os motivos são diversos, desde medo do fracasso e reprovação, até o medo da mudança (do novo) ou ter que começar a  fazer diferente de como é realizado hoje (este é um medo cultural). Além disto, a entrevista exige que os entrevistados parem as suas atividades, o que pode trazer dificuldades de agenda.

OBSERVAÇÃO DIRETA

Segundo Lakatos & Marconi (1992), a observação direta intensiva é um tipo de atividade que “[...] utiliza os sentidos na obtenção de determinados aspectos da realidade. Não consiste apenas em ver e ouvir, mas também examinar fatos ou fenômenos que se deseja estudar”.

Observação direta é um método que pode ser definido como um acompanhamento presencial do processo a ser modelado que sujeita o pesquisador a um contato mais direto com a realidade.

Este método auxilia na identificação de evidências revelando comportamentos, atividades e tarefas difíceis de serem lembradas por outras técnicas. Muito eficiente no diagnóstico de oscilações e desvios que ocorrem no dia-a-dia do trabalho.

Participantes: A escolha correta do executor do processo deve representar o nível de desempenho típico para executores daquele processo. Este executor deve entender o impacto de suas tarefas no resultado final do processo ponta-a-ponta, ter uma compreensão (uma visão) do todo e ter critérios para entender se o desempenho de suas atividades são satisfatórias.

Esforço: Para que o observador possa capturar informações consistentes com um grau de detalhamento satisfatório, deve ser levado em conta uma variedade grande de execuções de processos, observação de diversos grupos de executores e locais. Este esforço exige tempo e esforço, o que pode não ser possível em determinados projetos.

Riscos: A presença do observador pode provocar alterações na forma como os atores executam suas atividades, acabando com a naturalidade dos mesmos. Com isto, os atores ao serem observados realizam suas atividades da forma como aprenderam e não como realmente realizam no seu dia-a-dia. Este cenário pode gerar uma visão distorcida, criando falsas impressões da realidade e impactando de forma direta no resultado do processo.

Alguns cuidados podem ser tomados para que este tipo de problema não venha ocorrer, como dar as condições e tempo necessário para que o executor do processo se sinta confortável. Outra solução é realizar um comparativo dos resultados obtidos na observação com resultados anteriores registrados, garantindo assim que o trabalho realizado pelo observador represente a rotina diária do ator do processo.

Em nosso próximo artigo sobre o assunto continuaremos falando dos métodos especializados para levantamento e coleta de informações.
Confira: Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2.

 


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

 

Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Projetos de Modelagem de Processos – Parte 1: Objetivos e Motivadores

A modelagem de processos está sendo muito utilizada pelas organizações para conhecer, documentar e melhorar os seus processos. Porém, as necessidades que levam uma organização a iniciar a modelagem de processos acabam direcionando a tipos de projetos de modelagem com focos diferentes.
Trataremos, neste primeiro artigo da série, dos principais objetivos e motivadores relacionados aos mais comuns tipos de projetos de modelagem de processos.

 

Modelagem para Conhecer o Processo:

Objetivo
  • modelar o processo de modo que a forma como ele é realizado passe a ser de conhecimento dos participantes que executam o processo e da organização como um todo
Motivadores
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Documentação ou Treinamento:

Objetivos
  • documentar o processo para que dúvidas operacionais possam ser diluídas através da consulta ao processo
  • fornecer uma documentação completa para que os seus executores saibam como realizar suas atividades, evitando erros ou demoras devido a dúvidas
  • fornecer uma documentação que facilite o treinamento de novos colaboradores:
    • minimizando o efeito de perdas de colaboradores
    • auxiliando a organização que passe por um processo de expansão
Motivadores
  • processos em que os executores não tem experiência em executá-lo porque:
    • os papéis tem alta rotatividade ou
    • o processo não é executado com frequência por determinados papéis
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Implantação de Auditoria:

Objetivo
  • descrever os processos que serão objetos de auditoria para que exista uma referência comum sobre o que deve ou não ser feito no processo
Motivadores
  • padronização e documentação de processos que precisam ser auditados devido a exigências internas ou externas da organização
Mapeamento de Processos de Toda a Organização:

Objetivo
  • criar um repositório de processo com todos os processos da organização modelados e documentados
Motivadores
  • criar um ponto de partida para as iniciativas de gestão por processos
  • permitir que novas demandas de melhoria de processos possam ser atendidas rapidamente
Modelagem para Padronização dos Processos:

Objetivo
  • garantir que toda a organização executa o mesmo processo
Motivadores
  • demandada por processos executados em mais de um local. Ex.: Processo utilizado em várias unidades geográficas como no varejo ou no sistema financeiro.
  • processos que possuem diferente desempenhos de acordo com o local onde são executados ou das pessoas que os executam
  • aquisição de outras empresas → Necessidade de unificar a operação
  • abertura de novas unidades → Necessidade de replicar o modelo de gestão
Modelagem para o Redesenho de Processos:

Objetivos
  • a modelagem é focada no entendimento da situação atual do processo (AS IS)
  • objetivo não é a documentação do processo e sim o entendimento de
    • quais são suas atividades
    • quais os seus pontos fracos
    • quais os seus pontos fortes
    • quais suas oportunidades de melhoria
  • criar base para executar todo o ciclo BPM de melhorias: Mapeamento, Redesenho, Automação, Implantação e Melhoria Contínua.
Motivadores
  • redução de custos ou perdas do processo
  • processos críticos que, se não forem bem executados, podem gerar um grande impacto na organização
  • processos com metas cronológicas bem delimitadas
  • processos que possuem muitas perguntas a serem respondidas. Ex: Como é feito o processo? Porque acontecem tantos erros? Porque o processo é tão lento? Como posso melhorá-lo? Como meço os indicadores deste Processo?
  • processos com SLA bem definidos
  • melhorar o atendimento ao cliente final
  • expansão organizacional
  • processos inter-organizacionais (B2B)
  • empresa precisa se certificar ou aderir a uma legislação
Modelagem para Automação de Processos:

Objetivo
  • conhecer o processo o suficiente para propor uma versão automatizada que busque aumentar a sua eficiência operacional
Motivadores
  • ocorre quando a organização está satisfeita com o seu processo, mas acredita que ele poderia ser melhorado com o uso da tecnologia
  • organização entende que não precisa necessariamente discutir o processo a nível de negócio, e sim entregar com mais eficiência o processo da forma como atua hoje

Leia também o artigo Parte 2 – Características e Desafios, que trata da profundidade da modelagem, características, desafios e riscos relacionados a cada tipo de projeto de modelagem.

A importância de avaliar a cultura e o medo da mudança na implementação de BPM

Neste artigo vamos abordar alguns dos aspectos mais críticos, e frequentemente ignorados, no que se refere a implementar BPM nas organizações: como a cultura organizacional e o medo da mudança são fatores que podem afetar consideravelmente o resultado desta iniciativa.

Durante a implementação de projetos de BPM, é muito frequente se deparar com obstáculos relacionados à cultura da organização, principalmente no que se refere à forma como as coisas costumam ser feitas. São procedimentos, padrões e ferramentas que se estabeleceram com o passar do tempo, e acabaram virando a única forma conhecida das pessoas de realizar o seu trabalho. Com a realização de um trabalho de análise e redesenho do processo através de uma iniciativa de BPM, então todos os gaps, ineficiências e problemas desta forma de trabalho podem vir à tona. Podemos citar como exemplo um caso clássico na automatização de processos: a substituição de formulários em papel que devem ser assinados manualmente pelos gestores, por formulários eletrônicos em que a aprovação é controlada por um processo automatizado e realizada através de uma lista de trabalho.

É do nosso conhecimento casos em que usuários de negócio ficaram receosos e resistentes pelo simples fato de que as aprovações necessárias não iriam mais ser em papel, ou seja, sem a assinatura “física” do seu gestor. São usuários que não foram suficientemente informados de todos os conceitos por trás de uma aprovação digital, e chegaram a exigir (já numa fase bem adiantada de uso do processo) que os participantes deveriam adicionalmente imprimir o histórico de aprovações e anexar junto a solicitação, para que fosse dado o encaminhamento para a próxima área envolvida. Temos aqui um caso em que um dos maiores benefícios da automatização de processos, que é a economia de papel, foi praticamente anulada simplesmente pelos receios de usuários mal informados.

Uma mudança na forma de como são feitas as coisas pode mexer ainda com questões comportamentais enraizadas na organização, e que podem passar despercebidas até para o mais experiente analista de processos. Podemos citar o exemplo de um solicitante que aproveitava o momento em que solicitava a aprovação do seu gestor (com o formulário em papel em mãos), para sentar com ele na sua sala, tomar um cafezinho e discutir com ele banalidades e o resultado do futebol no fim de semana. E que, de uma hora pra outra, teve esta rotina agradável e esperada (do ponto de vista dele) sendo substituída pela rápida, eficiente e distante aprovação eletrônica. O exemplo pode até parecer exagerado e cômico, mas é um tipo de percepção que de fato ocorre entre os usuários, e é preciso ficar atento.

A resistência a mudanças pode ser um grande impeditivo para o sucesso de projetos de BPM. Se os usuários não forem suficientemente informados e principalmente convencidos da necessidade da mudança, podem virar grandes opositores e chegar ao ponto de boicotar a iniciativa, levando muitas vezes o projeto ao fracasso. Em outro exemplo que ilustra esta situação, uma das pessoas envolvidas na execução de um processo chegou a temer pelo seu emprego, quando descobriu que a automação do processo iria realizar de forma automática muito dos procedimentos que esta pessoa executava de forma manual, procedimentos os quais tomavam boa parte do seu dia. Foi então necessário um trabalho de informação e conscientização com esta pessoa, informando que esta seria direcionada para atividades de maior valor agregado, para que a resistência e o medo da mudança fossem finalmente superados.

Se durante uma iniciativa de BPM as organizações optarem por ignorar a avaliação da cultura interna e não realizarem uma etapa de gerenciamento das mudanças com todos os envolvidos, certamente poderá se esperar como resultado uma resistência muito grande e, em casos extremos, até o cancelamento da iniciativa.

Evitando as armadilhas mais comuns em projetos de otimização de processos

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, os esforços de otimização devem “reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um custo mais baixo e com mínimo de impacto ambiental”.

A otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman explora as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:

1. Falta de clareza sobre onde começa e onde termina o trabalho

Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.

A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.

Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.

Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.

2. Usar indicadores (KPIs) inadequados

Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada.

Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:

  • não está relacionado ou é impactado muito levianamente pelo processo de negócio;
  • pode gerar interpretações diferentes;
  • não é impactado apenas pelo processo, mas também por  fatores externos;
  • não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.

3. Falta de apoio do dono do processo e da alta gestão

O Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio.

Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.

Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.

4. Não adotar as mudanças no processo

É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.

Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução

Holterman aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.
Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management Sustem).  Para mais informações do que esperar da implementação de um processo em um BPMS, leia nosso post “Benefícios da Automação de Processos“.

E veja no artigo “Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!” que avaliações recomendamos antes da decisão por automatizar um processo de negócio.