5 motivos pelos quais eu prefiro o Fusioninventory em detrimento do OCS

Muito se discute nos canais de GLPI sobre qual ferramenta de inventário utilizar e porque.

Eu tenho minha preferência pessoal por experiência e gosto.

Portanto deixo aqui rapidamente quais os principais motivos que me fazem preferir e indicar o Fusioninventory em detrimento do OCS.

ESSA É MINHA OPINIÃO! NÃO QUER DIZER QUE O FUSIONINVENTORY É MELHOR DO QUE O OCS. APENAS É DE MINHA PREFERÊNCIA.

Prefiro o Fusioninventory por:

  1. Ser o serviço padrão para o GLPI
  • O GLPI possui uma integração com o Fusioninventory a anos, sendo que se você navegares pelos menus Configurar > Geral > Ativos, encontrarás em qualquer instalação zerada do GLPI a opção que integra as categorias de software diretamente pelo Fusion
  1. Não precisa de outra aplicação, outro banco de dados, outra administração de sistema
  • Diferente do OCS, o Fusion inventory não possui uma nova aplicação que exija administração de usuários, configuração, backup, bancos de dados….
  1. Ser apenas um plugin para o GLPI
  • Apenas explicando o item 2. Ele não é uma aplicação separada. É um plugin que é instalado como todos os outros.
  1. Menor complexidade de implementação
  • Instala o plugin, instala o agente e seja feliz.
  1. Ainda não ter me deixado sem nada que o OCS tenha e o fusioninventory não.

Instalando e Configurando o FusionInventory no GLPI — Configuração de agente no Windows

O Fusion Inventory é um plugin que facilita o controle de inventário no GLPI.

Ele é um fork, ou seja, uma variação melhorada, do OCS Server que se tornou a implantação de uma ferramenta desse tipo muito mais fácil, rápida e eficiente.

Para facilitar ainda mais, fiz dois vídeos mostrando como instalar e configurar o plugin FusionInventory no GLPI e também como instalar o agente em uma estação de trabalho Windows.

Melhorias do GLPI 9.2.x — Parte 1

O GLPI 9.2 saiu, a versão 9.2.1 corrigindo diversos dos bugs também já saiu e é por isso que eu chamarei essa versão de 9.2.x.

Junto com o número, a quantidade de melhorias no GLPI e funções mais perceptíveis não é pequena.

Começo aqui a citar as que mais me chamaram a atenção e que facilitam muuuito mais a nossa vida.

Melhorias na Performance

Quando se trabalha com milhares de Entidades, o GLPI se apresentava bastante lento. Agora não está mais. A Teclib’ fez testes em uma base com mais de 37.000 entidades conforme imagem abaixo.


Função Lembrar-me

Sabe quando você fecha a janela do GLPI e quando volta pra ele, precisa inserir login e senha novamente?

Pois é. A partir desta versão ele possui a opção de “Lembrar-me”. Agora não precisa inserir login e senha mais de 100x por dia para acessar o GLPI


A configuração da retenção dos cookies que seguram as sessões pode ser configurados pelo administrador do GLPI (por padrão são 7 dias).

Pesquisas salvas

As pesquisas salvas, forma com que criamos os filtros pré-configurados, ganharam um belo upgrade na visualização. Não é mais um pop-up na tela e ficou muito mais bonito facilitando criarmos filtros pré-definidos e agilizar o dia dia dos técnicos do Service Desk trabalhando no GLPI.

Para chegar nela é só clicar na estrelinha no canto superior direito.


É possível também alterar as pesquisas salvas dentro das Listas Suspensas e com o contador de chamados é possível criar alertas para quando, por exemplo, uma pesquisa contiver mais de 10 resultados, o técnico seja alertado.

Menu de pesquisas difuso

Sabe aquela função ou configuração que você está procurando mas não lembra se está no menu Configurar ou no Administração, ou se de repente não está entre as Configurações de Entidades ou Geral?

Então. O GLPI tem uma complexidade grande e muitas vezes realmente não encontramos o que precisamos rapidamente. Com a combinação de teclas [Ctrl + Alt + G] você faz a pesquisa que precisar sem sequer usar o mouse -ADORO ISSO-


