Como escolhemos o ServiceDesk. Parte 2

Continuamos a escrever sobre a escolha de um sistema para digitalizar um negócio. Como tudo começou, leia aqui.

Deixe-me lembrá-lo: somos uma empresa de serviços que decidiu encontrar uma pílula mágica para nossos negócios, graças à qual ela é "seca" e todos os processos de negócios ocorrem sem problemas e sem interrupções.


Nós os consideramos pela disponibilidade das funções que precisamos. Quais?

3 funções importantes para nós


Esses recursos estão longe de tudo o que procuramos no ServiceDesk. Veja a lista completa em nosso primeiro artigo. Lá, descrevemos 3 recursos, aqui 3, o restante - no próximo artigo.

Este artigo comparou:

  • A capacidade de personalizar o ciclo de vida do aplicativo, dependendo da chamada recebida sem programação. Idealmente, isso é para economizar tempo. Para um tipo de trabalho, não há necessidade de coordenar o trabalho com o cliente e, para outro, é necessário. O ciclo de vida pode ser muito diferente, dependendo do tipo de aplicação (crítica, não crítica, planejada etc.). Deve haver uma ferramenta conveniente que permita marcar e editar.
  • Altere o histórico de cada aplicativo. Gostaríamos de receber algo como arbitragem. Nesse caso, estamos falando da oportunidade de explorar toda a cronologia da cooperação, o que geralmente ajuda a resolver problemas controversos. Um histórico claro de alterações de aplicativos é excelente para isso.
  • Ajuste flexível de escalação (transferência de responsabilidade) entre funcionários. Por exemplo, uma pessoa não pode acessar o aplicativo. Então você precisa transferir o aplicativo para o chefe, que o transferirá para outro funcionário. Isso pode ser refletido rapidamente no sistema e nos scripts pré-configurados?

Como esses recursos são implementados?

Configurando o Ciclo de Vida do Aplicativo


Planado


Durante a operação, vemos um LC linear simples: Início - Pausa - Fim.



A personalização não funciona. Que pena.
Em princípio, este sistema pode ser usado para resolver nossos problemas, mas não será conveniente.

Okdesk


Configurações flexíveis. É possível criar novos status e definir transições entre eles.
Interface simples e intuitiva.



Conclusão: se, no mínimo, a funcionalidade é aceitável, ou seja, é o suficiente. Mas não há como construir um relacionamento flexível entre status - perderemos essa função.

Grotem


A configuração do aplicativo LC não é fornecida.

BPM Online


Configurações muito flexíveis. É possível criar novos status e definir transições entre eles. Qualquer configuração através da funcionalidade incorporada.



Hubex


É possível criar e configurar o ciclo de vida do aplicativo individualmente. Status, estágios e transições são personalizáveis ​​e podem ser personalizados para a empresa.



Naumen


É possível criar novos status e definir transições entre eles.
Configuração flexível do ciclo de vida. Configurando a visibilidade e os campos obrigatórios, dependendo do status. Tudo isso é possível na interface do tecnólogo.



Mas, novamente, a interface não é adequada para todos.

Alterar histórico


Planado


A história como tal não é observada. Apenas fixando o horário ao alterar os status.



Isso é ruim, pois nenhuma arbitragem será bem-sucedida. Tal reflexo das mudanças requer tensão e recordação adicionais do que era naquela época. E se você não se lembra, perde a arbitragem.

Definitivamente, isso não nos convém.

Okdesk


História bastante padrão. Ele observa quando ocorreu a alteração e o status do aplicativo (anterior e novo).

Agradável - após um exame cuidadoso, fica claro quem alterou o status do aplicativo. Mas isso também é um sinal de menos - você pode considerar o autor das alterações apenas se olhar atentamente (porque o autor está marcado apenas no texto da alteração e não em uma coluna separada).



Isso nos convém? Não, porque essa história leva muito tempo para trabalhar com ela. Pelo menos, eu gostaria de uma exibição mais conveniente do histórico para procurar informações rapidamente.

