NexTool Solutions

Os processos de TI raramente cabem num único passo. O diagnóstico leva à execução, a execução leva à validação, e cada etapa só faz sentido depois do resultado da anterior. No GLPI de origem, cada uma dessas tarefas nasce da digitação manual do técnico, o que inviabiliza a padronização assim que o volume cresce. O módulo SubTask Flow encadeia estas etapas: quando o técnico regista a solução de uma tarefa na cronologia, a seguinte é criada automaticamente conforme essa resposta.

Porque criar a próxima tarefa à mão não escala

Muitos fluxos de atendimento são previsíveis: analisar, executar, validar, comunicar. O GLPI oferece modelos de tarefa (TaskTemplates) para padronizar o conteúdo de cada passo, mas não sabe que um passo deve gerar o seguinte. O resultado é conhecido: o técnico abre o modelo certo, copia o responsável e o prazo, e cria a tarefa seguinte à mão. Num ambiente com dezenas de técnicos, isto produz três problemas crónicos: etapas esquecidas, dados divergentes entre tickets equivalentes e nenhuma rastreabilidade de "porque é que esta tarefa existe". Quando uma auditoria pergunta se a validação foi feita, a resposta depende da disciplina individual de cada técnico, não de um processo desenhado.

Como o SubTask Flow encadeia tarefas por solução

O módulo cria relações hierárquicas entre TaskTemplates. Um modelo pai aponta para um ou mais modelos filhos, e cada filho pode ser condicionado a uma solução específica. Quando o técnico regista a solução na cronologia da tarefa pai (ou, se o modelo não tiver condição, marca a tarefa como "Feito"), o módulo executa três passos:

1. Identifica os modelos filhos ligados a essa solução;
2. Cria as TicketTasks filhas na cronologia do mesmo ticket;
3. Copia conteúdo, categoria, duração e responsável (técnico e grupo) definidos no modelo filho.

A configuração vive no modelo, não no ticket. Ajusta o fluxo uma vez e ele passa a valer para todos os tickets que usam esse modelo, sem tocar em regras de negócio nem em automatizações externas. É a diferença entre documentar um processo e fazer com que o sistema o execute.

Passo a passo da configuração

1. Padronize a lista de soluções na configuração do módulo (por exemplo: "hardware", "software", "sem defeito"). Trate-a como um vocabulário fechado, não como texto livre.
2. Abra o TaskTemplate pai e ligue os modelos filhos no separador de encadeamento.
3. Para cada filho, defina qual solução o dispara. Um filho condicional exige que o modelo pai tenha o estado predefinido "Informação".
4. Garanta que todo o modelo filho tem grupo ou técnico responsável e duração preenchidos - é o campo que mais custa depois.
5. Teste num ticket de homologação antes de disponibilizar em produção: crie uma tarefa pai de teste para cada solução possível, registe a solução na cronologia e confirme que o filho certo nasce com os dados corretos.

Deteção de ciclos

Encadeamento sem travão torna-se uma armadilha. Um modelo A que gera B, que gera C, que volta a A, recriaria as mesmas tarefas a cada volta, sem que o fluxo alguma vez termine. Ao guardar uma nova ligação, o módulo executa uma pesquisa em profundidade (DFS) sobre o grafo de modelos. Se encontrar um ciclo, mostra um aviso com o caminho encontrado, mas a ligação fica guardada: cabe a quem configura removê-la. Só a ligação de um modelo a si próprio é bloqueada. Por isso vale a mesma disciplina de qualquer automatização: manter as cadeias curtas e legíveis facilita o diagnóstico quando algo foge ao esperado.

Rastreabilidade: o separador de registos

Automatização sem registo é uma caixa negra. O SubTask Flow mantém um histórico de execuções com o ticket, a tarefa pai, a tarefa filha gerada, quem a despoletou, quem a concluiu e as marcas temporais. Numa auditoria, isto responde à pergunta mais frequente - "esta subtarefa foi criada por uma pessoa ou pelo fluxo, e a partir de que tarefa?" - sem depender da memória de ninguém. É também o primeiro sítio a olhar quando um cliente reporta que "a etapa desapareceu": o registo mostra se o gatilho disparou e a partir de que tarefa.

Diagnóstico: auditar o fluxo em SQL

Automatização silenciosa exige monitorização ativa. A consulta seguinte lista subtarefas ainda abertas que nasceram sem responsável definido, o sintoma clássico de um modelo filho incompleto. Execute numa réplica de leitura ou numa janela de baixa utilização:

-- Subtarefas abertas (state=1) sem tecnico nem grupo responsavel.
-- Sinaliza um TaskTemplate filho com users_id_tech/groups_id_tech vazio.
SELECT t.id                       AS ticket,
       tt.id                      AS task_id,
       tmpl.name                  AS modelo,
       tt.state,
       tt.users_id_tech,
       tt.groups_id_tech,
       tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t               ON t.id  = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
  AND tt.users_id_tech  = 0
  AND tt.groups_id_tech = 0
  AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;

No GLPI, state = 1 é "Por fazer" e state = 2 é "Feito". Se esta lista cresce a cada semana, o problema não é o módulo: é um modelo filho publicado sem responsável, a gerar tarefas que ninguém vê na fila.

Quando usar (e quando não usar)

O erro de campo mais comum

Na sustentação de ambientes com muitos técnicos, o problema que mais aparece não é técnico, é de modelação. Alguém configura o filho para disparar na solução "Hardware", mas a opção que o técnico realmente seleciona no ecrã é "hardware" em minúsculas - ou "HW", num ambiente que herdou o vocabulário de outra ferramenta. O gatilho não corresponde, a subtarefa não nasce, ninguém recebe erro, e o passo de execução desaparece simplesmente do processo sem deixar rasto visível. A correção que padronizámos: tratar as cadeias de solução como vocabulário controlado, todas em minúsculas, documentadas num único mapeamento, e rever os modelos filhos sempre que alguém adiciona uma solução nova. O segundo erro recorrente é o modelo filho sem responsável: a tarefa nasce órfã, perde-se no meio da cronologia e só reaparece quando o SLA já foi ultrapassado. Por isso a consulta SQL acima entra na checklist de sustentação, não numa auditoria pontual.

A NexTool implementa e sustenta ambientes GLPI com automatizações como o SubTask Flow desenhadas para a operação real de cada cliente. Fale com a nossa equipa para mapear e automatizar o fluxo de tarefas da sua equipa.

Revisto pela equipa NexTool Solutions.