Sistema de aprovação. Como inventamos a bicicleta

Continuamos a falar sobre como melhoramos a vida de nossos clientes e parceiros, mas também dos funcionários da empresa. Será sobre a implementação do sistema de harmonização. Eu deliberadamente não indiquei a coordenação do “o quê”, pois no futuro ficará claro que, puramente teoricamente, a coordenação do “tudo”.

Reflexões sobre o sistema de aprovação

Inicialmente, em nossa empresa, assim como em muitas outras, nas quais eu tinha que trabalhar e em que eu era um “convidado” ou acabei de ouvir de meus amigos, o acordo foi negociado (e no momento da redação do artigo ainda está em andamento), por meio de correspondência regular em mail. Naturalmente, isso serve para empresas com um pequeno número de funcionários e contratados. Não há necessidade específica de implementar e implementar sistemas devido à assinatura de um ou dois contratos por mês (ou mesmo um ano), apenas com o CEO tomando a decisão de assinar. Uma situação semelhante foi observada com o pagamento de contas. Cada funcionário que interage com as contrapartes e precisa pagar algo, solicita uma fatura e a envia ao departamento contábil por correio com uma solicitação para "pagar". Ao mesmo tempo, a contabilidade nem sempre paga contas sem a aprovação prévia do pagamento com o supervisor imediato do funcionário e / ou da gerência da empresa. Sob certas condições, a cadeia de aprovações pode ser "abreviada" ou vice-versa "prolongada".

Até agora, não há muitos funcionários e todos sabem todos os seus colegas quem é quem e quem é o líder - não há problemas especiais. No modo manual e sob certas condições, os pedidos de pagamento são negociados no modo de correspondência e pagos (ou rejeitados). Mas nossa empresa está crescendo e, a partir de um certo momento, cruzamos essa linha invisível, após a qual é necessário pensar na automação desses processos e na necessidade de introduzir algo novo.

Nossa lista de desejos

Tínhamos nossos próprios requisitos mínimos de sistema:

• Interface amigável e orientada para a Web altamente desejável (sem a necessidade de instalar clientes)
• Flexibilidade de configuração
• Embora não sejamos clínicos, somos paranóicos. Portanto, queremos manter os serviços nos quais informações confidenciais possam aparecer em nosso perímetro fechado

Inicialmente, analisamos os produtos da família "sistema de gerenciamento eletrônico de documentos" que estão no mercado. Analisamos os sistemas conhecidos: 1C: Gerenciamento de documentos, "NEGÓCIOS", "TESE". Também analisamos os sistemas criados sob encomenda para outras empresas, bem como novos produtos, como o Allware.

Não posso dizer que os sistemas são ruins. De fato, quase todos os sistemas nos permitem atender a nossa lista de desejos principal e ainda mais do que precisamos. Mas, como sempre, o diabo está nos detalhes.

Primeiro de tudo - a interface. Não estamos acostumados a usar a interface de estilo “1C”. Precisamos de uma interface simples e intuitiva na qual realizaremos um mínimo de ações para obter o resultado máximo (e quem não deseja?).
Em segundo lugar, o preço (pago ao mesmo tempo e, em seguida, o custo de propriedade do produto como um todo). Não precisamos de tudo nos sistemas oferecidos imediatamente. Mas, ao mesmo tempo, você deve pagar imediatamente por tudo. E como muitos agora estão migrando para um sistema de assinatura, é necessário pagar constantemente, e o valor, como sempre, depende de muitas condições (número de usuários / conexões, capacidade de trabalhar na nuvem, opções adicionais, módulos etc.). E para "pular" o sistema, se de repente o preço deixar de ser adequado - problemático.
Em terceiro lugar, não há como "gerenciar" sua "lista de desejos".

Implementação

Não vou escrever por muito tempo sobre como e por que, no final, decidimos "criar uma bicicleta" e escrever nosso próprio sistema de gerenciamento eletrônico de documentos. A decisão foi tomada - a ser feita. Já passamos pela doença de tentar implementar o produto sem requisitos, então o processo de escrever TK e sua harmonização foi iniciado. Felizmente, diante de nossos olhos, tínhamos exemplos de implementações, então a formação foi bastante indolor.

