A próxima evolução na melhoria do processo de negócios

Tabela de hyperlinks

Resumo e 1. Introdução

2. Antecedentes e trabalho relacionado

3. Método de pesquisa

4. Resultados

5. Discussão

6. Conclusão e referências

Organizações de todas as indústrias e tamanhos realizam várias combinações de atividades para alcançar os resultados desejados, podem ser a produção de bens físicos ou a prestação de serviços. Essas combinações de atividades são chamadas de processos de negócios [1]. Eles geralmente são padronizados e documentados, o que significa que cada vez que uma organização tenta alcançar um resultado específico, eles usam uma combinação semelhante de atividades. Esse processo de negócios padronizado é frequentemente modelado graficamente com o modelo e a notação do processo de negócios (BPMN) [22]. BPI é uma parte central do BPM [6]e também um tópico central deste estudo. O ciclo de vida tradicional da BPM (ver áreas não azuis e seta pontilhada da Figura 1) é geralmente seqüencial [6] e não considera falhas como “cidadãos de primeira classe”. Isso significa que as falhas não são consideradas uma parte necessária da melhoria e avaliadas sistematicamente, mas sim um incômodo causado pelo planejamento insuficiente na fase de reprojetação; E se a falha acontecer, todo o ciclo de vida deve ser repetido.

Uma abordagem mais abrangente para avaliar os efeitos da mudança é o teste AB. O principal objetivo do teste de AB é determinar rapidamente se uma mudança específica em um componente do sistema melhorará as métricas importantes de desempenho [2]. A versão inicial e atualizada do componente são testadas em paralelo usando experimentos randomizados em um ambiente de produção (A vs B). A nova versão geralmente é disponibilizada apenas para um grupo selecionado de consumidores, limitando quaisquer possíveis impactos adversos. O método surgiu como uma abordagem in style ao atualizar sistemas de software program de negócios a consumidores [11].

Uma abordagem particularmente dinâmica do teste de AB pode ser facilitada por RL. Embora a aprendizagem supervisionada tenha como objetivo aprender a rotular elementos de uma coleção de dados rotulados, e o aprendizado não supervisionado tenta encontrar estruturas ocultas em dados não marcados, a RL tem o objetivo de otimizar o comportamento de um agente de software program baseado em uma recompensa numérica em um ambiente interativo [26]. Na RL, o agente está situado em um ambiente específico e precisa decidir sobre uma ação. Essa ação é então avaliada e uma recompensa é calculada com base na consequência da ação. O objetivo do agente é maximizar a recompensa whole que obtém. Aprender quais escolhas fazer em que situação acontece, essencialmente, através de uma abordagem sistemática de tentativa e erro [26].

Como mencionado acima, a abordagem seqüencial do ciclo de vida tradicional do BPI falha em reagir rapidamente às hipóteses de melhoria que são falsificadas na realidade. Esta é uma falha essential: a pesquisa sobre o BPI mostrou que 75 % das idéias do BPI não levaram a uma melhoria: metade delas não teve efeito e um quarto até teve resultados prejudiciais [7]. Esse problema pode ser observado entre os domínios: em um estudo realizado na Microsoft, apenas um terço das idéias de melhoria do web site realmente teve um impacto positivo [12]. Além disso, comparar o desempenho do processo antes e depois da implementação é problemático por si só, porque a mudança de fatores ambientais pode ser o principal fator de alterações no desempenho do processo (ou falta delas). Para mitigar esses problemas, [24] propõe o uso do teste AB ao fazer a transição da análise para a fase de implementação. Isso significaria que a versão reprojetada é implantada em paralelo à versão antiga do processo, permitindo uma comparação justa. Como o teste de AB não é tradicionalmente usado em um ambiente de alto risco e de longa duração como BPM, os autores [24] Aplique RL para facilitar o teste dinâmico. Com algoritmos RL, nós podemos

Tomar decisões com base nos dados obtidos mais rapidamente, por solicitações de instanciação de processos já rotulando dinamicamente para a versão com melhor desempenho durante o próprio experimento, minimizando assim o risco de expor os clientes a versões de processo abaixo do superb por muito tempo. No whole, o AB-BPM também deve permitir uma análise teórica mais curta do redesenho, de acordo com o mantra do DevOps “falha rapidamente, falha barata”. A Figura 1 (incluindo as áreas azuis, excluindo a seta pontilhada) apresenta o ciclo de vida aprimorado do ab-bpm.

Além do teste AB apoiado por RL de hipóteses de melhoria, o método completo do AB-BPM propõe mais algumas técnicas de teste e análise. Nossa investigação se concentra no teste AB apoiado por RL de variantes de processo: está no núcleo do método AB-BPM, enquanto as outras etapas do ab-bpm apenas suportam o design dos testes AB apoiados por RL. As referências ao AB-BPM neste trabalho referem-se apenas ao teste AB apoiado por RL de variantes de processos de negócios.