Quando usar os mecanismos de fluxo de trabalho?

Um mecanismo de fluxo de trabalho é útil quando você precisa ir de um início a um final, mas há muitos caminhos / lógicas / regras diferentes para chegar lá.

Por exemplo, digamos que eu escreva um programa que publique conteúdo. Então, no meu caso, a publicação passa por um processo de revisão, legal e, depois, aprovação final. Eu escrevo o programa implementando minha lógica e etapas de processo. Agora este trabalho é ótimo para mim e para minha empresa. Então, decido que os outros devem usar meu programa.

Infelizmente, nem todos publicam conteúdo usando o mesmo processo, então, em vez de escrever processos separados para cada caso diferente, implementamos um processo de fluxo de trabalho para que o programa seja flexível para acomodar todos. Não importa quantos passos, regras ou lógica estejam entre esses dois pontos, o resultado é o mesmo.

Portanto, se você tiver processos que são variáveis do início ao fim, use um fluxo de trabalho. Se o mesmo processo puder ser usado por todos, você não precisará de um fluxo de trabalho.

Eu sei que você pediu por casos de uso, mas é mais fácil listar as vantagens do que imaginar todos os possíveis casos de uso. As vantagens, claro, dependem do motor e da linguagem que você está comparando, mas em geral:

1. Manter as regras como dados em vez de código significa que você não precisa recompilar, para poder testar as alterações rapidamente, alterar em tempo de execução, etc. Não é muito vantajoso se você não precisar recompilar em o primeiro lugar, no entanto.

2. É mais razoável esperar que os usuários editem as regras. Eles podem potencialmente mexer com eles interativamente de maneiras que não são viáveis quando um programador escreve código para eles.

3. Manter regras como dados permite que ferramentas sejam gravadas para visualizar e alterar os dados.

4. Manter as regras como dados permite a meta-programação mais facilmente - você pode escrever código para analisar os dados e inserir mais de uma maneira complexa, o que seria muito difícil para o código.

Todas essas coisas são possíveis de fazer diretamente com código (por exemplo - escrever um analisador C # para localizar todas as regras de um determinado tipo e gerar código para mais regras, inseri-lo dinamicamente em uma montagem de maneira que permita o descarregamento da montagem, escreva ferramentas para que os usuários possam fazer isso usando seu visualizador e editor) mas pode ser muito mais difícil dependendo do seu idioma (programadores usando um Lisp podem se referir aos itens 1-4 como "programação" ).

IMHO o único caso em que você deve usar esse tipo de coisa é quando ele pode ser configurado por usuários menos valiosos. Se você puder resolver seu problema dando a eles uma ferramenta e depois voltar a trabalhar em algo mais importante, use um.

Se você ainda precisar configurá-lo para eles, imagino que você poderia pensar em 10 maneiras diferentes de obter o mesmo resultado com uma ferramenta com a qual você está familiarizado e que será muito mais fácil de suportar e personalizar.

Isso parece uma pergunta antiga, mas aparece inúmeras vezes na natureza. Concordo com a resposta de Jon . Eu descobri que os mecanismos de fluxo de trabalho são altamente produtivos nos seguintes cenários:

1. Existe um processo comercial subjacente que você está tentando representar / implementar por meio de seu software.
2. Existe uma única entidade comercial (talvez composta) que é trabalhada em todos ou alguns dos estágios do processo. No exemplo que Jon forneceu, essa entidade ou Item de Fluxo de Trabalho seria conteúdo ou um artigo. Considere o rastreamento de bugs como outro exemplo de fluxo de trabalho, uma transição de bugs entre vários estados, com base em uma ação realizada por um usuário.
3. Use os fluxos de trabalho para modelar seus processos, somente se você espera que o processo de negócios mude, por mudança quero dizer a sequência ou ação executada como resultado de uma ação ou transição do usuário.

Tenha muito cuidado e seja crítico para ver se o domínio / requisitos do problema tem um processo de negócios, não tente "encaixar" em um fluxo de trabalho.

Eu tenho algumas diretrizes que uso para sugerir mecanismos de fluxo de trabalho.

1) Quando os analistas de negócios não têm antecedentes de codificação, mas podem desenhar diagramas.

Os mecanismos de fluxo de trabalho modernos usam a notação de modelagem de processos de negócios ou as versões menos capazes disponíveis no SharePoint e em sistemas semelhantes. Isso permite que membros da equipe tecnicamente competentes, mas com problemas de codificação, projetem e desenvolvam muitos fluxos de trabalho.

2) Quando você precisa monitorar o progresso do trabalho, execute escalonamentos, alterne entre processos controlados por computador e processos controlados por humanos.

O monitoramento e a auto-referência são marcas registradas dos modernos mecanismos de fluxo de trabalho.

De uma perspectiva de negócios de RH, os mecanismos de fluxo de trabalho são muito importantes.

1. Eles fornecem um processo estruturado, mesmo que seja sempre o mesmo.

2. Eles fornecem transparência

   • Quem solicitou a alteração
   • Quando foi solicitado,
   • Quem aprovou, etc.

   Esta transparência ajuda a impulsionar o processo e promove a propriedade.

Assumindo que os formulários sejam integrados e inteligentes, suportando a lógica de negócios, também tem um efeito dramático na linha do tempo, na eficiência do processamento e na qualidade dos dados. A segurança também é uma consideração e conter informações confidenciais em um sistema seguro é muito preferível a ter formulários em papel espalhados esperando para serem assinados. Também é muito mais móvel. Depois de uma implementação recente, um gerente me disse que isso o salvou de muitos problemas para conseguir que as coisas fossem postadas para ele quando ele viajava muito.

Em nome do RH: Fluxo de trabalho de longa duração !!!