A única coisa em que tivemos que esmagar as lanças foi o processo de desenvolvimento da arquitetura para resistir à tentação de satisfazer os requisitos "como estão", em detrimento da flexibilidade e maior facilidade de uso. A tentação foi grande, principalmente para o cliente principal, pois o período de implementação e implementação seria reduzido em 2 vezes. Mas conseguimos convencer a administração e a nós mesmos que "é melhor perder um dia e depois voar em 5 minutos". E acho que fizemos a escolha certa.

É melhor perder um dia e depois voar em 5 minutos.

A pilha "padrão" é .Net Core 2 e EntityFramework, Angular 4, MS SQL, pois temos um background bastante amplo na aplicação de ferramentas e tecnologias. Embora o DBMS realmente não nos importe por razões óbvias. Se necessário, vamos para o que quisermos.
O resultado é um produto que atende aos requisitos importantes para nós:

• Um fluxo de trabalho - diferentes partes do contrato (associadas ao próximo parágrafo)
• Condições para ignorar o estágio de aprovação sob condições especificadas (qualquer campo no aplicativo pode ser adicionado à condição com uma determinada verificação e, com base na validade da condição, a necessidade de ir para a próxima etapa de aprovação ou determinar seu "ignorar")
• Nossa interface "proprietária"

Recursos convenientes e úteis, como:

• Configurando valores padrão para diretórios (usuário e sistema). Um guia do usuário é uma entidade que permite aos usuários definir itens por conta própria. Os itens criados estarão disponíveis apenas para ele. Ao mesmo tempo, nesse diretório, o administrador do sistema pode inserir elementos comuns que estarão disponíveis para todos os usuários do sistema.
• Determinando os elementos de diretórios mais frequentemente usados ​​para cada usuário e formando listas na interface com base nessas estatísticas (classificação)
• Totalmente personalizável a partir dos diagramas do painel de administração (estrutura e propriedades dos campos a serem preenchidos) e visualizações (organização dos elementos no formulário) de cada tipo de solicitação de aprovação
• ACL flexível
• Cada usuário pesquisa aplicativos personalizáveis ​​por vários conjuntos de parâmetros. Parâmetros podem ser quaisquer propriedades de modelos de aplicativos com a capacidade de selecionar a condição que deve ser imposta nesse campo durante a filtragem. Nesse caso, você pode criar quantos conjuntos para filtragem. Conveniente para pesquisa rápida em diferentes seções
• Validação dos valores inseridos com base em um determinado modelo para um campo de aplicativo específico

Claro, havia algumas "curiosidades" também. Primeiro, estamos falando sobre a configuração do fluxo de trabalho. Inicialmente, decidimos que precisávamos da capacidade de configurar o diagrama em árvore do processo de negócios. Que a partir de um ponto (estágio) de coordenação, era possível seguir em diferentes ramos, dependendo da escolha do usuário (Coordenação). Lógico e flexível. Porém, depois que percebemos essa oportunidade e lançamos o sistema em produção, parecia-nos que na verdade não precisávamos dar ao usuário o direito de escolher (oportunidade de pensar). Para ele, tudo deve acontecer no nível de "Concordo", "Recusar". Caso contrário, não poderemos nos afastar do princípio de entender as sutilezas de interação dos funcionários na empresa. E para satisfazer essa condição, o fluxo de trabalho deve ser linear .

Claro, havia algumas "curiosidades" também.

Como resultado, encontramos um compromisso - a arquitetura da solução e a implementação do fluxo de trabalho foram deixadas em forma de árvore, mas o uso do ponto de vista da configuração foi corrigido no nível de "acordo". E eles fizeram certo. Desde agora, ao analisar as tarefas associadas ao lançamento de novos tipos de aprovações, ficou claro que, em alguns estágios, para tipos específicos de aplicativos, precisamos oferecer uma oportunidade para o coordenador escolher várias ações.

