Problemas comuns na modelagem de processos em BPMN – I – Atividades de transferência do processo

Vamos iniciar hoje uma série de artigos que pretendemos publicar ao longo dos próximos meses, falando especificamente de erros, problemas e inconsistências básicas de modelagem, comuns de ocorrer quando começamos a modelar processos e ainda não conhecemos muito bem a notação BPMN.

Pra começar, vamos falar de uma questão muito frequente, que se refere ao encaminhamento de um papel do processo para outro. Vamos imaginar um processo de Viagens, que foi descrito pela área de negócio da seguinte forma:

  1. Um colaborador solicita a viagem
  2. Solicitação de viagem é encaminhada (atenção especial ao uso desta palavra) para uma área interna chamada “Administrativo”, que tem a responsabilidade de pesquisar e mandar cotações da viagem para o solicitante
  3. Cotações são então encaminhadas de volta para o Solicitante avaliar
  4. Se a cotação for aprovada, processo é direcionado novamente para setor Administrativo comprar os tickets, do contrário processo é direcionado de volta para o setor Administrativo refazer as cotações

Agora veja como o modelador decidiu, inicialmente, representar este processo:

Note que no caso da primeira transferência do processo, do papel “Solicitante” para o papel “Administrativo”, foram criadas 2 atividades:

  • Uma atividade na raia do “Solicitante”, chamada “Encaminhar Viagem para Cotação para Administrativo”
  • Uma atividade na raia do “Administrativo”, chamada “Receber Viagem para Cotação do Solicitante”

O mesmo comportamento foi modelado posteriormente, na transferência do papel “Administrativo” para o papel “Solicitante”, com as atividades “Encaminhar Cotações para Solicitante” e “Receber Cotações do Administrativo”, respectivamente.

Este trecho do processo não está errado do ponto de vista da notação BPMN. Mas o que temos aqui, no entanto, são atividades que na prática não precisariam existir. O modelador optou por explicitar a passagem de bastão de um papel a outro através de atividades de transferência do processo, mas isso não é necessário: em BPMN, o próprio fluxo de sequencia já tem o papel de representar/realizar esta transferência de responsabilidade dentro do processo. Neste caso, como ficaria o desenho do processo ajustado? Veja a seguir:
Perceba que com esta mudança, deixamos o processo mais simples e limpo, ao mesmo tempo mantemos o comportamento esperado.

O conceito de utilizar apenas fluxos de sequência para representar a transferência de atividades dentro do processo costuma se aplicar mesmo que exista, de fato, um encaminhamento físico sendo realizado. Por exemplo, este processo de viagens poderia ser realizado em papel, implicando que o solicitante tivesse que levar fisicamente a solicitação impressa e assinada para o setor Administrativo. Mas mesmo neste caso não seria necessário modelar as atividades de transferência. Caso fosse necessário ressaltar este aspecto de encaminhamento físico de algo, poderiam ser utilizados outros recursos para representar, como adicionar uma anotação ao processo ou documentar esta característica do processo nos procedimentos das atividades.

Um cenário em que poderia ser necessária uma atividade para encaminhar ou receber o processo seria num caso em que as atividades são reconhecidamente manuais, realizadas no plano físico, e que possuem procedimentos adicionais, como protocolar a chamada do documento esperado, carimbar, etc. Por exemplo, num processo logístico poderíamos ter uma atividade da área de “Recebimento” chamada “Enviar material para Estoque”, onde “Estoque” é uma área da organização:

Note que, em linhas gerais, continuamos falando do mesmo exemplo citado no Processo de Viagens: a passagem de bastão de uma área para outra. Se o ato de encaminhamento físico do material de um lugar para outro envolve procedimentos adicionais e tem um tempo de execução relevante (vamos imaginar neste caso uma grande planta industrial, em que seria necessário percorrer a distância entre um setor para outro), ou seja, a atividade consome efetivamente recursos, então neste caso faria mais sentido criar uma atividade de transferência.

Fique ligado para outros artigos desta série no futuro! ;-)

BPMS na nuvem – uma visão geral

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BPM em tempos de crise econômica

Como todos estão sentindo muito bem na pele neste ano de 2015, estamos passando por uma grande crise econômica no Brasil, que promete uma continuidade nos próximos anos.

