Colocar RH, Jurídico e Facilities no mesmo GLPI da TI não é ligar um botão - é uma decisão de arquitetura. O Enterprise Service Management (ESM) reaproveita o motor de ITSM que já opera, mas o que separa um projeto que escala de um que se torna uma confusão é a forma como cada área é isolada: por entidade, por categoria ou por grupo. Errar essa escolha custa retrabalho e, no caso de RH e Jurídico, expõe dados confidenciais.
A primeira decisão: entidade, categoria ITIL ou grupo?
Antes de criar um formulário ou um SLA, defina a unidade de isolamento. O GLPI oferece três caminhos para modelar uma área fora da TI, e cada um tem um compromisso real entre confidencialidade e esforço de gestão.
| Abordagem | Isolamento de dados | SLA/calendário próprio | Esforço de gestão | Quando usar |
|---|---|---|---|---|
| Entidade dedicada | Total (pedidos, anexos e relatórios separados) | Sim, por entidade | Alto (perfis, regras e categorias por entidade) | RH e Jurídico, onde há sigilo |
| Categoria ITIL + grupo | Parcial (quem tem a entidade vê tudo) | Partilhado; o SLA pode variar por categoria | Baixo | Facilities e áreas sem confidencialidade forte |
| Subentidade sob a TI | Alto, herdando a governação da casa-mãe | Sim | Médio | Área que responde à mesma direção |
A regra prática que aplicamos: se um pedido da área pode conter um dado que a TI não deveria ler - folha de vencimentos, um contrato, um processo laboral - a resposta é uma entidade dedicada. Para o resto, categoria mais grupo resolvem com uma fração do esforço.
Isolamento de dados: o ponto cego do RH e do Jurídico
Na sustentação de parques GLPI de clientes, o erro que mais vemos num projeto de ESM não é de formulário, é de visibilidade. Alguém cria a entidade "Jurídico", cuida das categorias, mas concede o perfil aos analistas da TI de forma recursiva a partir da raiz - e pronto: a TI passa a ver todos os pedidos do Jurídico, anexos incluídos. Pior: no GLPI o anexo herda a entidade do pedido (o vínculo Document_Item exige que o ficheiro e o item estejam na mesma entidade), pelo que um contrato anexado a um pedido numa entidade partilhada fica visível para todos os que têm acesso a essa entidade. É por isso que, para o Jurídico, isolamos por entidade, nunca por categoria.
Antes de abrir qualquer área sensível, corremos esta auditoria para descobrir quem tem um acesso demasiado amplo:
-- Auditoria de visibilidade: quem ve pedidos de TODAS as areas.
-- Executar na base de dados do GLPI. O acesso recursivo a partir da raiz (entities_id = 0,
-- is_recursive = 1) faz o utilizador ver os pedidos de todas as entidades filhas.
SELECT u.name AS utilizador,
p.name AS perfil,
e.completename AS entidade_base,
pu.is_recursive
FROM glpi_profiles_users pu
JOIN glpi_users u ON u.id = pu.users_id
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_entities e ON e.id = pu.entities_id
WHERE pu.is_recursive = 1
AND pu.entities_id = 0
ORDER BY p.name, u.name;Cada linha é um utilizador que vê tudo. Para as áreas confidenciais, o vínculo perfil-utilizador deve apontar para a entidade específica com o is_recursive desligado. E cuidado com um pormenor do GLPI: a entidade de id 0 é a raiz, um valor válido - não a trate como "vazia".
SLA e calendário por área: o erro do 8x5 no Facilities
O SLA no GLPI está ligado a um calendário (horário de trabalho), e o calendário é definido por entidade. O erro comum é criar o Facilities herdando o calendário 8x5 da TI e prometer um SLA de manutenção de edifícios que, na prática, não corre à noite nem ao fim de semana - justamente quando um ar condicionado de datacenter ou uma falha elétrica exigem resposta. Antes de publicar o SLA de uma área, verifique:
- Calendário: Facilities crítico costuma exigir 24x7; RH e Jurídico funcionam bem em 8x5.
- Feriados: o calendário do GLPI aceita feriados e encerramentos - preencha-os, senão o SLA conta tempo fora do horário.
- Escalonamento: defina o grupo técnico da área antes de ligar o SLA, senão o pedido expira sem destinatário.
Onboarding multiárea: o fluxo que paga o ESM
O caso que justifica o investimento mais depressa é o onboarding. Um formulário "Novo colaborador" (nativo no GLPI 11, ou FormCreator no GLPI 10) despoleta pedidos coordenados: a TI cria e-mail e acessos, o Facilities prepara o posto de trabalho, o RH trata da documentação. Cada pedido nasce na entidade certa, com o grupo certo, e notifica o responsável. Um excerto de um modelo de notificação que usamos para o alerta de abertura na área:
Assunto: [##ticket.entity##] Onboarding: ##ticket.title## (##ticket.id##)
Foi aberto um novo pedido e aguarda a sua area.
Pedido......: ##ticket.title##
Entidade....: ##ticket.entity##
Categoria...: ##ticket.category##
Requerente..: ##ticket.authors##
Grupo.......: ##ticket.assigntogroups##
Prazo (SLA).: ##ticket.time_to_resolve##
Abrir.......: ##ticket.url##As ##...## são etiquetas nativas do GLPI, substituídas no momento do envio. O erro comum aqui é criar as categorias da área e esquecer de as marcar como visíveis no helpdesk (o campo is_helpdeskvisible): o colaborador abre o portal de autoatendimento e não encontra a categoria de RH, porque nasceu visível apenas para a interface técnica.
Checklist de implementação
- Mapeie os serviços da área (o que atende) antes de tocar no GLPI.
- Decida a unidade de isolamento pela tabela acima (entidade vs categoria vs grupo).
- Crie a entidade pela interface - nunca via SQL (o GLPI constrói a árvore com getSonsOf e um INSERT direto fica invisível na hierarquia).
- Configure o calendário e o SLA da área.
- Crie as categorias ITIL e marque a visibilidade no helpdesk.
- Crie o grupo técnico e os perfis, com o âmbito de entidade correto (corra a auditoria de recursividade).
- Monte o formulário (nativo no 11 ou FormCreator no 10) e teste com um pedido real em pré-produção.
- Só então liberte para os utilizadores e publique as métricas.
O que medir (intervalos honestos)
Com as áreas no mesmo GLPI, compara o que antes era incomparável: tempo médio de resposta, volume por categoria e taxa de reabertura, lado a lado entre TI, RH e Facilities. Não prometa um número mágico: reduzir o "e-mail perdido" costuma ser o ganho mais visível no primeiro mês, porque todo pedido passa a ser um registo rastreável. O ganho de tempo no onboarding depende de quanto do fluxo automatiza - quantas mais tarefas o formulário despoletar sozinho, maior o efeito.
Na NexTool implementamos e sustentamos GLPI multiárea para clientes, do desenho das entidades ao SLA e às regras de encaminhamento. Se quer levar o GLPI para além da TI sem expor dados do RH ou do Jurídico, os nossos serviços de suporte e sustentação cobrem esse desenho de ponta a ponta.
Revisto pela equipa NexTool Solutions.
