Exemplo de variáveis de contexto com impacto em processos


Como exemplo de mudanças contextuais que exigem flexibilidade em processos, consideraremos o processo de “atendimento ao cliente” de uma grande seguradora australiana. O processo de atendimento lida com diferentes reivindicações de seguro (ramos elementares, auto etc.), as quais são apresentadas através do telefone. O processo é mantido por duas centrais de atendimento operando para duas entidades organizacionais distintas (Brisbane e Sydney). Ambas as centrais são similares em termos de volume de chamadas, tempo médio de duração da chamada, número de atendentes e desempenho desejado. As principais diferenças entre as duas centrais são os sistemas de TI utilizados, as localizações e os modos de operação (24h frente a uma atuação entre 9:00 e 17:00).

Enquanto esse processo funciona de forma suave em um contexto de negócio usual, a organização recebe um número crescente de durante a temporada australiana de tempestades (Outubro-Março). As tempestades causam estragos e aumentam o número de chamadas semanais em mais de 20.000. Essa mudança no contexto do negócio não somente sobrecarrega ambas as centrais de atendimento como também os processos de back-office relacionados à avaliação e administração dessas solicitações. Com o intuito de lidar com o crescente tráfico de chamadas, a seguradora utiliza um “sistema de resposta baseado em eventos”4 que categoriza a situação baseada na severidade da tempestade. Baseada nas diretrizes deste sistema, a primeira categoria inclui tempestades e inundações localizadas e leva a um aumento no volume de ligações de 10-50% acima da média e um tempo de espera de 5-10 minutes por um período de no mínimo duas horas. A segunda categoria é disparada quando há ventos fortes, granizo e danos estruturais. Isso leva a um aumento do tempo de espera para 10-30 minutos e o volume de ligações é 50-100% maior que o previsto por pelo menos duas horas. A terceira categoria cobre danos generalizados, levando a tempos de espera superiores a 30 minutos.

Para cada uma dessas categorias foi definida uma estratégia de resposta individual, utilizando-se de recursos externos adicionais assim como alterações no procedimento de atendimento às reclamações. Em primeiro lugar, recursos adicionais são utilizados através da realocação de funcionários de outros departamentos (por exemplo, vendas) e contratação de empregados temporários. Como essas pessoas não receberam treinamento igual ao dos atendentes profissionais, seu desempenho, em termos de tempo de atendimento médio, é inferior. Em segundo lugar, utiliza-se uma forma racionalizada de atendimento de chamadas com o propósito de reduzir o tempo médio de atendimento e assim diminuir o tempo de espera na fila. Neste “processo de atendimento veloz”5, apenas uma quantidade reduzida de informação é coletada do requerente. Isso leva a um tempo de atendimento médio de 380 segundos para atendentes experientes e 450 segundos para empregados adicionais, abaixo da média usual de 550 segundos. Um mecanismo de lidar com os diferentes desempenhos desses dois tipos de atendentes é o redirecionamento das chamadas, transferindo casos novos e diretos para a força de trabalho adicional, enquanto situações mais complexas são transferidas para agentes experientes.

Dois gerentes responsáveis pelo serviço de atendimento e os processos de back-office relacionados avaliam a severidade das condições climáticas, por exemplo, ou seja, eles monitoram o contexto relevante a esse processo de negócio e disparam as diversas categorias, que levam a diferentes variações no processo.

Esse exemplo mostra como uma mudança no contexto exige uma adaptação flexível do processo. Essa mudança pode ser prevista e é desencadeada quando ocorrem alterações relevantes no contexto (por exemplo, alterações climáticas). As técnicas de modelagem atuais, entretanto, não fornecem suporte para modelagem do contexto relevante. Uma atividade que pode ser observado freqüentemente na prática da modelagem é que variáveis contextuais relevantes se tornam parte explícita do fluxo de controle, levando a pontos de decisão como “Checar se processo ocorre na temporada de tempestades”. Tal consideração de fatores externos leva a extensão desnecessária do modelo, mistura run-time individual com decisões build-time e tende a reduzir a aceitação dos modelos de processos pelos usuários finais que não estarão envolvidos com tal decisão na execução diária e usual do processo. Um modelo de processo operacional deve focar no fluxo de controle interno; informação relacionada ao contexto subjacente deve, preferencialmente, ser modelada de uma forma que possa ter impacto em diversos processos e outros modelos (por exemplo: modelo organizacional).

Outro exemplo para contexto seria o impacto do local. Enquanto localização como fator contextual é amplamente discutido como parte da pesquisa em aplicações móveis [11, 12], esta tem implicações ainda mais amplas em gestão de processos. Usualmente, o impacto da localização na execução de um processo é explicitamente capturado em um modelo de processo, por exemplo, ao incluir um ponto de decisão como “Checar o estado em que o processo ocorre”. Novamente, informação a respeito da localização deveria, preferencialmente, ser “terceirizada” a um modelo dedicado à captura de informações contextuais relevantes. A principal vantagem de capturar informação sobre o contexto externamente ao processo é o potencial de construir uma biblioteca de variáveis contextuais, a qual pode ser mantida e estendida, contrário à informação sobre o contexto que está enterrada em diversos modelos de processos.

Considere outro exemplo. Aplicações de internet banking permitem operações intercontinentais até certo limite. A quantia máxima transferível é orquestrada pelas respectivas legislações dos países envolvidos. O processo de “transferência de valores intercontinental” contém, dessa forma, uma regra de negócio que depende do contexto. A regra de negócio r é uma função do contexto c [r=f(c)].

O modelo de processo retratado na Fig. 1 adere ao princípio de manter a informação do contexto externa ao processo. O modelo meramente captura uma regra de negócio genérica, e um editor de regra de negócio separado especifica a regra como dependente de alguma informação do contexto (ou seja, país, moeda e limite). A informação dependente do contexto é descrita de forma ortogonal ao processo. Como um exemplo, um editor de regra de negócio poderia especificar espaços reservados para variáveis de contexto relevantes, cujos valores poderiam ser armazenados em uma biblioteca de contextos. Quando um processo é instanciado, os valores relevantes são atualizados na respectiva regra de negócio e o processo pode ser promulgado dentro deste contexto particular. Tal abordagem iria seguir o conceito de retratar a regras de negócio em diferentes visões; veja, por exemplo, [13].

No entanto, contrastando com tal abordagem, também pode ser observado como organizações com operações globais tentando aumentar o número de regras de negócio independentemente do contexto através de iniciativas de padronização internacional de processos. Nesses casos, organizações buscam identificar e capturar regras de negócio que são independentes de um dado contexto (ou que devem ser promulgadas independentemente do respectivo contexto), visando captação mais ampla do processo por vários contextos. Todavia, para que se possa racionalizar processos através de contextos mesmo nesses cenários, é necessário que, primeiramente, sejam identificadas as partes dos processos que precisam ser individualizadas localmente, por causa do impacto do contexto em seu projeto e execução.





_____________________________

4NT: no original, “event-based response system”

5NT: no original,“rapid lodgment process”