NexTool Solutions

O GLPI não precisa de ficar restrito à TI. Com entidades, categorias e regras de negócio bem desenhadas, a mesma instância atende RH, Jurídico, Facilities e Financeiro como uma Central de Serviços Partilhados (CSP). O que separa uma CSP que funciona de um amontoado de pedidos é a decisão de arquitetura tomada antes do primeiro formulário.

Decisão de arquitetura: entidade por área ou categoria por área?

Esta é a primeira escolha e a mais cara de reverter. No GLPI, uma entidade é uma fronteira multi-inquilino: isola dados, SLAs, perfis e catálogo. Uma categoria ITIL é apenas uma etiqueta de classificação dentro de uma entidade. Usar uma entidade por área dá isolamento forte, mas cobra gestão; usar categorias mantém tudo simples, mas depende de grupos e regras para encaminhar e proteger os dados.

Regra prática: use entidades quando houver requisito real de confidencialidade (RH e Jurídico costumam exigir) ou SLAs e perfis muito distintos. Use categorias quando as áreas partilham o mesmo conjunto de agentes e a confidencialidade é baixa. É comum um desenho híbrido: entidade separada para RH e Jurídico, e Facilities e Financeiro como categorias dentro da entidade corporativa.

Passo a passo para o primeiro departamento fora da TI

1. Modele a fronteira: decida entidade ou categoria pela matriz acima antes de criar seja o que for.
2. Crie a entidade (Administração > Entidades) ou a árvore de categorias (Configuração > Categorias de pedido), marcando sempre a visibilidade recursiva quando a estrutura for partilhada.
3. Crie um grupo de agentes por área (Administração > Grupos) e marque "Pode ser atribuído a pedidos".
4. Defina o SLA/OLA da área (Configuração > Níveis de serviço) com tempos de resposta e de resolução realistas.
5. Configure regras de negócio (Regras > Regras de negócio para pedidos) para atribuir automaticamente grupo, categoria e SLA conforme a origem do pedido.
6. Monte o catálogo: formulários nativos (GLPI 11) ou o plugin Formcreator (GLPI 10) com os campos da área.
7. Ajuste perfis e permissões: o agente de RH não deve ver a fila da TI, e vice-versa.
8. Ligue o cron externo (secção seguinte) antes de anunciar o serviço.

Diagnóstico: quem usa realmente a central

Antes e depois de expandir, meça. A consulta abaixo lê diretamente a base de dados e mostra volume e tempo até à solução por entidade e categoria nos últimos 30 dias. Execute numa réplica ou fora da hora de ponta.

-- Volume e tempo ate a solucao por entidade/categoria (30 dias)
SELECT e.completename                                   AS entidade,
       IFNULL(c.completename, '(sem categoria)')        AS categoria,
       COUNT(t.id)                                      AS pedidos,
       ROUND(AVG(TIMESTAMPDIFF(HOUR, t.date, t.solvedate)), 1) AS horas_ate_solucao
FROM glpi_tickets t
JOIN glpi_entities e            ON e.id = t.entities_id
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= NOW() - INTERVAL 30 DAY
  AND t.is_deleted = 0
GROUP BY e.completename, c.completename
ORDER BY pedidos DESC;

Se aparecerem muitas linhas com "(sem categoria)", é sinal de catálogo incompleto ou de agentes a abrir pedidos sem classificar - o primeiro sintoma de uma CSP que vai perder rastreabilidade.

Cron externo: porque o SLA do RH não dispara a horas

Na sustentação de ambientes multi-área, o padrão que mais falha em silêncio é a entidade sem cron externo. A TI, com tráfego alto, dispara o cron interno a cada carregamento de página e ninguém repara no problema. Já a entidade do Jurídico, com poucas visitas por dia, acumula escalonamentos de SLA que só correm quando alguém abre a interface. O pedido que nos chega costuma ser "os e-mails de prazo do Jurídico chegam todos em lote por volta das 9h" - exatamente quando o primeiro utilizador entra e o cron interno finalmente processa a fila represada. A correção é sempre mover a execução para o cron do sistema operativo (MODE_EXTERNAL) e reduzir a dependência do disparo por carregamento de página.

# /etc/cron.d/glpi - cron externo do GLPI (corre como o utilizador do servidor web)
# Dispara notificacoes, escalonamento de SLA e fecho automatico.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/null

Depois de agendar, entre em Configuração > Ações automáticas e confirme que as tarefas críticas (envio de notificações, escalonamento de SLA e fecho de pedidos) estão em modo CLI, e não "GLPI" (execução na abertura de página). Num ambiente com várias áreas, deixar em modo interno é a causa número 1 de "o prazo estourou, mas ninguém foi avisado".

O erro comum: categoria não recursiva e visibilidade partida

O erro que mais aparece na sustentação é subtil: uma categoria criada na entidade raiz sem marcar a visibilidade para as entidades filhas simplesmente não aparece no formulário do departamento. Sem a categoria certa, o agente abre o pedido como um "Incidente" genérico ou escreve a classificação no título - e o relatório da área nasce furado. O mesmo vale para perfis: um agente de RH com âmbito de perfil não recursivo só vê a entidade exata onde está, não as subentidades. Ao criar categorias na raiz, marque "Filho" (visível nas subentidades), com entities_id = 0 e is_recursive = 1; ao criar perfis de área, decida conscientemente se o âmbito é recursivo.

Governação: evite a explosão de categorias

• Limite a árvore a 2 níveis por área; mais do que isso e ninguém classifica bem.
• Nomeie categorias pela ação do requerente ("Solicitar reembolso"), não pelo jargão interno.
• Reveja trimestralmente as linhas "(sem categoria)" do diagnóstico.
• Um responsável por área, encarregado do catálogo e dos SLAs.
• Não replique a mesma categoria em várias entidades à mão; torne-a recursiva a partir da raiz.

Comece pela TI, que já está habituada ao service desk, e expanda de forma gradual. Cada nova área entra com fronteira definida, grupo de atendimento, SLA e cron externo validado - não com um catálogo improvisado.

Precisa de desenhar a fronteira entre entidades e categorias antes de escalar a sua CSP? A NexTool implementa e sustenta GLPI multi-área para clientes B2B, da modelação de entidades ao cron e às regras de encaminhamento.

Revisto pela equipa NexTool Solutions.