Nestes momentos de crise as organizações são forçadas a rever seus investimentos e estratégias, para se adaptar a um novo cenário que, para a maioria delas, é negativo. Digo “maioria delas”, porque sempre há quem lucre ou cresça com a crise, enxergando novas oportunidades e evoluindo.

O fato é que infelizmente a crise está aí. Como ficam os projetos BPM neste cenário? Como fica a situação dos profissionais de BPM? Poderiam eles sofrer também os efeitos da crise, com cortes de vagas e cancelamentos de projetos?

Da nossa experiência, infelizmente ainda nos deparamos com a percepção de que BPM é um gasto, e não um investimento. Isto geralmente acontece em empresas que não tiveram uma boa experiência em seus projetos de BPM (por diversos motivos), pela falta de maturidade em Gestão Por Processos ou por não ter vislumbrado um bom retorno em relação ao investimento exigido.

Nos momentos de crise, as empresas precisam revisitar e ajustar sua gestão e processos, serem inovadoras, cortar custos e descobrir como “fazer mais com menos”. Sim, este clichê tão disseminado, mas que continua mais válido do que nunca, em tempos de crise econômica e discussões sobre sustentabilidade.

É neste momento que a prática de BPM dá o apoio fundamental para que a empresa consiga atingir estes objetivos. Alguns exemplos:

  • A partir da etapa modelagem de processos se obtêm todo o conhecimento dos processos de negócio;
  • A partir da etapa de análise de processos se obtêm o conhecimento de quais são os problemas e pontos fracos dos processos;
  • A partir da etapa de redesenho de processos são analisadas e definidas as melhorias e inovações necessárias, que serão implementadas e implantadas nos processos;
  • A partir do monitoramento de processos se verificam se os resultados desejados estão sendo atingidos.

Ciclo BPM

Assim, BPM tem o poder de “armar” (no bom sentido) a organização com toda a informação necessária que ela precisa para se adaptar a crise e aos novos tempos, mudar e inovar com rapidez. Sem falar de, obviamente, sobreviver.

Em países em desenvolvimento como o Brasil, por sua série de deficiências, os projetos de BPM tem o potencial de atingir níveis de melhoria que não seriam possíveis em países desenvolvidos, que contam com metodologias e práticas de gestão bem estabelecidas, que contribuem para a execução dos processos com eficiência. Agora, se estamos falando de um país em desenvolvimento E em crise (Brasil, alguém?), então as possibilidades da prática de BPM são inúmeras.

Então, quando estiver analisando o que precisa ser feito para adequar a sua organização à crise que nos encontramos, olhe com atenção para profissionais e projetos de BPM: eles tem o potencial de oferecer os recursos e subsídios que a organização precisa para enfrentar e superar a situação.

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.

BAM – Uma visão geral

Em um artigo anterior, tivemos uma breve explicação sobre uma ferramenta de BAM que pode ser utilizada para realizar o monitoramento de atividades do negócio.

Achamos que é hora de aprofundar um pouco mais este conceito. Então vamos começar novamente do básico: O que exatamente é o BAM?

BAM é a sigla para Business Activity Monitoring, que é uma tecnologia que permite realizar o monitoramento em tempo real de indicadores de desempenho da empresa. Isso possibilita a tomada de decisão de uma forma mais ágil, a partir da análise desses indicadores. Existem ferramentas de BAM que permitem, inclusive, a execução de planos de contingência baseado em gatilhos previamente definidos, como por exemplo o envio de alertas por e-mail quando um determinado indicador está fora dos limites definidos.

Algumas características importantes deste tipo de tecnologia:

  • É voltada para a ação imediata a partir do acesso à informação;
  • BAM é focado no que está acontecendo, não o que aconteceu, ou pode acontecer;
  • BAM fica, desta forma, posicionado entre o foco histórico e analítico do BI e o planejamento futuro de negócio do CPM (Corporate Performance Management).

Com uma ferramenta de BAM é possível, por exemplo:

  • Monitorar processos:
    • Acompanhar as etapas;
    • Identificar problemas ou gargalos;
  • Realizar agregações de dados provenientes de diferentes sistemas:
    • Realizar médias, somas, agrupamentos, cálculos;
  • Processar eventos complexos:
    • Correlação de eventos isolados;
    • Identificar ameaças e oportunidades;
  • Obter informações de contexto:
    • Acompanhar desempenho histórico;
    • Evolução da média;

Normalmente as ferramentas de BAM são oferecidas em ambiente Web, desta forma facilitando o acesso.

