Processos em notação VBPMN - parte 4 (final)

Nos últimos três posts vimos, rapidamente, uma forma de modelar um processo de trabalho usando a notação VBPMN. Diferentemente do que costuma ocorrer em nossos modelos tradicionais, algumas diferenças (e, em meu modo de ver, vantagens) que tal abordagem apresenta são:

- a representação explícita dos valores / resultados envolvidos no processo, dando origem a diagramas que, de fato, expressam cadeias de valor;

- o início da construção dos modelos justamente a partir dos resultados a serem gerados, e não de uma visão interna;

- a caracterização dos resultados / valores, por meio de descrições dos estados que julgamos serem necessários para sua utilização e para alcance dos objetivos do processo;

- a diferenciação que fazemos dos papéis assumidos localmente pelos valores dentro de um processo, ou seja, se são insumos (a serem transformados), referências (a serem observadas na transformação) ou recursos de infraestrutura (consumidos, no todo ou em parte);

- a montagem das cadeias de valor no sentido inverso ("do fim para o começo", ou "outside-in"), por meio da sincronização das condições esperadas dos elementos do processo com as características que os responsáveis por sua geração relataram;

- o estabelecimento de planos de ação / contingências a partir de diferenças identificadas entre o que é necessário e o estado atual dos elementos de processo, dentre outras.

Há alguns aspectos finais igualmente importantes em tal abordagem que merecem aqui o nosso registro.

Se a modelagem é uma etapa fundamental em nosso método de buscar representar a realidade, existem outros três momentos de minimização de riscos que devem ser considerados por um gestor de processos responsável. O primeiro deles é a simulação do processo, no qual imaginamos comportamentos estimados que os elementos de nossa cadeia de valor podem assumir e vemos quais seriam os respectivos resultados. Por exemplo, imaginamos que quando implantarmos nosso processo de atendimento teremos um fluxo-base de 10 pessoas buscando acesso ao mesmo tempo, cada uma levará uma média de cinco minutos para preencher o formulário-cadastro e que trinta por cento delas precisarão de assistência por chat on-line (é apenas um exemplo simplificado). Será que tal carga fará com que nosso processo atenda satisfatoriamente o que se espera dele? E se esse fluxo demonstrar que precisamos ter mais atendentes que o atualmente contratado? Ou ainda, e se ao invés de dez acessos simultâneos tivermos cem (ou mil) pessoas concorrendo pelos recursos - nossa rede estará preparada? Devemos implantar o processo como originalmente desenhado, correndo o risco de tais efeitos indesejados, ou mudá-lo imediatamente? A simulação permite tais correções e ajustes antes dos impactos reais que podem comprometer nossos resultados e nossa imagem.

A emulação é uma sofisticação da simulação pois, em vez de dados apenas estimados, começamos a incluir dados reais em nosso modelo. Por exemplo, por que não criarmos o formulário-padrão que previmos no processo e pedirmos para um grupo de cem colegas de nossa unidade para preenchê-lo, como se ele já estivesse no ar? A previsão de tempo médio de cinco minutos para o preenchimento se confirmou? Ou precisamos melhorar o formulário (ou mudar nossas expectativas)?

Simulando e emulando um processo antes de sua implementação, certamente estaremos mais certos do que irá ocorrer com os resultados quando formos para a fase de "encenação", ou seja, para a vida real do processo. É muito comum, nesses casos, implantarmos versões-piloto de nosso processo para que possamos ainda corrigir algo que não tenha sido percebido nas fases de modelagem, de simulação e de emulação.

Por último, gostaria de apresentar um recurso muito interessante presente na ferramenta que usamos para modelar o processo em questão, que é o algoritmo de "fatiamento" de um processo (o chamado "slice and trace", na solução PArchitect). O que tal algoritmo realiza é a possibilidade de gerar processos a partir de uma cadeia de valor (processo-base). Em outras palavras, se tomarmos nosso mapa do processo de atendimento como base, podemos escolher qualquer de seus valores representados e (mantendo, claramente, o processo original), "fatiar" a cadeia de valor em subprocessos específicos.

Processo original, com o resultado "Documentos digitalizados e enviados para a central" em destaque

Por exemplo, podemos pedir para o aplicativo obter o subprocesso necessário para gerar o resultado "Documentos digitalizados e enviados para a central", representando apenas os componentes que estão diretamente vinculados à sua existência - veja a figura abaixo.

Subprocesso necessário para gerar o resultado em destaque

Da mesma forma, podemos obter o subprocesso que passa a existir a partir da presença de "Documentos digitalizados e enviados para a central" - o que chamaríamos de "traço" do resultado em questão, visto na figura a seguir.

Subprocesso gerado pelo resultado em destaque

Ou ainda, podemos chegar ao subprocesso que contém o resultado "Documentos digitalizados e enviados para a central", em ambos os sentidos, fazendo uma gestão mais próxima daquele pedaço da grande cadeia de valor que nos interessa no momento. Apenas para lembrar, uma vez que fatiamos um processo maior, além de manter o original salvo, temos à nossa disposição toda a sorte de funcionalidades aplicadas também ao subprocesso (ou seja, podemos simulá-lo e emulá-lo antes da implantação). A figura a seguir demonstra o subprocesso bi-direcional que contém o elemento "Documentos digitalizados e enviados para a central".

Subprocesso que contém o resultado em destaque ("Documentos digitalizados e enviados para a central")

Até o próximo post !!!