OTRS (Open Technology Real Services)
Total Page:16
File Type:pdf, Size:1020Kb
OTRS (Open Technology Real Services) OTRS is one of the most flexible web-based ticketing systems used for Customer Service, Help Desk, IT Service Management. As the name suggests, OTRS is a "ticketing system" which provides users with an application that can create, distribute, answer, manage, and archive trouble tickets received from customers via telephone or e-mail. By default, user roles in the system are configured as Agents who respond to requests, and Users who receive services. Both types of users interface with OTRS through its fully customizable web interface. After the appropriate installation, setup, and configuration, user can access tickets and ticket histories, as well as create new tickets if appropriate to their role in the system. Additional roles can also be created, and out of the box roles can be customized to fit any specification or requirement. Tickets enter the system and are subsequently managed by assignment or movement between queues. All tickets issued for individual customers and companies have unique, customizable numerical identifiers. Actions are stored in the database and can be accessed through the ticket history. Tickets can have different status characteristics, escalation times, and email addresses depending upon the queue in which they reside. This is also preserved in the history and archive. Statistical analysis is also possible. Tickets can be answered with predetermined e-mail responses that can also contain attachments. Automation of responses and notification evens is possible. Since its beginnings OTRS has been implemented in the programming language Perl. The web interface is made more user-friendly by using JavaScript (which can be switched off for security reasons). Different functionalities are implemented as reusable backend modules, making it possible to create custom modules to extend the functionality of the OTRS system. The web interface itself uses its own templating mechanism called DTL (Dynamic Template Language) to facilitate the display of the systems output data. Originally, OTRS worked only on MySQL databases. Support has since been added for PostgreSQL, Oracle, DB2 and Microsoft SQL Server. OTRS may be used on many UNIXor UNIX-like platforms (e.g. Linux, Mac OS X, FreeBSD, etc.) as well as on Microsoft Windows. INSTALLATION 1) Download install files “otrs-4.0.10.tar.gz”. 2) Extract “otrs-4.0.10.tar.gz” to “/opt” directory. 3) Rename “otrs-4.0.10″ directory to “otrs”. 4) Install MySQL server. 5) Install Apache Web server. 6) Install Perl modules. 7) Update source list. 8) Upgrade all installed packages. 9) Check and make sure that all required Perl modules are installed. 10) Create new user for running OTRS, because OTRS should not be run with root user rights. 11) Add created OTRS user in step above to Web server group. 12) Activate OTRS config files by copying them without .dist filename extension. 13) Run syntax check to see if your Perl is properly set up. After every command you should see message “syntax OK”. 14) Set Web server user permissions for OTRS user. 15) Set up working Apache configuration by copying OTRS conf file “apache2-httpd.include.conf” to “etc/apache2/sites-available/” directory. 16) For installing additional packages, like for example ITSM bundle it is required to set MySQL database to accept packages larger than 16 MB which is set by default. OTRS message: Please make sure your database accepts packages over 20 MB in size (it currently only accepts packages up to 16 MB). Please adapt the max_allowed_packet setting of your database in order to avoid errors.“ Change following line from: “max_allowed_packet = 16M” to “max_allowed_packet = 50M” and add the following line “innodb_log_file_size = 512M” 17) Copy Cron jobs scripts without suffix “.dist”. 18) Configure Cron Jobs with “Cron.sh” script. Note: do not run Cron.sh script as root user, run it as OTRS user. 19) Change how often will PostMaster fetch email (by default it is set to fetch emails very 10 minutes). Change following line from: to 20) Run OTRS web based installer and finish installation steps. http://localhost/otrs/installer.pl 21) Improve Web server GUI speed activate mod-headers. 22) Restart your Ubuntu server, and start using OTRS system via following links: Agent Web interface… http://localhost/otrs/index.pl Customer web interface… http:// localhost /otrs/customer.pl Now, we login to system as admin. After login, helpdesk dashboard page is opened. "Don't use the Superuser account to work with OTRS! Create new Agents and work with these accounts instead." error is displaying. Optionally, we can create agents in settings page. Ticket management is important in OTRS System. So ticket components should not removed from dashboard.Some components; Showing new tickets Showing requests in queue Showing tickets that is increasing priority Company or person's emails can be shown as tickets. These tickets are solved by agents. Agents can do these processes; Send e-mail Call phone Change priority Long estimation time Closing All processes are stored on database CONFIGURATION Our scenario is; "We are a hosting company. Groups and Roles, Agent and Customers are in this company. Our company has IT and IK/Finance departmants. There departmants have sub depertmants. Technical request are sending to IT depertmant and Billing requests are sending to Finance depertmant. " GROUPS Groups in OTRS should be thought of as collections of access rights. To some extent, you can also think of Groups as collections of Queues, though that limits their scope a bit. There are a few modules, including Stats (reporting) and FAQs, that don’t have Queues associated with them by default, but you still define access rights to their functionality through Groups. For this reason, you should not get in the habit of thinking of Groups exclusively as collections of Queues. Groups define the following rights: MOVE_INTO (move tickets into these queues) CREATE (create tickets/articles in these queues) NOTE (add notes to tickets in these queues) OWNER (change the owner of tickets in these queues) PRIORITY (change the priority of tickets in these queues) RW (read-write access to tickets/modules in this group) RO (read-only access to tickets/modules in this group) You can see that the first five rights apply primarily to Queues, while the last two (RW/RO) are more closely related to modules like Stats and FAQ. Nevertheless, there is some overlap. Develop a bias toward thinking of Groups as collections of rights rather than collections of Queues. When you associate a Queue with a Group, you are granting all the access rights defined by that Group to the selected Queue. Groups can seen from Admin page. These groups are already exist. We will create custom groups for our system Create group page; After enter group name, define roles on users Our all groups; ROLES Now that you have some Queues that allow you to classify tickets, and you have Groups that define access rights to those Queues, you need to find a way to grant those rights to an Agent. There are two ways to do this. The first is to assign Agents directly to Groups. This is not generally regarded as best practice for large implementations. Instead, I recommend setting up Roles. Using Roles instead of assigning Group rights directly to Agents offers the following advantages: You only have to configure the rights once, for the role. You can associate multiple Agents with a Role in one swoop. When Agents assume or discard a Role, you can add/remove rights by disassociating them from the Role—no need to update multiple rights on multiple groups. When the responsibilities of a Role change, you only have to update them once for everyone associated with that Role. The trade-off of using Roles is it requires a little more work up front. You have to define your Groups and Roles clearly to make sure that Agents get the rights they need. In the long-run, though, it will simplify administration. Create role; We created 16 Roles; AGENTS By clicking the link Agents, you get access to the agent management screen of OTRS (see Figure below). Administrators can add, change or deactivate agent accounts. Furthermore they can also manage agent preferences, including the language and notification settings for the individual agent's interface. NOTE: An OTRS agent account may be deactivated but not deleted. Deactivation is done by setting the Valid flag to invalid or invalid-temporarily. Create agent page; After creating agent, we need add to groups this agent. Our agents; After creating all agents, groups and roles, move the step relations. 1) Manage Role-Agent Relations 2) Manage Role-Group Relations Services Services such as "standard IT workstation", "e-mail" or "web access" are IT products and should be compiled in a "IT service catalog" prior to the adoption of OTRS ITSM. Such a service catalog is usually customer or company specific and can be structured hierarchically. Furthermore, it should be formulated in a user friendly, meaning easily understood, language, as both IT personnel (agents) and IT users (customers) are among its audience. Adding service; Our services; SLA Service levels and the respective agreements (service level agreements, SLAs) document quality pledges for IT services. SLAs are recorded and administered in the admin interface. OTRS:ITSM offers by default up to 99 different calendars to describe the various time zones for work or service times. The SLAs can be allocated to them ("service level window"). Various time spans can be entered (in minutes) which OTRS::ITSM uses to control notification and escalation: [ Response Time ] = reaction time with incidents = start of service request procession ("service request lead time") [ Update Time ] = notification time [ Solution Time ] = time elapsed until incidents are resolved ("maximum time to repair", "MTTR") = delivery time for service requests ("delivery time") [ Min.