Uma ferramenta de BAM disponibiliza uma interface gráfica para exibição de dados diversos de negócio, normalmente em um formato de dashboard (ou simplesmente um “relatório”).

Dashboard é o termo utilizado para designar uma série de gráficos que são visualizados de forma conjunta, onde cada gráfico pode ser de um tipo diferente (ex: gráfico de pizza, gráfico de barra), cada qual exibindo informações relacionadas a uma determinada informação/indicador de negócio. Normalmente um dashboard irá exibir informações relacionadas a um determinado contexto/área de negócio, como por exemplo indicadores relacionados a área de logística ou a área de suporte de TI. Veja um exemplo de dashboard na imagem abaixo:
A arquitetura de um produto BAM pode variar de acordo com a ferramenta. Podemos, no entanto, descrever a arquitetura usual da seguinte forma:

  • Interface de desenvolvimento: é a interface que permite o desenvolvimento dos gráficos pelos desenvolvedores e a definição dos dados pelos arquitetos;
  • Interface de apresentação: é a interface dos usuários finais com a ferramenta, permitindo a visualização dos dashboards implementados;
  • Base de dados:  é o repositório das informações que são exibidas na camada de apresentação do BAM. Muito embora as fontes dos dados exibidos no BAM tenham origem sempre em outros sistemas (ex: BPMS, ERP, Banco de Dados, etc), as ferramentas de BAM normalmente possuem uma base de dados própria para armazenamento destas informações, assim diminuindo a necessidade de buscar as informações a todo momento nos sistemas de origem;
  • Camada de integração: é a camada que permite a integração da ferramenta de BAM com outros sistemas e fontes de dados, para armazenamento na base de dados própria da ferramenta;
  • Interface de administração:  se encarrega, por exemplo, da definição de usuários e perfis/restrições de acesso, bem como integrações com repositórios de usuários existentes (ex: AD, LDAP);
  • Camada de Monitoramento de Alertas/Ações: em ferramentas de BAM que a possuem, é responsável por verificar a alteração e desvio dos valores dos indicadores e disparar ações de tratamento  (ex: envio de e-mail ou SMS de alerta)

Um dos principais aspectos relacionados a uma ferramenta de BAM é que a ferramenta não é fonte/origem de dados, ou seja, ela não “cria” nenhuma informação, mas apenas consolida e exibe dados provenientes de outros sistemas ou fontes de dados. Neste sentido, temos normalmente 2 cenários:

  1. Ferramenta de BAM que faz parte de uma suite de BPMS: o BAM é um dos módulos da solução de BPMS. Neste caso, a ferramenta está habilitada a exibir informações provenientes dos processos automatizados na solução.
  2. Ferramenta de BAM que é um produto independente:  neste caso o produto normalmente tem uma arquitetura mais robusta e abrangente, permitindo assim que os dados provenham de diferentes origens, também podendo ter integração nativa com ferramenta de BPMS. Alguns exemplos de origens de dados que podem ser enviados para a ferramenta de BAM:
    • Dados de aplicações, transições de estado;
    • RFID e sensores;
    • Sistemas de mensagens (JMS, MQSeries, etc);
    • Bancos de Dados;
    • ERPs;
    • Sistemas legados diversos;
    • etc;

Bons resultados no monitoramento da atividade do negócio com BAM não dependem apenas da ferramenta, mas da definição de bons indicadores, buscando a visão equilibrada de indicadores direcionadores e indicadores de resultados. A definição de medidas, métricas e indicadores já foi tema de artigo em nosso blog. Confira em: http://blog.iprocess.com.br/2014/05/medidas-metricas-e-indicadores/

Em futuros artigos, vamos falar dos benefícios na utilização de uma solução de BAM, bem como dos principais passos e cuidados que devem ser tomados para iniciar projetos neste tipo de tecnologia. Fique ligado!

 

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?

Projetos de Modelagem de Processos – Parte 2 – Características e Desafios

No primeiro artigo da série, vimos os principais tipos de projetos de modelagem de processos, e quais seus objetivos e principais motivadores.
Neste segundo e último artigo vamos descobrir, para cada tipo de projeto de modelagem de processos, qual é o nível de profundidade da modelagem, desafios e riscos (se for o caso) envolvidos.

Modelagem para Conhecer o Processo:

