You are not logged in.

Announcement

 Téléchargez la dernière version stable de GLPI      -     Et vous, que pouvez vous faire pour le projet GLPI ? :  Contribuer
 Download last stable version of GLPI                      -     What can you do for GLPI ? :  Contribute

#1 2017-07-28 11:56:55

Kallisti
Member
Registered: 2017-07-28
Posts: 18

Best practices for GLPI implementation

Hi all!

I have been running GLPI for a few years in the Proof-of-concept becoming production scenario. I needed it to keep track of tickets for myself and then also for my co-IT technician. Now I want to reimplement GLPI in a more thought-through manner and I'm looking to the community for advise and best practices. I hope it will be a useful discussion!

My current installation is using ocs-ng and a mail receiver, we are using tickets with follow-ups to track user requests and incidents. We have experimented with a number of plugins but are currently mostly using plugins like auto login, browser notification and show loading. Both technicians are generally logged in as super-admin.

Goal: I want to use GLPI better and for more. IN addition to IT, I have several other teams that need a system to track project/tickets and tasks. I want to move away from employees being logged in as super-admin except for when doing GLPI configuration.

Currently GLPI is only used for IT issues, a ticket mostly arrives by email, either from the user or forwarded from a technician. The ticket is assigned to the entity, a basic SLA (still on 0.90.1) and a assigned to group. We have also tried to have the IT team be assigned as a watcher group in order to make us aware when a ticket comes in. I would like the technicians to be able to grab a ticket themselves but also for the group manager to be able to assign a ticket to someone, who will be notified that they have been assigned.

We generally don't use tasks and planning. Progress, and to some extent, communication with the requester is done through follow-ups. When an issue has been resolved, the technician just marks the tickets solved and closed. We have barely scratched the surface of knowledge base, problems and resuing solutions.

As you can see, I would like to take GLPI to the next step and would be really happy to get any type of input. Here are a few specific questions based on the above:

1. Entities, I have never really understood when to use them. Would entities be a good fit for different departments/teams or is for example categories better?
2. Watcher and assigned to groups, are either useful to alert that a new ticket has arrived so it can be (self)assigned?
3. What is a good strategy to alert technicians and manager about outstanding tickets, preferably summarized and sent by email?
4. Is it worth breaking down tickets to tasks? Would that be another or better way to do assignments of work?
5. Are people using problems, knowledge base and solutions, is it worth the effort in your organizations?

Thanks!

Offline

#2 2017-07-28 13:33:04

freewood
Member
From: Moscow
Registered: 2016-01-30
Posts: 116

Re: Best practices for GLPI implementation

Hello. I want to share my opinion, it's actually may be wrong smile
1. You can use entities for departments/organisations etc. Entities in most case used for isolation. User from one entity can't see user and objects from different entity. But it's not always true. You can assign a recursive profile to the user and he will able to view all SUBentities. Or you can additionaly assign him another profile from different entity and he will able to view objects in 2 entities which are placed on the same level.
2. I don't know how to correctly notificate techs about new tickets, but i did that thing: created group "For notifications" and add this to notifications which i want to receive (example: New ticket notification), in this group I added those techs who should reciev notifications.
We use watchers to take control on some tickets. For example, if ticket comes from accounting department it's assign to a tech "John" and "Mark" added as watcher, to control each step of this ticket. In our installation watchers receive all available notifications about a ticket.
3. We didn't use it... yet (I hope smile
4. For us ticket - is a single task. In theory, if there is a big task with many techs involved - it's should be created as a project.
5. We didn't use it.


Debian Stretch + nginx 1.10.3 + php7.0-fpm
GLPI v9.3.1 + Reports, Behaviors, Forms

Offline

#3 2017-07-28 13:58:41

evangineer
Member
Registered: 2017-07-28
Posts: 7

Re: Best practices for GLPI implementation

Hi,

I'm pretty new to GLPI, I only installed it a couple of weeks ago.

Have installed the FusionInventory plugin.  Don't have a mail receiver running yet, but it's high priority.