Grotem


O sistema armazena o histórico de alterações do aplicativo.
Na história, você pode ver as seguintes opções:
- Data da mudança
- Status
- Autor da mudança



Essa funcionalidade é adequada para nós? Sim, é possível.

BPM Online


Tendo várias visualizações sobre as alterações.

No sistema, você pode visualizar o histórico de alterações para cada estágio do aplicativo:

- quem fez as alterações,
- quando ele fez isso,
- quais.



A funcionalidade deste sistema é adequada para nós? Provavelmente. Vamos olhar mais longe.

Hubex


O "Histórico de alterações" é armazenado na seção apropriada dentro do aplicativo.

As seguintes informações são armazenadas no histórico:

- status do aplicativo,
- fase do ciclo de vida da aplicação,
- quem fez a mudança,
- quando ele fez as alterações,
- a que horas as mudanças.



Aqui você pode encontrar informações sobre o status do aplicativo, o período de validade e o status do aplicativo.



Um bônus muito bom: no histórico de mudanças, você pode ver se havia um funcionário na instalação ou não. No estado da solicitação (centro da tela), o sistema mostra onde a alteração foi feita.
Essa funcionalidade é adequada para a nossa empresa? Acho que sim, mas há mais uma solução.

Naumen


Uma história bastante comum.

A fixação da maioria das alterações nos atributos do aplicativo foi implementada:

- datas da alteração,
- descrição da alteração,
- O autor da mudança.

A próxima versão espera a adição de geolocalização ao alterar o status.



Configurando escalação automatizada (transferência de responsabilidade)


Idealmente, eu gostaria de automatizar esse processo para que o próprio sistema mude e notifique a pessoa responsável pelo aplicativo, dependendo do cenário especificado.

Por exemplo, se o aplicativo permanecer no status "Novo" por mais de 2 horas ou ao alterar o status do aplicativo para "recusa do executor" - o sistema pode transferir o aplicativo independentemente para o chefe da organização?

Planado


Não há configurações de escalação de nenhuma forma. Isso é, infelizmente, simples, porque uma empresa pode perder parte de sua receita devido à perda de clientes. Um enorme menos ...

Okdesk


O escalonamento é implementado apenas na forma de um único alerta de email. Você pode configurar o tempo dos alertas.



Isso não é totalmente adequado para nós, porque gostaria de notificar o chefe não apenas por e-mail.

Grotem


Em uma versão típica do sistema, essa função não é fornecida. Apenas personalização individual.
Em princípio, você pode considerar essa opção, mas eu não gostaria de gastar dinheiro extra.

BPM Online


O escalonamento é configurado no designer de processos de negócios, na guia "Formulários".



Aqui você pode especificar a condição de execução da tarefa ou o período durante o qual a tarefa deve ser concluída. Caso contrário, o gerenciamento é notificado no sistema.

Isso é adequado para nós? Não, porque o gerenciamento nem sempre "fica" no sistema e precisa de notificações por outros canais (e-mail, SMS, pelo menos).

Hubex


No sistema, você pode configurar facilmente a escalação - as condições para o envio de uma notificação, o texto da notificação e outras funções estão configuradas.



As notificações estão disponíveis por meio de mensagens push ou email.
Apropriado para nós? Métodos de notificação talvez, mas não o suficiente.

Naumen


Implementou um grande número de configurações para o mecanismo de escalação. Existem notificações por email, SMS e push.





O sistema é definitivamente adequado para a nossa organização.

Para continuar ...


Isso é tudo, é claro, bom. Mas há muito material. Não quero aborrecer o estimado leitor com meus escritos. E não há tempo para aulas de ficção.

No final, não somos Daria Dantsova, para carimbar livros inteiros algumas peças por dia. Portanto, publicaremos informações gradualmente.

Para a conexão!




Parte 1
Parte 3

Source: https://habr.com/ru/post/pt472088/


All Articles