Agora um pouco sobre o nosso "know-how" (pelo menos acreditamos nele). Para obter linearidade e, ao mesmo tempo, poder usar um fluxo de trabalho para um esquema de aprovação (por um esquema, quero dizer entidades que requerem envolvimento e a ordem de diferentes funções - contrato, conta de pagamento etc.), pensamos e implementamos um mecanismo de condições pulando as próximas etapas de aprovação. Ao criar as condições, podemos usar qualquer entidade do cartão de reconciliação e compará-lo com "qualquer coisa".

Por exemplo, temos as seguintes entidades: Iniciador, Valor, Moeda, Contraparte. E precisamos disso com uma quantidade inferior a 100.000 rublos. a coordenação não passou pelo funcionário A; nos pagamentos em moeda estrangeira, estava necessariamente conectada à coordenação B e, se o iniciador for o funcionário C, será necessária uma coordenação adicional do funcionário D. Além disso, por funcionários, queremos dizer indivíduos e um determinado grupo. Para implementar esses pontos, adicionamos todos os pontos correspondentes "em linha". Ou seja: Iniciador-> A-> B-> D-> ...

Em seguida, são formadas as condições para uma transição de "aprovação" para cada um dos pontos de coordenação. Por exemplo, no Iniciador de transição-> A, a condição "Valor <100.000" está configurada, em (Iniciador) A-> B - Moeda = "Rublo", (Iniciador, A, B) -> D - Iniciador! = C.

Por que as transições são indicadas entre parênteses? Como as condições podem ser atendidas de forma complexa e "sob o capô", se formarmos uma condição para a transição para um ponto de coordenação, geramos automaticamente uma transição do sistema que "ignora" esse ponto (aqui nossa arquitetura de fluxo de trabalho em forma de árvore nos ajudou e não havia nada "Muleta").

Bem, uma pequena mosca na pomada. Não conseguimos implementar um mecanismo configurável de gerenciamento de alertas. Embora inicialmente tenha sido definido na arquitetura do projeto. Como de costume, para acelerar o processo de inicialização, tive que "temporariamente codificar" um pouco e, no momento, esse código permanece. E a ideia era criar um mecanismo semelhante ao jira, que permite criar seu próprio esquema de notificação, no qual você pode definir gatilhos (eventos) e associá-los a grupos ou funcionários específicos, além de poder "anexá-lo" a qualquer tipo de aplicativo.

Para acelerar o processo de inicialização, eu tive que "codificar temporariamente" um pouco.

Interfaces

Algumas interfaces do nosso sistema, para que haja uma compreensão do que geralmente foi discutido

Dashboard

A primeira coisa que o usuário do sistema vê quando é aberto (se você não levar em conta o processo de autenticação) é um painel. Ele exibe apenas aprovações ativas (incompletas). Além disso, as aplicações são divididas em 2 segmentos:

• Aplicativos que exigem aprovação do usuário (eu sou o artista)
• Aplicativos iniciados pelo usuário (eu sou o autor)

Crie uma nova aplicação

A interface para criar um novo aplicativo pode ter uma representação (o número e o arranjo dos elementos) absolutamente qualquer. Aqui está uma interface simples que demonstra a capacidade de inserir números, selecionar na lista, sinalizar (caixa de seleção), data, anexos.
A única coisa em que você pode prestar atenção é a opção "Criar mais". Quando ativado, após a criação do aplicativo atual, não estamos no painel ou no cartão do aplicativo recém-criado, mas o formulário para criar um novo aplicativo do mesmo tipo que o recém-criado é aberto imediatamente. Foi implementado a pedido de nossos funcionários, que precisam "agrupar" a criação do mesmo tipo de aplicativo.

Estágio de aprovação

Essa interface não é muito diferente do formulário de criação do aplicativo. Mas tem um número de características funcionais fundamentais:

1. Em vez dos botões de criação, aparecem botões, cliques nos quais transferem o aplicativo para um dos estados do processo de negócios. No caso degenerado, como descrito acima, é "Rejeitar" e "Concordo"
2. Anexos, comentários e uma nova entidade do diário (histórico de ações) são colocados em guias separadas
3. Por padrão, todos os campos do aplicativo, exceto o comentário, não são editáveis. Ao mesmo tempo, estabelecemos a funcionalidade que nos permite fornecer, em qualquer etapa específica da coordenação, a capacidade de ajustar apenas um determinado conjunto de campos.
4. Se você é o iniciador do aplicativo (você sempre pode acessar o cartão de aprovação) e tem a opção "Criar duplicado", ao clicar nele, o formulário de criação do aplicativo é aberto, cujos valores de campo (exceto anexos) duplicam os valores de campo do aplicativo atual.