Profundidade da Modelagem:

  • o suficiente para que as atividades do processo e o seu objetivo sejam compreendidos.
  • que permita a identificação das responsabilidades atribuídas ao longo do processo

Desafios

  • eventual resistência dos usuários do negócio em revelar o conhecimento que possuem do processo
  • entender todo o escopo do processo e suas peculiaridades quando a organização não tem uma visão clara de onde ele passa

Modelagem para Documentação ou Treinamento:

Profundidade da Modelagem

  • todas as atividades devem ser documentadas com seus procedimentos detalhados
  • dúvidas comuns e regras de negócio devem ser descritos
  • documentos de apoio deve ser identificados e apontados
  • suas atividades são detalhadas em nível de procedimentos, criando-se uma documentação a nível operacional

Desafios

  • perceber quais informações serão efetivamente procuradas pelos usuários quando eles tiverem uma dúvida
  • organizar a documentação de modo que seja intuitiva para quem estiver aprendendo sobre o funcionamento do processo
  • elaborar uma documentação didática para quem não conhece o processo

Modelagem para Implantação de Auditoria:

Profundidade da Modelagem

  • processos são mapeados, detalhados e documentados o suficiente para que:
    • possam ser padronizados
    • expectativas sobre cada atividade estejam bem claras
    • sejam definidos critérios claros e objetivos de avaliação e medição
    • sejam definidas evidências objetivas que serão avaliadas durante a auditoria

Desafios

  • mudanças nesses processos exigem:
    • aprovação formal dos gestores do processo
    • comunicação das alterações a todos os que executam o processo
    • ciclo de treinamentos para reapresentação do processo

Mapeamento de Processos de Toda a Organização:

Profundidade da Modelagem

  • costumam ser menos detalhados do que processos para auditoria ou treinamento
  • envolvem mais o desenho do processo que a descrição detalhada de cada atividade

Desafios

  • garantir que todos os consultores documentem no mesmo nível de detalhe
  • sentimento que projeto termina quando todos os processos foram entregues (na verdade, este deveria ser o início do ciclo)
  • manter os processos vivos e atualizados
  • base de processos não cair em desuso alguns meses após o projeto
  • justificar o retorno do investimento neste tipo de projeto sem um motivador mais objetivo e com um ROI bem definido.

Riscos envolvidos

  • mapear somente por mapear, sem uma continuidade ou objetivo específico
  • definir uma política de governança para garantir a atualização dos processos
  • definir responsáveis pelos processos e fazer que os mesmos garantam a sua atualização

Modelagem para Padronização dos Processos:

Profundidade da Modelagem

  • detalhar atividades e procedimentos o suficiente para que o mesmo possa ser replicado. Via de regra, no mínimo, no mesmo nível do aplicado na documentação ou treinamento.

Desafios

  • unificar a forma como o processo é executado quando o mesmo é executado de formas distintas em cada local
  • diminuir a resistência à mudança daqueles que acreditam que a sua forma é a melhor
  • perceber as peculiaridades regionais que efetivamente exigem que o processo tenha que ser executado de forma diferenciada

Modelagem para o Redesenho de Processos:

Profundidade da Modelagem

  • o mínimo possível, desde que este mínimo seja o suficiente para o entendimento do processo e seus problemas
  • não envolve a documentação operacional do que é executado

Desafios

  • vencer a resistência das pessoas que não desejam a mudança
  • enfrentar o boicote daqueles que não querem expor os problemas do processo devido às atividades que eles executam

Modelagem para Automação de Processos:

Profundidade da Modelagem

  • entendimento é mais detalhado do que na modelagem para o redesenho
  • os resultados esperados de cada atividade não são alterados. Não há mudança no “o que é feito” em cada atividade do processo. Assim, a situação atual deve ser detalhada a nível operacional.
  • ocorre mudança, contudo, no “como é feito” cada atividade.
  • é desenvolvido o modelo to-do, que melhora o processo com tecnologia
  • atividades manuais passam a ser automáticas
  • prazos passam a ser controlados de forma proativa
  • é implementada a garantia de integridade dos processos

Desafios

  • garantir que realmente o processo é eficaz e atende aos objetivos da organização.
  • modelar todas as regras de negócio no nível de profundidade necessário.

É possível perceber que cada projeto tem as suas particularidades, e estas devem ser levadas em consideração durante o planejamento do projeto, para que o êxito seja obtido!

 

 

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.