Outra peça de um livro sobre programação de negócios.
Os processos de fronteira são melhor automatizados. Parece brega, mas essa recomendação está longe de ser sempre implementada.
As situações ainda são comuns quando o processo atravessa a fronteira sem o uso de sistemas automatizados. Em muitas empresas, memorandos em papel, aplicativos, pedidos etc. estão em uso. Obviamente, isso se aplica não apenas aos limites entre departamentos - os funcionários do mesmo serviço também pecam com pedaços de papel.
Se um funcionário entrega o processo para outro em papel, o rastreamento do status dessa tarefa é extremamente difícil. O método elementar e difundido de perder essa tarefa é expresso na fraseologia “limpo debaixo do pano”. É bom que o funcionário empilhe esses pedaços de papel na área de trabalho - o volume de aplicativos é pelo menos visível. Teoricamente, um pedaço de papel específico dessa pilha pode ser encontrado e determinar quanto tempo está nessa fila.
Um método de transferência de um processo por email também é comum. Infelizmente, essa abordagem também não é boa. Em certo sentido, é ainda pior do que uma pilha de papéis, porque os clientes de email não têm funcionalidade suficiente para gerenciar cartas como tarefas. Uma pessoa terá apenas uma montanha de letras, o que dificilmente é possível determinar o estado da fila.
Sobre a transferência oral de tarefas e não vale a pena falar. Como se costuma dizer, voou em um ouvido, voou no outro.
Há outro momento desagradável associado ao conhecimento das fronteiras. Quando uma pessoa entrega a tarefa para outra - no papel, verbalmente ou por e-mail -, o portador da tarefa agora pertence à segunda. Do ponto de vista formal, moral e muitas vezes técnico, o primeiro não pode mais se aprofundar nas tarefas do segundo. Com uma certa estrutura de subordinação, é claro que você pode se aprofundar em uma pilha de papéis, mas ler o e-mail de outra pessoa já é demais. Ainda é possível descobrir, de alguma forma, o estado de um ou mais aplicativos, suas instâncias de processo, mas é quase impossível avaliar o estado geral da fila "na borda".
Portanto, precisamos de um sistema automatizado de controle de fronteiras. Tem vários requisitos importantes.
O primeiro requisito é que o sistema identifique claramente a fila e as tarefas nele. Mesmo em sistemas automatizados desenvolvidos, isso nem sempre é possível. Se você pedir a uma pessoa para mostrar o andamento de suas tarefas no programa, ela poderá demonstrar algo - ele mostrará uma lista de documentos, aplicará alguns filtros e classificação e você obterá uma lista de tarefas. Se você perguntar ao programador, ele fará o mesmo, não apenas na lista de documentos, mas, provavelmente, consultando os dados.
A frase-chave aqui é "se você perguntar". E se você não perguntar? Para um programador de negócios, essa pergunta simples (“e se você não perguntar?”) Pode ser um critério claro para a identificação correta da fronteira. Se você, sendo um observador externo, pode, sem perguntar a um funcionário, ver uma lista de suas tarefas, o primeiro requisito é cumprido - a fila é identificada.
Com a aparente simplicidade desse critério, você descobrirá que a maioria dos sistemas automatizados não o atende. Entender a fila como era apenas a cabeça de um funcionário, mesmo sob o czar Gorokh e os memorandos de escritório, permaneceu no sistema automatizado. Essa situação é familiar e parece normal, porque "todo mundo tem". Mas se você, como programador de negócios, deseja aprimorar esse processo, precisará fazer a identificação da fila.
O segundo requisito é que a fila seja decomposta antes das tarefas, ou seja, a entidades simples que exigem ações compreensíveis. Acontece que a fila parece estar identificada, mas tarefas de diferentes processos estão misturadas nela. Nesse caso, a controlabilidade e a controlabilidade da fila são uma questão séria.
O critério é simples: se você, sem perguntar a um funcionário, pode dizer para cada tarefa específica o que precisa ser feito, a fila é decomposta corretamente. Se a resposta for “é necessário entender” ou “é necessário corrigi-lo de alguma forma” ou “ainda não o olhou”, a decomposição é ruim. O sistema e o processo continuam a depender do funcionário.
O terceiro requisito é que as prioridades para a conclusão das tarefas sejam claras. O princípio é o mesmo dos critérios anteriores. Se você, olhando a fila de lado, vê a ordem das tarefas, as prioridades são claras. Se você, ou consumidores do processo, precisar perguntar ao funcionário sobre prioridades ou redefinir essas prioridades todos os dias, a fila será mal gerenciada.
O quarto requisito é que o tempo gasto pela tarefa na fila, ou seja, O princípio "Iceberg" é aplicado. O tempo gasto geralmente está interligado às prioridades de execução, mas também existem conflitos.
Por exemplo, o sistema prioritário baseia-se na classificação dupla - primeiro a importância e depois a data da tarefa. Nesse caso, com um grande volume de tarefas importantes, nunca alcançará os sem importância. Se o processo é tal que o eterno não cumprimento de algumas tarefas é considerado a norma, tudo bem. Mas, como regra, nos processos de streaming, é importante concluir todas as tarefas.
Portanto, a influência mútua da prioridade e do tempo gasto na fila deve ser monitorada. Por exemplo, após especificar o sistema prioritário, adicione um coeficiente de peso ao tempo gasto na fila, para que, com um determinado valor, a tarefa flutue para a superfície, independentemente da importância.
Portanto, o critério é simples: se você ver cada tarefa tendo tempo na fila, o requisito será atendido. Um erro típico é a opinião de que basta saber e ver a data da declaração do problema, pois, nesse caso, o tempo gasto na fila pode ser facilmente calculado. Automação é realmente fácil de fazer. Mas calcular na mente é muito mais difícil, e nem um único funcionário sensato fará isso. Portanto, o tempo gasto na fila não será levado em consideração no trabalho.
O quinto requisito não importa quão banal, mas o executor da tarefa deve ser conhecido. Se a escolha do contratante for regulada por um algoritmo automatizado, o momento em que esse algoritmo é executado deve ser entendido.
Enquanto a tarefa não tiver executor, ela não será resolvida. O contratado não precisa ser atribuído a cada tarefa específica - é suficiente entender que a solução para todas as tarefas da fila identificada está atribuída a uma pessoa específica.
A escolha do contratante geralmente faz com que uma fila fique ociosa nos casos em que o contratante no processo não designa uma pessoa específica, mas uma posição ou departamento. Nesse caso, é recomendável que a escolha do executor seja feita como uma tarefa separada, que o gerente ou um determinado expedidor deve executar. Embora a escolha do contratado não seja uma tarefa, mas um privilégio, a fila ficará constantemente paralisada neste momento.
O critério é simples: olhando do lado da linha, você deve saber exatamente quem fará a tarefa.
O sexto requisito , nas áreas mais altas da programação de negócios: o sistema deve ser capaz de visualizar e comparar filas de diferentes processos. No caso geral, esse requisito nunca é cumprido; portanto, podemos apenas falar sobre o grau de conformidade.
O problema, geralmente, é que diferentes filas, tarefas e processos são diferentes entidades do sistema, com conjuntos de propriedades separados. Há uma instância de processo em uma fila, mas não em outra. Uma tarefa tem uma data de produção, enquanto a outra não. Etc.
Em vista de tanta diversidade de entidades, geralmente ninguém resolve a tarefa de controlar todas as filas "em uma janela" - nem em sistemas automatizados nem em controle manual. Portanto, o estado das filas - instantâneas e métricas por período - permanece um mistério, o que reduz a eficácia do gerenciamento e da análise.
Parcialmente ajudam os sistemas de controle de processos que "agrupam" uma variedade de documentos principais em entidades únicas. É assim que os cartões de processo, tarefas comuns e entidades de endereçamento são exibidos.
Porém, para um programador de negócios, infelizmente, essa abordagem não é muito adequada.
Em primeiro lugar, a aplicação de processos geralmente leva a uma complicação da automação - não tanto do período de desenvolvimento quanto das alterações subseqüentes. O processo, com o cartão, executores, ações e condições, por si só, é um objeto de automação, com todas as conseqüências que se seguem - a necessidade de manutenção, depuração, coordenação, etc.
Em segundo lugar, a imagem real dos processos, como regra, não pode ser desenhada devido ao conflito do tipo "um-muitos". A maioria dos sistemas de desenho de processos deseja que um objeto seja executado por vez, mesmo se o objeto for múltiplo.
Por exemplo, o processo de execução de um aplicativo de compra. Se você desenhar um mapa de ponta a ponta desse processo, o mesmo aplicativo será executado do começo ao fim. O mesmo fornecedor, a julgar pelo mapa do processo, deve trabalhar com cada aplicativo separadamente, como parte da instância do processo.
Na realidade, o fornecedor não participa do processo de ponta a ponta. Ele tem seu próprio cartão, na entrada do qual há uma variedade de aplicativos. Além disso, todos os dias - de um volume diferente (incluindo, às vezes, vazio). Depois de executar um aplicativo específico a partir dessa primeira instância, o gerenciamento retorna para um único processo.
Esse processo só pode ser desenhado usando processos aninhados, o que geralmente é bem-sucedido, mas a simplicidade e a clareza do algoritmo são perdidas - ele se torna técnico, compreensível para os programadores, mas não adequado para pessoas e gerenciamento vivos.
Terceiro, esses processos são propensos à burocratização - eles estão se esforçando para torná-los "concreto armado", coordená-los, imprimi-los e colocá-los na prateleira. Essa abordagem contradiz os princípios da automação rápida e, portanto, não é adequada para programação de negócios. Processos de concretagem, especialmente durante o período de depuração, é o mesmo que imprimir o código do programa.
Em quarto lugar, os desenvolvedores de mecanismos para desenhar processos, guiados apenas pela lógica do programador, não fornecem ferramentas de gerenciamento de filas. Assim, analisar todas as linhas nas bordas, compará-las entre si, em movimento não funcionará. Você ainda precisa inventar suas próprias ferramentas.
O método de desenhar processos de "concreto armado" pode ser usado como auxiliar, não haverá muitos danos. Ou, pode ser usado no final do projeto, como forma de preservar os processos configurados. Até o próximo projeto.
No entanto, não se esqueça do terceiro ponto - a tendência à burocratização. Se lhe parece que você pode preservar o sistema por um tempo, os demais funcionários e gerentes têm a opinião oposta: não toque no que funciona. O sistema criado, depurado e implementado por você começará a resistir a você.
É muito melhor usar o princípio de "Tarefa automática" ou similar quando o sistema tiver entidades que possam "anexar" aos processos em andamento e criar tarefas em uma fila. O próprio princípio será considerado mais tarde.
Uma única entidade para gerenciar filas nas fronteiras fornece, em primeiro lugar, um único sistema de coordenadas - as métricas de todos os processos nas mesmas unidades. Qualquer processo pode ser avaliado - instantaneamente e em retrospecto - na mesma escala.
A avaliação instantânea pode ser implementada, por exemplo, em um painel de controle de processo comum. Não no mapa de processo geral tradicional, que não pode ser visto em uma tela sem rolagem, mas na forma de uma lista simples, mesmo sem números, usando uma exibição colorida, como um semáforo. Isso resultará em uma lista de duas colunas: processo e status.
A opção é um pouco mais interessante - não uma lista de processos, mas uma lista de pontos problemáticos. A questão, neste caso, é uma autotask, um certo nó de um processo específico, inequivocamente comparável à vida. Por exemplo, "acordo de contratos de um advogado". Basta listar todos os pontos, mostrar seu status e classificá-los para que os mais problemáticos apareçam no topo.
Uma avaliação instantânea de todos os processos, apesar de sua aparente simplicidade e obviedade, é extremamente rara. Agora você entende o porquê.
A análise retrospectiva de filas é uma ocorrência ainda menos comum porque a maioria dos sistemas não contém os dados necessários. Esses dados estão disponíveis apenas se o princípio Iceberg for totalmente utilizado, quando não apenas o tempo instantâneo do estado estiver armazenado, mas também seu histórico.
Em geral, como você vê, não há nada complicado em automatizar o controle de fronteiras. É importante não criar dificuldades artificialmente usando processos de “concreto armado” e ignorando os princípios da automação rápida. As abordagens e critérios que você precisa usar ao automatizar os estados limites dos processos agora são conhecidos por você.