Se você olhar atentamente, notará um elemento laranja com um sinal de mais na frente do campo de seleção Contador. Essa é a funcionalidade de gerenciar um diretório pessoal. Quando você clica nesse item, o formulário para adicionar um item de diretório é aberto.



Como nesse caso é a contraparte, o elemento do diretório em nós contém dois detalhes - Nome e NIF. Após a criação, o usuário pode selecionar imediatamente esse item na lista suspensa.

Pesquisar

Na pesquisa de aplicativos, um conjunto de propriedades é exibido na parte superior, de acordo com os valores que você precisa selecionar. Os conjuntos são configuráveis ​​por cada usuário de acordo com suas necessidades, com a capacidade de alternar rapidamente entre eles.

Administração de processos de negócios

Como parte do gerenciamento de um processo de negócios, podemos criar qualquer número de waypoints e indicar transições. Como resultado, um gráfico de transição é formado. E para cada ponto de coordenação, podemos definir:

• Quem está correspondendo em um determinado ponto
• Permissões para executar ações em um determinado ponto da rota
• Condições para ignorar este ponto (estágio de aprovação)

Correspondência

Na guia "Coordenadores", você pode adicionar grupos, usuários adicionados aos quais eles podem executar o processo de aprovação em um determinado ponto do processo comercial.

Permissões de ação

Nas permissões, você pode ficar um pouco mais. Para limitar as ações dos coordenadores relacionadas à alteração dos valores dos campos (entidades) no aplicativo, foi introduzido um mecanismo de permissão. Atualmente, inserimos 4 permissões:

• Baixar anexos
• Ver anexos
• Comentando
• Alterar os valores dos campos do aplicativo

Se os três primeiros forem mais ou menos claros, a permissão para alterar os campos disponíveis precisará ser comentada. Por padrão, os negociadores não podem alterar nenhum valor de campo no aplicativo. Somente o modo de visualização está disponível. Se for necessário permitir a alteração de campos de aplicativos individuais em um ponto de aprovação específico, esta opção está ativada e é possível selecionar na lista de campos de aplicativos apenas aqueles cujos valores podem ser alterados para o correspondente.

Embora um pouco exagerado, mas por exemplo, isso pode ser necessário se você tiver uma posição separada “um verificador da exatidão do preenchimento da quantidade”, dê a ele a oportunidade de alterar apenas a quantidade no aplicativo e nada mais.

Ignorando Condições

Ignorando as condições que descrevi acima. A funcionalidade é necessária para formar um processo de negócios linear único para todos os usuários do sistema e, ao mesmo tempo, para executar o movimento do aplicativo ao longo da rota de diferentes maneiras, dependendo da condição especificada e sem a intervenção do usuário.

Na tela, é preparada uma configuração que permitirá que você pule esse ponto de rota se o iniciador estiver em determinados grupos e a Moeda for equivalente ao rublo russo.

Em vez de uma conclusão

Atualmente, nossa empresa lançou apenas um tipo de aprovação. Porém, com a flexibilidade de customização incorporada ao sistema, temos ferramentas que permitem configurar qualquer cartão de aplicativo, onde você pode especificar qualquer número de campos, qualquer representação do cartão de aplicativo e qualquer rota para coordenação com várias condições.

A única coisa necessária é trabalhar com as análises para coletar os requisitos e depois transferi-los para o sistema através da interface de administração. O que estamos fazendo agora?

O produto está ativo, periodicamente fazemos alterações a pedido de nossos funcionários, como resultado do aumento de seu poder e usabilidade, e as funções implementadas cumprem a tarefa que nossos negócios enfrentam, e podemos sempre dizer com confiança que a funcionalidade solicitada será implementada no caso de se possível.