OLA (Operaional Level Agreements/Acordos Operacionais de Serviço)

A guia ‘SLA’ passou a se chamar ‘Service Levels’ e ganhou uma nova aba para o Gerenciamento de OLA.

O GLPI, como software aderente ao ITIL, segue a linha de raciocínio das bibliotecas que citam os SLA e os OLA. Os OLAs são os acordos feitos entre um provedor de serviços e outro serviço da empresa.

Exemplo para entender melhor:

Uma central de serviços oferece suporte 24/7 para seus clientes e se compromete em lidar com certos tipos de incidentes em até 2 horas e solucioná-los até o próximo dia: Esta configuração é feita nos SLAs do GLPI.

Para entregar esse nível de serviço, pode ser necessário que o mesmo incidente seja escalado para 3 times internos diferentes (dependendo de localização de cliente, serviços envolvidos, natureza do incidente…). Cada time se compromete em lidar com a sua demanda em no máximo 15 minutos e encaminhar sua solução à central de serviços em até 1 hora: Isto é um OLA.


A equipe de desenvolvimento tem noção de que a tela de chamados está ficando um pouco poluída com tanta informação e estão tratando isso como prioridade no futuro. Melhorar essa visão.

Além disso, a aba de estatísticas dos chamados apresenta uma nova linha do tempo mostrando os principais passos do ciclo de vida do chamado.


Se alguma data de SLA ou OLA é estourada, fica em vermelho.


Melhorias nos editores de texto rico

É possível colar imagens diretamente no corpo de chamados e artigos da base de conhecimento quando a função de text-rico está ativa.


GLPI 9.2, atualizar ou não? — ATUALIZADO

O texto abrange a data de lançamento do GLPI 9.2. Hoje 2/2/2018, a realidade é outra e sugiro veementemente a atualização para a versão 9.2.1.

Como todos devem estar sabendo e acompanhando, mas caso não esteja, a versão 9.2 do GLPI saiu a algumas semanas e trouxe muita coisa legal. OLA, Melhorias bem bacanas na base de conhecimento, melhorias no processo de login e de guardar a sessão, notificações no browser via Ajax, pesquisa otimizada no estilo Spotlight do Mac, telemetria, possibilidade de linkar modelos de tarefas diretamente em um modelo de chamado… Tem coisa boa demais aí!!

Mas, e aí Arthur, vale a pena atualizar??

Minha opinião:

Segura aí, peão. Tem pelo menos 30 bugs sendo tratados para a versão 9.2.1, alguns plugins não estão 100% funcionais para a nova versão e essas novas funções todas, ainda estão em fase de documentação pela comunidade. Em um ambiente de produção de alta performance eu ainda sugiro manter a 9.1.3 que me parece estar mais estável e funcional.

Quer brincar com a 9.2? Sobe uma base de prototipagem com um dump do teu banco e vai brincando. Simula a atualização e simula situações do teu dia-dia observando as novas melhorias da versão mais esperada de 2017!!

Mas se estiveres com aquele espírito de porco e louco pra “ver o que dá”, manda bala. Mas saiba que podem surgir problemas ainda não reportados. E caso eles aconteçam, please. Para a comunidade, reporte no https://github.com/glpi-project/glpi/issues, Obrigado, De nada!!

Post do site oficial sobre a nova versão e algumas figurinhas =D

GLPI — Bloqueio de título e descrição de chamado para o requerente

Na atualização 9.1.5 do GLPI, os usuários requerentes passaram a poder se auto atribuir como responsáveis pelo chamado e obter acesso a comentários privados e outras informações que são de posse apenas da equipe interna da Central de Serviços. Rapidamente a Teclib lançou uma versão corrigindo esse bug de segurança.

Acontece que ao passo que percebemos esse erro, boa parte dos administradores do sistema também percebeu um comportamento desconhecido pela maioria.

É possível que o usuário requerente do chamado realize alterações no chamado, logo após a abertura do mesmo.

Fui investigar já que na versão 9.1.6, que corrigiu um grave bug, não havia “corrigido” esse comportamento.

É um comportamento normal desde, pelo menos, a versão 0.85.x, a qual realizei testes. O chamado é de propriedade total do usuário que está solicitando o atendimento. É possível que ele realize as alterações necessárias.