I'm actually starting to use the Knowledge Base quite heavily.  Using it as a centralized IT documentation repository instead of using a wiki for that purpose. 

I have defined a dozen Knowledge Base categories, which will be used for user-facing documentation and technician-facing documentation.

Have already created a bunch of articles that have been published under the appropriate category.

Looking to learn more about GLPI myself and how to make the most of it.

Offline

#4 2017-07-28 16:23:50

evangineer
Member
Registered: 2017-07-28
Posts: 7

Re: Best practices for GLPI implementation

Hi,

Just had my first look at Problems and it's not clear to me what the distinction between a problem and a ticket is.

Let alone why I should use Problems instead of or as well as tickets.

Can anybody explain this please?

Offline

#5 2017-07-31 10:53:52

Kallisti
Member
Registered: 2017-07-28
Posts: 18

Re: Best practices for GLPI implementation

Hi all,

great to have a discussion!

@freewood: Thanks! Didn't think about the notification settings, I haven't tweaked them for a long time. Also as far as I can see in the notification settings it might be better to use entities, as a ticket always has an entity even before a watcher or assigned to group is set. By the way, are the notification recipients and events documented somewhere? The docs seem to only refer to "fill out all the settings"..
Can you explain more on when you use projects? Do you connect tickets to projects somehow?

@evangineer: We have basically been using onenote as our knowledge base. Perhaps we should start a project to migrate it into GLPI. I've really only used that functionality coming from solving a ticket. Would you mind sharing your approach to using the knowledge base by itself?
I don't use problems myself, I thought they were basically recurring issues, almost like a ticket template, but when looking at it now I'm not sure I'm right.

Offline

#6 2017-08-02 11:15:11

LucaC
Member
Registered: 2012-04-10
Posts: 44

Re: Best practices for GLPI implementation

Hello, here my reply after 5 years of usage (about 500 users, 500 computers and 40branch offices).

1) Entities should be used when you need to isolate items.
For example, you manage two different companies with same GLPI installation, so you want to keep them isolated each other. So I would (not sure of course!) keep IT management in the "root" entity and create two sub entities (companyA and CompanyB).
Then will inherit root uses into A and B

2) Now working as described for one of the IT group. Use assign rules to manage this

3) I would look into native reporting and additional reports plugin (just playing around with them and they are really powerful)

4) We do this sometimes.. Example: a user open a ticket and you realize that you have to escalate to the software house who built the application. In this example, I add a task to the ticket saying "ticket sent to XYZ. Waiting for their reply" - Then I set the ticket as "pending". THe user is notified that IT took care of the incident and that it has been escalated externally. Also you as technician can quickly see tickets currently in "pending" state.

5) Good question, I think ITIL is the answer. To simplify, we use tickets for every user's request. We use Problems for issues fired by our monitoring software (monitoring SHOULD warn us BEFORE incidents from user - this is at least what we hope!)

Bye

Offline

#7 2017-08-03 19:06:05

evangineer
Member
Registered: 2017-07-28
Posts: 7

Re: Best practices for GLPI implementation

Kallisti wrote:

@evangineer: We have basically been using onenote as our knowledge base. Perhaps we should start a project to migrate it into GLPI. I've really only used that functionality coming from solving a ticket. Would you mind sharing your approach to using the knowledge base by itself?

I'm not doing anything particularly complex, just trying a common sense (to me at least) approach.

Defined a dozen or so categories covering different aspects of our infrastructure and just started writing articles under those categories.  I had previously created an overview document for our infrastructure, so I broke that down into separate articles and in the articles elaborated further on the topics beyond what I had written previously.

I also extracted bits of documentation I had published elsewhere and centralized them in the knowledge base, either expanding on existing articles or creating new ones as appropriate.

My aim is to create a one stop shop for all documentation related to our infrastructure.  Each article is aimed for at least one of two audiences, either guides and howtos for end users and/or more in-depth technical documentation for sysadmins (even though I'm the only one currently).

Last edited by evangineer (2017-08-03 19:09:14)

Offline

Board footer

Powered by FluxBB