Aí você me pergunta. Mas e se depois que algum técnico realizar o atendimento, o usuário for lá e alterar a requisição. Ótima pergunta.

  1. Os campos só ficam editáveis ATÉ que um técnico ou grupo seja ATRIBUÍDO ao chamado;
  2. O chamado mantém histórico das alterações de quem, o que e quando alterou no chamado.

Dessa forma, traz a segurança necessária para o suporte assumir que o chamado que ele começar a atender é o que irá até o fim. Obviamente adaptações à solicitação primária podem ser realizadas durante o atendimento através dos Acompanhamentos. Mas a solicitação inicial e descrição se mantém a mesma do momento em que o técnico iniciou o processo de atendimento até o final.

Sendo assim, o problema da 9.1.5 era apenas com a possibilidade de que o requerente se atribuísse como analista técnico. Solucionado na 9.1.6.

Obs.: Se, ao atribuir um técnico os campos são bloqueados, tu podes criar uma regra que atribua um grupo técnico ou um técnico para todo chamado aberto. Mas aí tu perde outros indicadores como o Tempo para aceitar o chamado.

Mas isso é assunto para outro post.

Um abraço a todos

Sugestão de melhoria no GLPI — Ocultar campos apenas na Interface Simplificada, não escondendo na Interface Padrão

Interface Simplificada = Interface do usuário final do GLPI. Sem acesso a parte técnica do chamado e do sistema.

Interface Padrão = Interface da equipe de serviços. Acesso aos módulos e alimentação técnica dos chamados.

Existe uma função no GLPI para ocultar campos na abertura de chamados pela Interface Simplificada. O único problema é que ao ocultar campos como Localização ou Urgência na Interface Simplificada, por exemplo, os campos são ocultos até na Interface Padrão, impedindo assim que os técnicos utilizem esses campos.

Realizei uma sugestão de melhoria no portal userecho para que possamos simplificar ainda mais a Interface do usuário final sem atingir a Interface dos técnicos e possibilitar a criação de relatórios mais completos e com mais informações.

Se gostou da ideia, vota nela no portal!!

http://glpi.userecho.com/topics/680-hide-fields-on-simplified-interface-but-not-on-default-interface/

Improvement suggestion for GLPI — Hide fields on Simplified interface but not on Default Interface

Simplified Interface = Final user interface in GLPI. Without access to the technical interface of tickets and system.

Default Interface = Services team Interface. Technical modules and tickets access.

There’s a functionality inside GLPI to hide fields on ticket creation at the Simplified Interface. The only problem is that when we hide fields like Localization or Urgency at the Simplified Interface, for example, the same fields are hidden even at Default Interface, preventing the technical team to use these fields.

I created an improvement suggestion at userecho portal to simplify even more the final user interface without hiding the fields for the technical team e to permit the creation of more complete e more informative reports.

If you liked the idea, vote for it at the portal!!

http://glpi.userecho.com/topics/680-hide-fields-on-simplified-interface-but-not-on-default-interface/

GLPI — Formulário de sugestões, elogios

Como alguns já sabem, existe um portal para a comunidade postar sugestões, dúvidas e até elogiar o GLPI e equipe de desenvolvimento. Acontece que o portal é todo em Inglês e como temos uma comunidade brasileira forte no sistema e que pode ter dificuldades com a língua inglesa, estou disponibilizando um formulário simples para quem quiser compartilhar alguma ideia ou elogio a respeito do software.

Na medida do possível, tentarei repassar essas informações diretamente para o portal oficial.

Improvement suggestion to GLPI — Targets for solution/tasks templates

To whom not seen yet, GLPI, since its 9.1 version, has the function to create and use Solutions Templates and Tasks Templates for repetitive activities which, in general, present few description variations into a task/solution, making it fast to feed the tickets.

The problem with that function is that once the templates are created, they’re visible to all the technicians which have permission to feed tickets.

Thinking of that, I made an improvement suggestion for us to have the possibility to define targets, as on knowledge base items, to limit the templates access by groups, entities or users.

If you think it’s a good suggestion, upvote it on the userecho website for us to see this function in next versions.

http://glpi.userecho.com/topics/682-/