მეტი HelpDesk HelpDesk-ზე. რა არის OTRS? ჩვენ შეგვიძლია მოვარგოთ შეტყობინებების ჩვენება

სტატიებში შევეცდები გამოვავლინო ITIL პრაქტიკის განხორციელების თავისებურებები, მათ შორის OTRS ვიკი.

რისი მიტანა სურთ IT დეველოპერებს?

შევეცდები მოგითხროთ ამბავი, ITIL-ის გადახედვით, კორესპონდენტის სიტყვებით (ეს შეიძლება უფრო გრძელი იყოს კარგი კორისტუვაჩი), ამ გზით: კორისტუვაჩს სურს, რომ IT სერვისები თანმიმდევრულად იყოს მიწოდებული IT დეპარტამენტთან ან გარე ორგანიზაციებთან, რომლებიც უზრუნველყოფენ მომსახურებას. თუ მოცემულ სერვისში არის გაუმართაობა, თქვენზეა დამოკიდებული, სად მიმართოთ და სერვისი რაც შეიძლება სწრაფად უნდა განახლდეს. ამ შემთხვევაში, კლიენტებს სურთ შეასრულონ გარკვეული IT სერვისები, როგორიცაა პროგრამული უზრუნველყოფის ინსტალაცია, ისევე როგორც ძირითადი პროცესები, რომლებიც შეიძლება შესრულდეს პირდაპირ, როგორიცაა:

ინციდენტების მართვა
მოთხოვნის შესრულება

ინციდენტების მაგალითები: კომპიუტერი არ ჩართულია, არის პრობლემა პროგრამის გაშვებისას.
განაცხადები ფინანსურ მომსახურებაზე მოთხოვნებისთვის: პროგრამული უზრუნველყოფის ინსტალაცია, კორპორატიულ რესურსებზე უფლებების მინიჭება და ა.შ.

კომენტარებში დასახმარებლად: პროგრამული უზრუნველყოფის ინსტალაცია შეიძლება შეიცვალოს ან ექვემდებარება შენარჩუნებას, ხოლო უფლებების მინიჭება შეიძლება დარეგულირდეს Access Management-ის მიერ. ყველაფერი წესრიგში უნდა იყოს დაცული, ამიტომ დადექით IT დეპარტამენტის წინ და აღწერეთ ეს სერვისები, როგორც დეპარტამენტი გვთავაზობს.

ცოტაოდენი ITIL ტერმინოლოგია

ინციდენტი – IT სერვისის დაუგეგმავი შეწყვეტა ან IT სერვისის სიმძლავრის შემცირება.
Meta to the Incident Management process: ყველაზე მოწინავე IT სერვისი კორპორატიული პროფესიონალებისთვის.

ცოტა რამ OTRS-ის შესახებ

Habr-ზე არის ამ სისტემის გამოცანები, ამას სულ რამდენიმე წუთში გამოვიცნობ:
ვიკის მსგავსად სისტემა განბლოკილიაგანაცხადების დამუშავება, თუმცა მისი ფუნქციონირება ბევრად სცილდება აპლიკაციების დამუშავებას.
სისტემის რეგისტრაცია შეგიძლიათ ოფიციალურ ვებგვერდზე www.otrs.com. იქ ასევე შეგიძლიათ იპოვოთ დამხმარე საშუალებები ინსტალაციისა და რეგულირებისგან.

OTRS-ის დაყენება

ეს ნიშნავს ბილეთების ტიპს. უფრო სწორედ, ჩვენ მოკლებული ვართ იმათ, რაც გვჭირდება მნიშვნელოვანი პროცესების განსახორციელებლად, მაშინ როცა სისტემა უკვე შეიძლება დამონტაჟდეს.

საჭიროების შემთხვევაში, შეგიძლიათ დათვალოთ chergs, მაგალითად, Hardware Security, Druk, Program Security. აგენტის წვდომა შეიძლება მორგებული იყოს კანზე. აგენტები არიან სერვისის პროვაიდერები, რომლებიც პასუხისმგებელნი არიან ინციდენტების გადაჭრაზე, სახელწოდებით ServiceDesk სერვერები.
კალენდრის მიზნით, მაშინ... კონკრეტულ უნარზე მინიჭებული აგენტების ხელმისაწვდომობის საათები დამოკიდებულია მათ სამუშაო გრაფიკზე.

კალენდრის პარამეტრები კონფიგურირებულია მოდულში:

Core::Time::Calendar1

შესაძლებელია 10-მდე ასეთი კალენდრის მინიჭება და თითოეული კალენდარისთვის შეგიძლიათ მიუთითოთ აგენტების მუშაობის წელი კვირის თითოეული დღისთვის, წმინდა დღეებისთვის და შაბათ-კვირისთვის. საათი ხელმისაწვდომია მანამ, სანამ SLA არ უზრუნველყოფს აგენტების ხელმისაწვდომობას.

ეს ნიშნავს სერვისებს (ასევე ცნობილია როგორც სერვისების კატალოგი) და მომსახურების დონის SLA.

საკმარისია მინიმუმ ერთი SLA, რომელიც მიუთითებს პირველი რეაქციის დროს და უმაღლესი პასუხის საათს.

განაცხადების წარდგენა უნდა მოხდეს WEB-ინტერფეისის, ტელეფონით ან IT დეპარტამენტის აგენტური ინტერფეისის მეშვეობით.
იმისდა მიუხედავად, რომ OTRS-ში არის კლიენტის ინტერფეისი მოთხოვნებთან მუშაობისთვის, ჩვენ ინტერაქციას ვატარებდით შიდა საიტის მეშვეობით, რომელიც მუშაობს Joomla-ზე, რომელიც შეიცავს OTRS Gateway მოდულს (ჯიხურში, რომელიც არის ჯეკი). მოდული საშუალებას გაძლევთ შექმნათ მოთხოვნები და ნახოთ „თქვენი“ მოთხოვნის შექმნამდე.

განაცხადი უარყოფილი იქნება როგორც ახალი. აგენტის ინტერფეისში არის ერთი საათი პირველ რეაქციამდე და გადაწყვეტილების მიღებამდე.

აპლიკაციიდან მუშაობის დაწყების ფაქტი ფიქსირდება შაბლონის ბაზაზე შექმნილ დასტურში
ამის შემდეგ აპლიკაცია იბლოკება და ღია სტატუსი წაიშლება. ამ ეტაპზე განმცხადებელი იღებს ინფორმაციას მათ შესახებ, ვინც მიიღო განცხადება განსახილველად. ექიმი აწვდის პირველ რეაქციას ერთი საათით ადრე.
ჩანაწერი განპირობებულია აღწერებით, საჭიროების შემთხვევაში, არასწორად შეყვანილი მონაცემების გასწორებით.
გადაწყვეტილების მიღების შემდეგ განაცხადი გადადის მომლოდინე ავტომატური დახურვის+ სადგურზე.
რეცხვის საათი დგინდება პარამეტრით:

$Self->("Ticket::Frontend::PendingDiffTime") = "14400"

თუ კორისტუვაჩი დაკითხვამდე მეტ ინფორმაციას არ მიიღებს, იგი გადაყვანილია დახურულ წარმატებულ ბანაკში. ასე რომ, შესაძლოა, ეს არ არის მთლად სამართლიანი, მაგრამ მეორეს მხრივ, ნუ სთხოვთ თქვენს კორესპონდენტს წასვლა WEB-ინტერფეისზე და დაწეროს კომენტარები საბოლოო მოთხოვნამდე.

$Self->(Ticket::StateAfterPending) = (
"pending auto close+" => "დახურული წარმატებით",
"pending auto close-" => "დახურულია წარუმატებელი"

Unix cron დამგეგმავი პასუხისმგებელია სტატუსების გადაცემაზე, რომელშიც აუცილებელია სტატუსის განახლების სიხშირის დაყენება 2 წელზე ნაკლებ დროზე:

ყოველ 120 წუთში შეამოწმეთ მომლოდინე სამუშაოები
45 */2 * * * $HOME/bin/PendingJobs.pl >> /dev/null

ჩვენ შეგვიძლია შევცვალოთ პარამეტრი საათის 5 წუთზე დაყენებით. ამავე დროს, ჩვენ გვახსოვს სისტემის პროდუქტიულობა.

ყოველ 5 წუთში შეამოწმეთ მომლოდინე სამუშაოები
*/5 * * * * $HOME/bin/PendingJobs.pl >> /dev/null

აგენტის ინტერფეისში მოთხოვნების ხელით საჩვენებლად, დააყენეთ შემდეგი პარამეტრი:
ძირითადი::ბილეთი::ViewableStateType,
ახლისა და ღიას ჩამორთმევა, რითაც გაეცანი აგენტის ინტერფეისს.

გამოწვევები

ამ დიალოგის დროს კითხვის აღწერა ხშირად გადადის მხრებზე, ფრიალის გარეშე, რათა არ დაიღალოს კორისტუვაჩი. საჭიროებისამებრ, ველები მითითებულია სერვისით და ტიპით. მოთხოვნის არასწორი აღწერა შესწორებულია ServiceDesk-ის მიერ.
აუცილებელია მომხმარებელთა მომსახურების ყველა აქტივობის აღრიცხვა, ეს პრობლემა მოგვარებულია Service Desk-ის თანამშრომლების მოტივაციის გზით.

საჯაროობა

მნიშვნელობა იქმნება დამატებითი სტანდარტული ფუნქციონირების გამოყენებით შექმნის ოსტატის დახმარებით, მაგალითად:
რეაქციის შუა საათი ვიკონავიელებისთვის
საშუალო რეაქციის საათი თითო სერვისზე
ვიკონიანური გადაწყვეტილების შუა საათი
სამსახურის გადაწყვეტილების შუა საათი
სასმელების რაოდენობა სინათლის პერიოდში (თვეში) ვიკონავიელებისთვის
სასმელების რაოდენობა სეზონზე (თვეში) მომსახურებისთვის
მოთხოვნების მაქსიმალური რაოდენობა შეესაბამება მოთხოვნების SLA-ს მოთხოვნების მთლიან რაოდენობამდე.

ვიკონავიელების ანგარიშვალდებულება აუცილებელია სამსახურის ფუნქციონირებამდე მიღებული ფაჰივების შეფასებისთვის (მოტივაციისთვის).
ამ სერვისის საჯაროობა ეძლევა დაინტერესებულ პირებს.

გარდა ამისა, vikorystvoyutsya ხმები, SQL მოთხოვნების ამოღება მონაცემთა ბაზაში და თავად სუნი არის IT სერვისის მუშაობის მთავარი მაჩვენებელი:
ასობით ყოველი მოთხოვნა აკმაყოფილებს SLA-ს. (ჩვენს ვიპადკას აქვს 80%, პრაგნემოს 90%-მდე).

ახლახან გაჩნდა ნათელი იდეა ჩვენი HelpDesk სერვისის მუშაობის სისტემატიზაციის შესახებ, ან როგორც ჩვენ ახლა ვუწოდებთ ServiceDesk-ს, რადგან შესაძლებელია დამატებითი სისტემის გამოყენება აპლიკაციების ავტომატური შეგროვებისა და დამუშავებისთვის (რომელიც იგივე სახელს ატარებს).
მოდი, ვნახოთ.
1. გავაანალიზოთ ასეთი სერვისისთვის ყველაზე შესაფერისი სისტემები

• გადახდილი HelpDesk სისტემების და უფასო HelpDesk სისტემების განლაგების ცხრილს რომ გადავხედე, ერთი შეხედვით ყველაზე სპეციალიზებული საიტი HelpDesk-ის შესახებ, მივხვდი, რომ მონაცემები, როგორც ეს ხდება, სამწუხაროდ მოძველებულია და არ წარმოადგენს ახალ სურათს.
• დაბრუნდა ძებნაში, დაარტყა დონე რუ-ბორტზე. აქ ყველაფერი ბევრად უფრო დეტალური და არა მიკერძოებული იყო. ალე ასევე დაზარალდა, ქუდი შეყვარებული იყო 2008 წლის როკის აღზევებაზე. მსგავსი პუნქტის დაპირისპირების კიდევ ერთი მცდელობა გარდაიცვალა კულმინაციამდე, მაგრამ ინფორმაცია, რომელიც გამოქვეყნდა, თუმცა ნებართვის გარეშე.
• კიდევ ერთი შესანიშნავი რესურსი არის http://netdocs.ru/, მაგრამ მე ვერ მოვახერხე ამის გამოსწორება.
• ასეა nowa.cc ფორუმზე მყოფებთანაც, მაგრამ იქ, როგორც ყოველთვის, ყველაფერი დახურულია "გასვლისთვის" და ბევრი ინფორმაცია არ არის.
• მეტი ვერაფერი ვიცოდი.

2. ამ ფაქტების გათვალისწინების შემდეგ, ჩვენ ვიწყებთ ანალიზს, თუ რომელი სისტემები საუკეთესოდ შეესაბამება ჩემს საჭიროებებს. ჩამოთვალეთ მახასიათებლების მნიშვნელობის შემცირებით:

• შესყიდვის წინ სისტემის პროტესტის შესაძლებლობა
• განმცხადებლის WEB სახე
• სპეციალისტის WEB სახე
• განმცხადებლის ელექტრონული ფოსტით შეტყობინება და დოკუმენტი
• ინტერფეისის შეცვლის შესაძლებლობა
• დროა დაიწყოს და გამოსცადოს ოპერაცია
• რუსიფიკაცია
• მატერიალური ბაზის ტიპი
• კონტენტის იმპორტი გლობალური დირექტორია სერვისებიდან
• ლიცენზია

3. შემუშავებული ათი კრიტერიუმი, მგრძნობიარეა პირველის მიმართ. Vіn ვირუსულად გამოჩნდა.
აქ არის რამოდენიმე რამ, რაც უნდა იყოს კმაყოფილი ტესტირებისთვის აღებული სისტემების შესახებ:

• (ბეზკოშტოვნა, ლიცენზია GNU ) - http://otrs.org
• PerlDesk v2.25(გადახდილი) http://www.perldesk.com/
• კლარისი(გადახდილი) - http://saas.claris.su/
• იტილიუმი(გადახდილი) - http://www.itilium.ru/
• (გადახდილი) - http://www.adventnet.com
• HP OpenView (ფასიანი) - რუ-დაფა
• კაიაკო(გადახდილი) - http://www.kayako.com/
• IPI.HELPDESK (გადახდილი) – http://ipi-helpdesk.ru/

4. ტესტირებისთვის მხოლოდ ნახევრის დაყენება მოვახერხე:

• OTRS - ღია ბილეთის მოთხოვნის სისტემა (უფასო ლიცენზია GNU ) - http://otrs.org
• იტილიუმი(გადახდილი) - http://www.itilium.ru/
• ManageEngine ServiceDesk Plus(გადახდილი) - http://www.adventnet.com
• HP OpenView (ფასიანი) - რუ-დაფა

ყოველდღიური საცდელი ან ტაბლეტების მეშვეობით.

• HP OpenView (Windows), როგორც ვიცი, ვერსია 4.5 აღმოჩნდა მოძველებული და არ იყო მხარდაჭერილი. HP გამოუშვა ვერსია 5.1 და გამოუშვა საბოლოო გიგანტური ვერსია 7.5, დააინსტალირა გარკვეული გაგება, რომ სერვერის მონიტორინგის სისტემა მნიშვნელოვანია ჩემი სერვისის ორგანიზებისთვის. HelpDesk საერთოდ არ არის შესაფერისი.
• Itilium (Windows), რომელიც დაფუძნებულია 1C პლატფორმაზე, იქნა ნაპოვნი და დაინსტალირებული, მას შემდეგ, რაც რამდენიმე დღის განმავლობაში ცდილობდნენ ეძებდნენ საჭირო ვერსიას, რომელიც შეესაბამება 1C პლატფორმის ვერსიას. დავაყენე C-ka 8.0, 8.1, 8.2 და Itilium ვერსია 8.3.1 დაყენებული 1C 8.2-ზე, ხრახნიანი 1C სპეციალური WEB გაფართოებავერსია 8.0.11.1. სანამ ვილაპარაკებთ, Itilium-ის ამჟამინდელი ვერსია უკვე უცნობი ხდება, რადგან WEB გაფართოება 1C 8.3-ში ხელახლა იქნება აშენებული და ინტეგრირებული 1C-ში.
• OTRS(Windows, Linux), გასაკვირი არ არის, რთული იყო ინსტალაცია. იმიტომ რომ მესამედ დავაინსტალირე, მერე პრობლემები, რამაც გამოიწვია WEB-ის წასვლა, უკვე დაკავებული იყო და საინსტალაციო პაკეტიდან ინსტალაცია არ მუშაობდა. გასაკვირია, რომ ასეთი სერიოზული სისტემის ინსტალაციის კონფიგურატორი არ შეიცავს "Advanced" ინსტალაციის ვარიანტს. ჩაცმას წყდება და მოწყალებით დაფრინავს. ასევე არსებობს ცალკე პაკეტებში ინსტალაციის შესაძლებლობა. ჩემთვის მნიშვნელობა არ ჰქონდა, მაგრამ არც ისე ადვილი იყო იმის გაგება, თუ რა პაკეტები იყო ისინი! იმიტომ რომ ვერსია 2.4.7 პრაქტიკულად აღარ არის მხარდაჭერილი 2010 წლის პანდემიის შუა პერიოდში განახლებით ახალი ვერსიები 3.0. როგორც ჩანს, ეს პაკეტები გაჟონა ოფიციალური ვებსაიტიდან (ალბათ მათ გადაწყვიტეს ჰოსტინგზე 50 მეგაბაიტის დაზოგვა). ჩემთვის მნიშვნელოვანი იყო საჭირო ვერსიების მოპოვება: 1. საჭირო ვერსიის სადისტრიბუციო ნაკრები Perl 5.6.1.633, იძულებით ale ვიცი - http://crymchaks.at.ua/files/ActivePerl-5.6.1.633-MSWin32-x86.msi.7z. 2. Posilannya on Apache 1.3.27- http://www.filewatcher.com/m/apache_1.3.27-win32-x86-no_src.msi.2192896.0.0.html. 3. ღერძიანი პაკეტიOTRS-Win32-Perl-პაკეტებიმე ეს ვერ ვიცოდი. (Neroboe poslannya- ftp://ftp.otrs.org/pub/otrs/misc/win32/OTRS-Win32-Perl-Packages.zip, თუ რამეს იპოვით - გთხოვთ გააზიარეთ, ეს ხუმრობაა!) მე მქონდა ამის დაინსტალირება სხვა სერვერი ინსტალაციის პაკეტიდან. Არაა პრობლემა.
• ManageEngine ServiceDesk Plus (Windows) - ვერსია 7.6.0 დაინსტალირებულია სამუშაო მაგიდაზე. და ღვთის გულისთვის, პირველად დამაყენეს ჩვეულებრივი ტამბურების გარეშე, თუმცა რუ-დაფაზე აბი წავედი.

5. ორი წლის წინ დავიწყეთ ამ სისტემების ტესტირება. მე არ ვაჩვენებ გრაფიკებს და ცხრილებს ქულებით. მოკლედ ვიტყვი:

• Itilium - მე ვერ გავაუქმე სასურველი შეტყობინება ფოსტით შექმნილი ან განახლებული ბილეთის შესახებ (ბილეთის აპლიკაცია). 1C-ში ჩამოაყალიბეს დოვიდნიკების გრძელვადიანი გორგლების ფენები და სავალდებულო ველების ფენები მათ შევსებამდე, ისე რომ პირველი განაცხადის დასრულებას რამდენიმე დღე დასჭირდა მინიმუმის შევსებას. და უბრალოდ არ არის საკმარისი დრო ყველაფრის დასამახსოვრებლად და ყველა შესაძლებლობის გასავლელად, ასე რომ არ არის საჭირო 2 სახელმძღვანელოს წაკითხვა 250 და 90 გვერდიანი სისტემის ინსტალაციისა და ინსტალაციისთვის... ან გადაიხადოთ სახელმძღვანელოებში, ან Vykoristannaya-ზე. მათი სპეციალისტები, რომ აღარაფერი ვთქვათ მათზე, ვისაც თავად სისტემის გადახდა მოუწევს.
• OTRS– სისტემაში მუშაობის მე-10 კვირაზე ჩემი პირველი განაცხადის ჩამოყალიბება მოვახერხე, მაგრამ საფოსტო შეტყობინება ჯერ არ მიმიღია. :( Zagalom არის ყველაზე პოპულარული საპროტესტო სისტემებიდან. მართალია, დიდი დრო დასჭირდა ყველა, ყველა, ყველა წესის, ინციდენტების სახელების შეცვლას, მენიუს და ადმინისტრატორის ინტერფეისის გარდა. ძალიან ცოტა იყო ამის აღწერა. მენიუ ადმინისტრატორშიდიდი ხანის განმვლობაშიაურიეთ თავი იმის გასაგებად, თუ რატომ ემსახურება თითოეული ჯგუფი და რა არის დაკავშირებული მასთან, მინდა სიტყვასიტყვით გამოვიტანო რამდენიმე ფრაზა. თუ არ გსურთ შეინახოთ ის, რაც მე არ მივიღე ფოსტაში, მაშინღია ბილეთის მოთხოვნის სისტემა კარგი სისტემაა, არ არის რთული, მაგრამ მას გააჩნია ბევრი რამ. ამის გასაფართოვებლად, თქვენ უნდა ჩაუღრმავდეთ არა მხოლოდ PHP-ს, არამედ ბიზნეს წესებს, რომლებიც აწესრიგებს ამ სისტემის მუშაობას, ან რაიმე მსგავსი.
• ManageEngine ServiceDesk Plus - პირველი აპლიკაციის გაშვებას ერთი დღე დასჭირდა, მაგრამ შემდეგ ყველაფერი საათის მექანიზმით ჩაიარა. ყველაფერი კარგად არის აღწერილი და მუშაობს მინიმალური შევსებით. შაბლონებში შეგიძლიათ შეცვალოთ არა მხოლოდ ტექსტი, არამედ ხატების რეტუშირებაც და მათი ხილვადობა გაქრა, ფაქტიურად მხოლოდ ერთი დაწკაპუნებით, როგორც ჩანს.გადაათრიეთ და ჩამოაგდეთ. დაბნეული ვიყავი ამ სისტემაში, ამიტომ სწრაფად გავგზავნე შეტყობინებები ბილეთების შესახებ ფოსტით და შესაძლოა SMS-ითაც კი. მშვენიერი ნამუშევარი მატერიალური ბაზით (IT სისტემის აღჭურვილობის ინვენტარი), ანგარიშების მენეჯერთან კავშირებით, რომლებიც იმპორტირებულია Active Directory-დან ან LDAP-დან. ამრიგად, თავად სტანდარტული ავტორიზაცია შეიძლება დაემატოს რაიმე სპეცრაზმის გარეშე დომენით და ჩამოერთვას შესვლის მეთოდის არჩევის შესაძლებლობას.

მიზანი მხოლოდ დადებითი ემოციებია სამუშაოდან ManageEngine ServiceDesk Plus 7.0, რომელსაც გირჩევთ.
ერთი ის არის, რომ არცერთ სისტემას არ აკლია კარგი არაოფიციალური საიტი: (
მაშ ასე, რუ-დაფაზე დაწერეთ თემაზე, ვიკორსტანის ცოდნას გავუზიარებთ.
ვიმედოვნებ, რომ ეს სტატია დაგეხმარებათ დაზოგოთ ასეთი ძვირფასი დრო, რომელიც დაიხარჯება ყირიმელი ხალხის ისტორიის შესწავლაზე, რომლებიც კვდებიან, კრიმჩაკების ეთნიკური ჯგუფი.
წარმატებები ყველას!

PS (2 კლდის მეშვეობით): on ნარაზივიკორისტი OTRS 3.1.3 განაცხადების (ბილეთების) მიღების, დამუშავებისთვის და თქვენი არჩევანით კმაყოფილებისთვის.

Დადებითი:

1. pratsyuє shvidko (Linux)
2. მორგებული ხმა
3. სისტემის 1300-მდე გაუმართავი განყოფილება მათ სრული ტექსტის მოძიებით
4. განახლებულ ოპერაციულ სისტემასთან დაკავშირებით არანაირი პრობლემა არ არის
5. ცხელი ღილაკები

ნაკლოვანებები:

1. სხვადასხვა მონაკვეთების ასეთი ფართო სპექტრის გამო, ძნელია იცოდეს კორექტირების საჭიროება
2. ასე რომ, მე ვერ დავაყენე ის, რომ როდესაც განაცხადი მიიღება, მოთხოვნის სტატუსი "წარმატებულად დაიხურება"
3. ზომა ვერ შევცვალე ტექსტის ველიშეყვანილი უნდა იყოს აპლიკაციის ნაცვლად, როდესაც აპლიკაციას უპასუხებენ (ფანჯარას, რომელიც იხსნება, არ აქვს ღილაკი „ანგარიში“).

მე უბრალოდ დავამატებ ფასიანთა სწრაფ სახეს უფასო სისტემებიუპირატესობების უმეტესობა ხელმისაწვდომია HelpDesk ან ServiceDesk სისტემებიდან.

რა არის OTRS?

იაკი ყვირის სახელიდან" Საჯარო წყარობილეთების მოთხოვნის სისტემა", OTRS არის მოთხოვნის (ბილეთების) მიღებისა და დამუშავების სისტემა. მოთხოვნით (ბილეთი) მე მესმის სხვის მიმართ სისასტიკეს. ამრიგად, OTRS აპლიკაციის შესაძლებლობები გაცილებით ფართოა, Helpdesk-ის ქვემოთ. IT დეპარტამენტი, მაგალითად, სისტემის იდეოლოგია აშკარად მოიცავს რობოტს, რომელიც მომგებიანია, რობოტი გაყიდვების სფეროში კომერციული წინადადებისა და ბაზრის მოთხოვნის მოპოვებიდან, რობოტი ბატარეის კონტროლის სამსახურში. და ა.შ. თუ გსურთ IT დეპარტამენტის გაზიარება, გსურთ Helpdesk სერვისის ავტომატიზაცია, შემდეგ შემდგომი აღწერა აღწერს თავად Helpdesk-ის გადაწყვეტას.

რა სახის დავალება ჰქვია OTRS for Helpdesk:

• ცხოველების რეგისტრაცია. IT სპეციალისტებმა უნდა იცოდნენ, რა ხდებოდა; მოლარეებმა უნდა გაიგონ, რომ თანხა დაიხარჯა მისამართზე და არ დაიხარჯა. გარდა ამისა, მყიდველისთვის მნიშვნელოვანია ნებისმიერი ტრანზაქციის დამუშავება ერთი და იგივე ერთიანი გზით.
• მხეცის გარეგნობა და აღჭურვილობა. მათი პასუხისმგებლობაა იცოდნენ, როგორი სისასტიკეა ყოველ წამს და იმუშავონ მათ სიკვდილზე; ჩვენი ვალია გავიგოთ რა ხდება ჩვენს მხეცებთან.
• აპლიკაციების ავტომატიზაცია. თეორიაა, რომ ნებისმიერი პრობლემა კომპეტენტურ სპეციალისტს შეუძლია 1 წლის განმავლობაში გადაჭრას. რა საჭიროა, პრობლემა მაშინვე ჩავარდეს ასეთი ფაკერის ხელში. ამიტომ, როგორც კი ავტომატიზირებთ ღუმელის დამუშავებას, შეგიძლიათ სწრაფად დააჩქაროთ ღუმელის პროცესი ოფიციალურ კლერკთან.
• „ფარული ცოდნის“ წინააღმდეგ ბრძოლა. ინფორმაცია აპლიკაციებისა და აპლიკაციების მიღმა არსებული მოქმედებების შესახებ უნდა ჩაიწეროს ისე, რომ ისინი არ იყოს ხილული მხოლოდ სპივოროტინიკებისთვის, რომლებმაც დაიწყეს ქვესტი. სხვა ტიპის განაცხადის წარდგენისას ადამიანური ფაქტორი შეიძლება ცდებოდეს და განაცხადი არ წარედგინება მას, ვინც უბრალოდ არ იცის ამის შესახებ, თუმცა ადამიანები, რომლებსაც შეეძლოთ მისი დაჯილდოება, მეტ-ნაკლებად საკმარისი იქნება.

სისტემის იდეოლოგია გადმოგვცემს, რომ ნებისმიერი სისასტიკე შეიძლება ჩაიწეროს. ცვლილებები ფიქსირდება განაცხადის დროს. დაბნეულობის თავიდან ასაცილებლად, ჩვენ გვინდა შემოგთავაზოთ რამდენიმე ძირითადი კონცეფცია:

• კლიენტი - ის, ვინც აყალიბებს აპლიკაციას. ეს არის სისტემის გარე ღირებულება.
• აგენტი - ის, ვინც ამუშავებს განაცხადს. ეს არის სისტემის შიდა სისტემა.

კლიენტის რეგისტრაციისა და იდენტიფიკაციის დაფიქსირება, განაცხადისთვის უნიკალური ნომრის მინიჭება წინა მორთვაამ კატეგორიზაციის მეთოდით, აგენტ(ებ)ის შეტყობინება ახალი განაცხადის შესახებ.

განაცხადები მიიღება ჩერღახში.

• ჩერგა არის ადგილი, სადაც განიხილება განაცხადები.

ჩერგი იძლევა საშუალებას:

• დაყავით აპლიკაციების მასიური მასივი.
• მიანიჭეთ შეზღუდული წვდომა აგენტებზე განაცხადების დაწყებამდე.
• შეატყობინეთ მომღერლის აგენტების განაცხადების შესახებ.
• კლიენტებმა უნდა დააყენონ სხვადასხვა ავტომატური ტრანსმისია აპლიკაციის პარამეტრების გამოყენებით

როგორია სისტემაში შეტანილი განაცხადების თანმიმდევრობა? გამოითქმის 3 გზით:

1. ეცნობება ელექტრონული ფოსტით. OTRS ამოწმებს საფოსტო სკრინშოტი(i) i გარდაქმნის კანის შეტყობინებებს აპლიკაციაში
2. ფორმის შევსება კლიენტის მიერ ვებ ინტერფეისის საშუალებით
3. აგენტის მიერ განაცხადის შექმნა ცხოველთა სპეციალური ფერმის წარმომადგენლობისთვის, მაგალითად, ტელეფონით ან სიტყვიერად ქათმისგან.

მოდით, ახლა შევისვენოთ. შემდეგი ქანდაკება მიეძღვნება მოკლე აღწერაინსტალაციამდე და სხვა მე აღვწერ მოხსენებას კობის რეგულირებასისტემა.

ცხადია, ლოკალიზაციის ფაილში არის შეცდომა. იპოვეთ ფაილი c:\otrs\Kernel\Language\ru.pm, იპოვეთ ტექსტი „გასვლა“ და შეცვალეთ %c %c %s %s-ზე.

Apache სერვისის გადატვირთვა - მუშაობდა.

ნაშტუვანნია ჩერგი.

ბარათის მენეჯმენტში აირჩიეთ Postmaster. ჩვენ ვცვლით ნახატის სახელს სისტემის მხარდაჭერაზე, დააჭირეთ გაგზავნას.

ფოშტი მოწესრიგდა.

განაცხადების მიღება შესაძლებელია ელექტრონული ფოსტით.

განაცხადების ელექტრონული ფოსტით დასარეგისტრირებლად, თქვენ უნდა იცოდეთ შესვლა და პაროლი იმ ანგარიშის ანგარიშისთვის, რომელზეც განთავსებულია აპლიკაციები. ამ სკრინშოტის დაყენებისას, თქვენ უნდა მიუთითოთ „სერვერიდან სიების წაშლა, თუ სიებს მოთხოვნილი იქნება IMAP (POP) გამოყენება.

დაბანის შემდეგ სისტემა იღებს ათი შემოწმებას კანზე.

მოდით გადავიდეთ ადმინისტრაციაში – ფოსტის დაყენება – ღრუბლოვანი ფოსტის ჩანაწერები PostMaster-ისთვის. IMAP შეიძლება გაშვებული იყოს.

მიუთითეთ ტიპი, პოსტ სერვერი. არჩეული გადამისამართება შერჩევით მეშვეობით, სადაც - სისტემის მხარდაჭერა. ჩვენ ვაჭერთ გაგზავნას.

ადმინისტრაციაში გადასვლა – ფოსტის დაყენება – ელ.ფოსტის მისამართები.

Keruvannya განყოფილებას აქვს სისტემის მისამართები ელექტრონული ფოსტითმისამართის შერჩევა [ელფოსტა დაცულია]ჩვენ ვცვლით მისამართს, სადაც ახალი აპლიკაციებია საჭირო. საჭიროების შემთხვევაში შეგიძლიათ შეცვალოთ სახელი, რომელიც გამოჩნდება „სისტემის მხარდაჭერის სერვისებზე“. ჩვენ ვაჭერთ გაგზავნას.

ჩვენ ვარეგულირებთ შესაძლებლობას მოგაწოდოთ ერთი და იგივე საფოსტო მისამართი ახალი აპლიკაციებისთვის.

რომლის კლიენტი იყენებს MS Exchange 2008-ს, როგორც ფოსტის სერვერს. გადადით ადმინისტრაციაზე – სისტემის ადმინისტრაცია – სისტემის კონფიგურაციაზე. აირჩიეთ Framework, შემდეგ Core::Sendmail. Მოდით ვთქვათ:

SendmailModule - აირჩიეთ SMTPTLS;

SendmailModule::Host – მიუთითეთ გამომავალი ფოსტის სერვერი;

SendmailModule::Port – სურვილისამებრ პორტი;

SendmailModule:AuthUser – მითითებული ანგარიშის შესვლა;

SendmailModule::AuthPassword – შეიყვანეთ ანგარიშის პაროლი;

SendmailNotificationEnvelopeFrom – მითითებული სისტემის ელფოსტის მისამართი.

სამუშაო კალენდრის დაყენება მომხმარებელთა დახმარების სერვისისთვის.

გადადით ადმინისტრაციაზე – სისტემის ადმინისტრაცია – სისტემის კონფიგურაცია – ჩარჩო – Core::Time.

ჩვენ ვირჩევთ სპეციალურ სამუშაო წელზე. ვისთვისაც მხარდაჭერა გათვალისწინებულია 8.00-დან 17.00 საათამდე.

დააჭირეთ ღილაკს განახლება.

ჩვენ მივმართავთ სისტემის კონფიგურაციას – Framework-Core::Time::Calendar1.

ჩვენ შეგვიძლია შევცვალოთ კალენდრის სახელი.

სამუშაო წლისთავია, წმიდაო.

Dodamo ჯგუფი წვდომის უფლებების დიფერენცირებას.

ადმინისტრაცია - აგენტების მართვა - ჯგუფები.

განყოფილებაში Keruvannya ჯგუფებში აირჩიეთ ჯგუფის დამატება. მიუთითეთ ჯგუფის სახელი - სისტემის მხარდაჭერა. დააჭირეთ გაგზავნის ღილაკს.

შემდეგი, ჩვენ ამ ჯგუფს ვუკავშირებთ დამხმარე სერვისის აგენტებს საჭირო ველების შემოწმებით.

ჩვენ ვამატებთ კიდევ ერთ ჯგუფს ძირითადი დამხმარე აგენტებისთვის, OTRS-თან უფლებების გაზიარების შედეგად.

დააყენეთ საჭირო ყუთები. დასაბეჭდი გაგზავნა.

ანალოგიის შემდეგ, ჩვენ ვქმნით სხვა ჯგუფებს, რომლებიც გვჭირდება.

აქ ასევე შეგიძლიათ დაამატოთ აგენტები, რომლებსაც აქვთ OTRS-ის ადმინისტრირების უფლება ადმინისტრაციულ ჯგუფში.

ჩერგის მორგება

ჩვენ ვაყენებთ კავშირებს ისე, რომ ფაქსიმ შეძლოს უპასუხოს მომხმარებელთა მოთხოვნებს სისტემიდან.

ადმინისტრაცია – მონახაზის დაყენება – შაბლონები.

სექციაში Keruvannya შაბლონები შეგიძლიათ იხილოთ ტესტის პასუხის პასუხი.

ახლა აირჩიეთ პასუხის ცარიელი შაბლონი და შეცვალეთ იგი. სტრიქონის სახელი იცვლება ახალი ხაზი. ფურცლის სხეული ცარიელია გადაყრილი. ჩვენ ვაჭერთ გაგზავნას.

შიგთავსი, რომელიც ჩანს ფურცლის სხეულში დოკუმენტის წარდგენისას, კონფიგურირებადია.

მოდით გადავიდეთ ადმინისტრაციაზე - ჩერგის მორგება - ვიტანია. აირჩიეთ სტანდარტული მისალმების სისტემა და შეცვალეთ იგი. ჩვენ ვაჭერთ გაგზავნას.

ჩვენ შეგვიძლია მოვარგოთ ხელმოწერა, რომელიც გამოჩნდება ფურცლის ბოლოში დოკუმენტის წარდგენისას.

ადმინისტრაცია – ანგარიშის პარამეტრები – ხელმოწერები. აირჩიეთ სტანდარტული ხელმოწერის (en) სისტემა და შეცვალეთ იგი.

ახლა თავად გამოვასწოროთ ეშმაკები.

ადმინისტრაცია – ჩერგი – ჩერგის მოწყობა.

აირჩიეთ თქვენი სისტემური მხარდაჭერა. თქვენ შეგიძლიათ მიუთითოთ თქვენი სახელი, ჯგუფი, სისტემის მისამართი, გაიმეოროთ დადასტურების პარამეტრები - შესაძლოა, მიუთითოთ ჩვენი კალენდარი.

ანალოგიისთვის, ჩვენ უნდა მივყვეთ ქვემოთ მოცემულ ინსტრუქციას.

ავტომატური აკრიფის დაყენება, რომელსაც მომხმარებლები იღებენ ახალი აპლიკაციის რეგისტრაციისას.

ადმინისტრაცია – მომზადებული პერსონალი – Autovideos.

ავტომატური პასუხის მართვის განყოფილებაში აირჩიეთ ნაგულისხმევი პასუხი (ახალი ბილეთის შექმნის შემდეგ) და შეცვალეთ იგი. ჩვენ ვაჭერთ გაგზავნას.

დასახელება: ახალი აპლიკაციის შექმნა

თემა: RE:

ფოთლის სხეული:

Კარგი დღე, !

თქვენი განაცხადი დარეგისტრირდა.
განაცხადის ტექსტი:

———————————————

ავტომატური კავშირი აქამდე.

ადმინისტრაცია – პერსონალის მორგება – ავტოვიდეო-ჩერგა.

განყოფილებაში შეკვეთების ბმულები ავტომატური პასუხებით აირჩიეთ სისტემის მხარდაჭერის ვარიანტი, ხოლო ავტომატური პასუხის განყოფილებაში აირჩიეთ ახალი შეკვეთის შექმნა. ჩვენ ვაჭერთ გაგზავნას.

ანალოგიურად, ჩვენ ვამატებთ ავტომატურ აკრეფას ყველა ზარს.

ჩვენ ვაწყობთ ობლიკოვის ჩანაწერიაგენტი

ადმინისტრაცია - აგენტები - აგენტების მართვა.

აირჩიეთ აგენტი. შეამოწმეთ თუ ელ.ფოსტის ველი სავსეა.

ჩვენ ვდებთ ყველა შეტყობინებას, რათა რესპონდენტმა შეძლოს სწრაფად რეაგირება ახალ მოვლენებზე.

პუნქტში "განახლების საათი" ირჩევთ 2 ვარიანტს. კომენტარის ველში შეგიძლიათ შეიყვანოთ დამხმარე სამსახურის სპეციალისტის ტელეფონის ნომერი.

ჩემი უჯრით ველში ირჩევთ (ხილულად) საჭირო უჯრას.

ჩვენ ვაჭერთ გაგზავნას.

ჩვენ ვასწორებთ შეტყობინებებს fakhivstvos-ისთვის

ადმინისტრაცია – განაცხადების დამუშავება – აგენტების შეტყობინება.

Keruvannya განყოფილებაში, ჩვენ ვცვლით ნაგულისხმევ ტექსტს კანის ინფორმაციისთვის.

en::აგენტი::AddNote- ეს ინფორმაცია საჭიროა, როდესაც აპლიკაციას ემატება ახალი შენიშვნა.

ახალი შენიშვნა! ( )

ფოთლის სხეული:

Კარგი დღე, ,

განაცხადის ნომერზე ახალი შენიშვნის დამატებით .

აღნიშვნა:

:///

—————————————
Helpdesk შეტყობინების სერვისი

ru::აგენტი::ესკალაცია- შეტყობინება განაცხადის ესკალაციის შესახებ (განაცხადის გადაწყვეტილების მიღების საათი დასრულდა)

თემა: განაცხადი უარყოფილია! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, ,

Აპლიკაციის ნომერი [ ] ესკალოვანა!

ესკალოვანა ვ:
ესკალოვანა თ:

დაწერილი(ა):

კოლაფსი პატივისცემა:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ru::აგენტი::EscalationNotifyPefore- შეტყობინება შვედური განაცხადის ესკალაციის შესახებ (აპლიკაციის დახურვის დრო მთავრდება)

თემა: ინფორმაცია განაცხადის შვედური ესკალაციის შესახებ! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, ,

Აპლიკაციის ნომერი [ ] მალე თქვენ გახდებით ესკალაცია!

ესკალოვანა ვ:
ესკალოვანა თ:

დაწერილი(ა):

კოლაფსი პატივისცემა:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————-
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ru::აგენტი::FollowUp– ინფორმაცია მათ შესახებ, ვინც ვერ ახერხებს აპლიკაციის გადაჭრას და სამუშაოდ გადაქცევას

თემა: განაცხადი დახურულია! აპლიკაცია გადაკეთდა რობოტად! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

დახურული განაცხადის ნომერი საოცარი!

დაწერა:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ru::აგენტი::LockTimeout– შეტყობინება მათ შესახებ, რომ აპლიკაციის დაბლოკვის ვადა დასრულდა

თემა: განაცხადის დაბლოკვის ვადა გავიდა! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

განაცხადის დაბლოკვის პერიოდის ნომერი [ ] დასრულდა.
აპლიკაცია განბლოკილია.

დაწერა:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

en::აგენტი::გადაადგილება– ინფორმაცია მათ შესახებ, ვინც სხვა პირს მიმართა

თემა: განაცხადის გაგზავნა ვადამდე ! ()

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

თქვენი განაცხადის ნომრის გაგზავნით [ ] ჩერგუში .

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ru::Agent::NewTicket – შეტყობინება მათ შესახებ, ვისაც აქვს ახალი მოთხოვნა

თემა: ახალი აპლიკაცია ჩერზისგან! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

ნ კვერცხუჯრედი განაცხადი ვ ჩერგი !

დაწერა:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

en::აგენტი::OwnerUpdate- ინფორმაცია მათ შესახებ, ვინც მითითებულია განაცხადის მფლობელად

თემა: თქვენ გამოცხადდით აპლიკაციის მფლობელად! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

Აპლიკაციის ნომერი [ ] გადმოგეცათ.

კომენტარი:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ru::Agent::PendingReminder – ინფორმაცია მათ შესახებ, ვინც კონფიგურირებულია აპლიკაციის გამოცნობისთვის

თემა: განაცხადის გამოცნობა! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

აპლიკაცია [ ] საკუთარ თავზე გამოცნობა!

დაწერა:

პატივისცემის აღდგენა:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

en::აგენტი::ResponsibleUpdate- ინფორმაცია იმ პირების შესახებ, ვინც პასუხისმგებელია განაცხადზე

თემა: თქვენ ითვლებით განაცხადზე პასუხისმგებელი! ( )

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

In და აღიარებული საშუალოზე მაღალიგანაცხადის ნომრის შემდეგ [ ].

კომენტარი:

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————-
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ru:: აგენტი:: სერვისის განახლება– ინფორმაცია მათ შესახებ, ვინც განაახლეს სერვისი

თემა: სერვისი შეიცვალა ! ()

ფოთლის სხეული:

———————————————————————————————-

Კარგი დღე, !

თქვენი განაცხადის ნომრის განახლება [ ] და სერვისის შეცვლა

:///index.pl?Action=AgentTicketZoom;TicketID=

—————————————-
Helpdesk შეტყობინების სერვისი

———————————————————————————————-

ჩვენ ვაყენებთ შეტყობინებებს კლიენტებისთვის

ადმინისტრაცია – განაცხადების დამუშავება – ინფორმაცია განაცხადის შესახებ.

დააჭირეთ ღილაკს შეტყობინების დამატება.

სახელი მითითებულია.

როგორც ჩანს, ცნობილია საათი, როდესაც კორისტუვაჩე მოვა.

როგორც ჩანს, ვინ უარყოფს ინფორმაციას პროცედურის შესახებ.

შეტყობინების სამეტყველო ტექსტი:

——————————————————————————————

Კარგი დღე, !

თქვენი განაცხადის ნომერზე მითითება დავალებები .
ტელეფონი:

სერვისი:
სერვისი:
უკიდურესი ტერმინია virišenya:

———————————————
მომხმარებელთა მხარდაჭერის სერვისი
—————————————————————————————-

ანალოგიურად, ჩვენ ვქმნით შეტყობინებას აპლიკაციის დახურვის შესახებ.

ჩვენ ვაჭერთ შეტყობინებების დამატების ღილაკს სახელის მითითებით - აპლიკაცია დახურულია.

შეტყობინების სამეტყველო ტექსტი:

——————————————————————————————

Აპლიკაციის ნომერი გადავიდა სტატუსში" წარმატებით დაიხურა«!

გადაწყვეტილება:

განაცხადის საგანი:

Vіdpovidalny:
ტელეფონი:

თუ თქვენ არ ხართ კმაყოფილი გადაწყვეტილებებით და გსურთ აპლიკაციის გადაქცევა რობოტებად, გთხოვთ, დაწეროთ თქვენი გამოხმაურება ამ ფურცელზე და დაწეროთ გადაწყვეტილების მიღებისას წარმოშობილი პრობლემების შესახებ.

თუ კმაყოფილი ხართ თქვენი გადაწყვეტილებებით, გთხოვთ, არ დანებდეთ მთელ ამ გვერდზე!

———————————————
მომხმარებელთა მხარდაჭერის სერვისი
——————————————————————————————

გადავიდეთ განყოფილებაში ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – Tickey – Core::Ticket.

Ticket::Hook პარამეტრს აქვს ცვალებადი მნიშვნელობა: Order No.

Ticket::Service პარამეტრების (SLA მხარდასაჭერად) და Ticket::Service::Default::UnknownCustomer მნიშვნელობები არჩეულია ასე.

Ticket::NumberGenerator პარამეტრი დაყენებულია Autoincrement-ზე, რათა იცოდეთ რამდენი მოთხოვნა გაიარა სისტემაში.

ჩვენ ვაჭერთ განახლებებს.

ჩვენ ვარეგულირებთ ჩვენს სერვისებს.

რომელ სერვისს სჭირდება SLA დამატება?

მოდით გადავიდეთ ადმინისტრაციაზე - აპლიკაციების დაყენება - გთხოვთ Riven სერვისის შესახებ - დაამატეთ SLA.

Dodamo SLA ახალი ინსტალაციისთვის პროგრამული უზრუნველყოფის უსაფრთხოება. ჩვენ ვუყენებთ სახელს SLA-ს, ვხედავთ სერვისს, რომლისთვისაც SLA არის გამორიცხული, ვირჩევთ ჩვენს კალენდარს, ვაინსტალირებთ 7200 ხაზს და ვწერთ მოთხოვნას; ესკალაცია ხდება მოცემული საათის 60%-ის შემდეგ. ჩვენ ვაჭერთ გაგზავნას.

შეკვეთა მორგებულია.

გადადით ადმინისტრაციაზე - სისტემის ადმინისტრირება - დავალების დამგეგმავი - დავალების დამატება.

Dodamo ავტომატურად დაბლოკავს განბლოკილ აპლიკაციებს. განაცხადები გადაეცემა რეესტრს მას შემდეგ, რაც მომხმარებელი წარადგენს განცხადებას სამუშაოზე.

ჩემი ოფისი - კრიტიკული შეკვეთების ბლოკირება

ავტომატური ჩვენება - გაშვებისას დღის დროზე არჩევა შესაძლებელია 10-ჯერ, გაშვებისას დღის სადგურზე დღის დაწყებაზე აირჩიეთ ყველა მნიშვნელობა.

აირჩიეთ აპლიკაციები – Stan – Vidkritiy. აპლიკაციის დაბლოკვა – განბლოკილია.

განაახლეთ/დაამატეთ აპლიკაციის ატრიბუტები – დააინსტალირეთ ახალი ბლოკირების სადგური – Blokuvati.

ჩვენ ვაჭერთ გაგზავნას.

სისტემის მხარდაჭერის ნახაზის დამატებითი ამოცანები, რომლებიც ავტომატურად გადააქვთ მოთხოვნებს, ენიჭება სისტემის მხარდაჭერის სპეციალისტს სისტემის მხარდაჭერის ნახაზში.

ავტომატური ჩვენება - გაშვების დროს დღის დროზე არჩევა შესაძლებელია 20-ჯერ, გაშვებისას დღის სადგურზე დღის დასაწყისში აირჩიეთ ყველა მნიშვნელობა.

აირჩიეთ აპლიკაციები – აგენტი/ვლასნიკი – ჩვენ ვიღებთ სპეციალისტებს ტექნიკური მხარდაჭერისთვის.

აპლიკაციის ატრიბუტების განახლება/დამატება – დააინსტალირეთ ახალი დოკუმენტი – სისტემის მხარდაჭერა.

ჩვენ ვაჭერთ გაგზავნას.

მოდით გავაგრძელოთ სისტემის შესწორება.

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ჩარჩო – ძირითადი.

SecureMode დაყენებულია დიახ.

ჩვენ ვაჭერთ განახლებებს.

ჩვენ ვამოწმებთ FQDN, AdminEmail, ორგანიზაცია, NotificationSenderEmail, NotificationSenderName პარამეტრების მნიშვნელობებს.

მოდით გადავიდეთ Framework-ზე – Frontend::Customer

CustomerHeadline – მიუთითებს მხარდაჭერის სერვისის სახელს

CustomerPanelLostPassword – არცერთი (პაროლის განახლების ფუნქცია ჩართულია, რადგან გვაქვს სრული ავტორიზაცია)

CustomerPanelCreateAccount – Ні (მონაცემები აღებულია აქტიური ხიდან)

ჩვენ ვაჭერთ გაგზავნას.

ჩვენ ვავითარებთ სპეციალისტებს აპლიკაციების მონიტორინგის უნარს.

ოჯახებს შეუძლიათ მიიღონ შეტყობინებები ცვლილებების შესახებ მათი კოლეგების მოთხოვნებიდან.

სისტემის კონფიგურაცია - Ticket - Core :: TicketWatcher

ბილეთი::Watcher – დიახ

ვგეგმავთ კვირაში ერთ სამუშაო დღეს.

სისტემის კონფიგურაცია – Ticket – Frontend::Agent

ბილეთი::Frontend::TimeUnits – (ხვილინი)

ჩვენ ვაჭერთ განახლებებს.

ჩვენ ვარეგულირებთ შეტყობინებების ჩვენებას

სისტემის კონფიგურაცია – Ticket – Frontend::Agent::ModuleNotify

ჩართეთ მოსანიშნი ველი Frontend::NotifyModule###5-Ticket::TicketEscalation.

ინტერფეისის პერსონალიზაცია მოთხოვნებთან კომფორტული მუშაობისთვის

ადმინისტრაცია - სისტემის ადმინისტრირება - სისტემის კონფიგურაცია - ბილეთი - წინა ნაწილი:: აგენტი:: მოდულის რეგისტრაცია

ადმინისტრაცია - სისტემის ადმინისტრირება - სისტემის კონფიგურაცია - ბილეთი - წინა ნაწილი:: აგენტი:: ბილეთი:: ViewClose

Ticket::Frontend::AgentTicketClose###სერვისი – დიახ

ადმინისტრაცია - სისტემის ადმინისტრირება - სისტემის კონფიგურაცია - ბილეთი - წინა:: აგენტი:: ბილეთი:: ხედვა წინ

Ticket::Frontend::AgentTicketForward###RequiredLock – არა

Ticket::Frontend::AgentTicketForward###StateDefault — ღია

ადმინისტრაცია - სისტემის ადმინისტრირება - სისტემის კონფიგურაცია - ბილეთი - წინა ნაწილი:: აგენტი:: ბილეთი:: ViewMerge

Ticket::Frontend::AgentTicketMerge###RequiredLock – არა

ბილეთი::Frontend::MergeText – „აპლიკაცია“ აპლიკაციასთან ერთად "

Ticket::Frontend::AutomaticMergeSubject – „მოთხოვნები გაერთიანების შესახებ“

ბილეთი::Frontend::AutomaticMergeText - "აპლიკაცია" აპლიკაციასთან ერთად " ».»

ჩვენ ვაჭერთ განახლებებს.

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ბილეთი – წინა ნაწილი:: აგენტი:: ბილეთი:: ViewOwner

Ticket::Frontend::AgentTicketOwner###სერვისი – დიახ

Ticket::Frontend::AgentTicketOwner###რიგი – დიახ

Ticket::Frontend::AgentTicketOwner###შენიშვნა — არა

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ბილეთი – წინა ნაწილი:: აგენტი::ბილეთი:: ნახვამოუკიდებლად

Ticket::Frontend::AgentTicketPending###RequiredLock – არა

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ბილეთი – წინა მხარე:: აგენტი:: ბილეთი:: ხედვის პრიორიტეტი

Ticket::Frontend::AgentTicketPriority###RequiredLock – არცერთი

Ticket::Frontend::AgentTicketPriority###შენიშვნა — არა

დაამატეთ დამატებითი ღილაკები აგენტის ინტერფეისში ზედა მარცხენა კუთხეში

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ბილეთი – Frontend::Agent::ToolBarModule

მოდი შევამოწმოთ საპირისპირო ველები:

Frontend::ToolBarModule###1-Ticket::AgentTicketQueue

Frontend::ToolBarModule###2-Ticket::AgentTicketStatus

Frontend::ToolBarModule###3-Ticket::AgentTicketEscalation

Frontend::ToolBarModule###4-Ticket::AgentTicketPhone

ჩვენ ვაგროვებთ საგადასახადო პუნქტებს კლერკის სპეციალური ოფისიდან

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ბილეთი – წინა მხარე:: კლიენტი:: TicketViewNew

Ticket::Frontend::CustomerTicketMessage###QueueDefault – სისტემის მხარდაჭერა

Ticket::Frontend::CustomerTicketMessage###სერვისი – არა

Ticket::Frontend::CustomerTicketMessage###SLA – არა (ეს ელემენტი ხელმისაწვდომი გახდება მას შემდეგ, რაც იქნება აპლიკაციების საკმარისი მონაცემთა ბაზა SLA-ის შესაქმნელად)

მნიშვნელოვანია, რომ განმცხადებელმა სპეციალურ ოფისში განსაზღვროს ვინ არის განაცხადის მფლობელი

ადმინისტრაცია – სისტემის ადმინისტრირება – სისტემის კონფიგურაცია – ბილეთი – Frontend::Customer::TicketOverView

Ticket::Frontend::CustomerTicketOverview###მფლობელი – დიახ

ამის საფუძველზე დასრულებულია OTRS-ის დაყენება.

(ოკალმის წყარო თისკეტი რცხენოსნობა ს ystem) – ეს არის აპლიკაციების დამუშავების ღია სისტემა, რომელიც უზრუნველყოფს ერთიანი კონტაქტის პუნქტს ბუღალტერებისთვის, IT პერსონალისთვის, IT სერვისებისთვის, ასევე ნებისმიერი გარე ორგანიზაციებისთვის. პროგრამა დაწერილია პერლში. OTRS მხარს უჭერს არაპერსონალურ მონაცემთა ბაზებს (MySQL, PostgreSQL და ა.შ.) და ინტეგრაციას LDAP დირექტორიებთან.

ეს სახელმძღვანელო დაგეხმარებათ დააინსტალიროთ და დააკონფიგურიროთ OTRS CentOS 7 სერვერზე.

ვიმოგი

• CentOS 7 სერვერი;
• Chi nonroot koristuvach სუდოზე წვდომით (კორისტუვაჩის პრივილეგიების შესახებ შეგიძლიათ წაიკითხოთ აქ);
• 4 GB swap სივრცე (სვოპის დაყენების შესახებ - იხილეთ ეს სახელმძღვანელო).

1: დააინსტალირეთ MariaDB

ჯერ უნდა დააინსტალიროთ ყველა OTRS კომპონენტი.

ამისთვის დაგჭირდებათ EPEL (Extra Packages for Enterprise Linux) საცავი. იოგოს დამატება:

sudo yum install epel-release

განაახლეთ სისტემა:

დააინსტალირეთ MariaDB (MySQL ფანჯარა):

sudo yum დააინსტალირე mariadb-სერვერი mariadb

იმისათვის, რომ OTRS-მა სწორად იმუშაოს, თქვენ უნდა შეცვალოთ ნაგულისხმევი MySQL პარამეტრები. გახსენით კონფიგურაციის ფაილი vi რედაქტორში:

sudo vi /etc/my.cnf

დაამატეთ შემდეგი სტრიქონები განყოფილებაში, სადაც მითითებულია ამ ფაილების ზომები:

max_allowed_packet = 20M
query_cache_size = 32M
innodb_log_file_size = 256M
datadir=/var/lib/mysql
. . .

შეინახეთ და დახურეთ ფაილი.

შენიშვნა: თქვენ უნდა განახორციელოთ ეს ცვლილებები MySQL-ის დაწყებამდე

დაიწყეთ MariaDB:

sudo systemctl დაწყება mariadb.service

გაუშვით MySQL სკრიპტი, რომელიც შლის ყველა სახიფათო პარამეტრს.

sudo mysql_secure_installation

სკრიპტი გააქტიურდება. სტანდარტული მნიშვნელობების მისაღებად, უბრალოდ დააჭირეთ Enter ღილაკს. თქვენ აუცილებლად უნდა შეცვალოთ სტანდარტული root პაროლი. აირჩიეთ საიმედო პაროლი.

2: დააინსტალირეთ OTRS

შეგიძლიათ დააინსტალიროთ OTRS წინასწარ შედგენილი RPM პაკეტის გამოყენებით. ჩამოტვირთეთ ეს პაკეტი პროგრამის ოფიციალური საცავიდან.

შენიშვნა: უპირველეს ყოვლისა, გთხოვთ გადმოწეროთ პაკეტი, შეამოწმოთ რა არის დარჩენილი ვერსია.

wget http://ftp.otrs.org/pub/otrs/RPMS/rhel/7/otrs-5.0.7-01.noarch.rpm

დააინსტალირეთ OTRS:

sudo yum დააინსტალირე otrs-5.0.7-01.noarch.rpm

OTRS პროგრამა დაწერილია Perl-ში, რომელიც მოითხოვს Perl მოდულების მუშაობას. ყოველდღიური მოდულების იდენტიფიცირებისთვის გამოიყენეთ CheckModules.pl სკრიპტი (მოწოდებულია OTRS პაკეტში):

sudo /opt/otrs/bin/otrs.CheckModules.pl

ხატი ასე გამოიყურება:

o Apache::DBI...................ok (v1.12)
o Apache2:: გადატვირთვა................ ვერ მოხერხდა! ამ მოდულის ყველა წინა დამცავი არ არის დამონტაჟებული სწორად.
. . .
o XML::LibXSLT................ok (v1.80)
o XML:: Parser...................ok (v2.41)
o YAML::XS........................ არ არის დაინსტალირებული! გამოიყენეთ: "yum install "perl(YAML::XS)"" (საჭიროა - ძალიან მნიშვნელოვანია)

ეს მოდულები საჭიროა მხოლოდ დამატებითი ფუნქციებისთვის (მაგალითად, სხვა მონაცემთა ბაზებთან დასაკავშირებლად ან ფოსტის დასამუშავებლად ჩინური სიმბოლოების გამოყენებით). ყოველდღიური მოდულების დასაყენებლად, მიჰყევით ქვემოთ მოცემულ yum ბრძანებებს.

sudo yum install "perl(Apache2::Reload)" "perl(Crypt::Eksblowfish::Bcrypt)" "perl(Encode::HanExtra)" "perl(JSON::XS)" "perl(Mail::IMAPClient) " "perl(ModPerl::Util)" "perl(ტექსტი::CSV_XS)" "perl(YAML::XS)"

ყველა საჭირო მოდულის დაინსტალირების შემდეგ, ხელახლა გაუშვით სკრიპტი გადატვირთვისთვის, რათა ყველაფერი გადმოიწეროს.

3: OTRS-ის დაყენება

ახლა თქვენ უნდა დააყენოთ მონაცემთა ბაზა და OTRS ფოსტა. სასწრაფოდ გადატვირთეთ Apache OTRS პარამეტრების განახლებისთვის.

sudo systemctl გადატვირთეთ httpd.service

ახლა გახსენით ინსტალერის ვებ გვერდი:

http://your_server_ip/otrs/installer.pl

სასიცოცხლო გვერდი გამოჩნდება ეკრანზე. დააჭირეთ ღილაკს შემდეგი. ამის შემდეგ თქვენ იღებთ ლიცენზიას; წაიკითხეთ და დააჭირეთ ლიცენზიის მიღებას და გააგრძელეთ.

შემდეგ გვერდზე თქვენ უნდა აირჩიოთ მონაცემთა ბაზა. ჩამოსაშლელი მენიუდან აირჩიეთ MySQL და დააწკაპუნეთ OTRS-ისთვის ახალი მონაცემთა ბაზის შექმნა (რაც ნიშნავს, MySQL მონაცემთა ბაზა განკუთვნილია დამუშავებისთვის). დააჭირეთ ღილაკს შემდეგი.

ამის შემდეგ აუცილებელია MySQL მონაცემთა ბაზის ადრე შექმნილი ღრუბლოვანი მონაცემების მითითება. იმისათვის, რომ დარწმუნდეთ, რომ შეყვანილი მონაცემები სწორია, დააჭირეთ მონაცემთა ბაზის პარამეტრების შემოწმებას.

ინსტალერი ქმნის ღრუბლოვან მონაცემებს ახალი მონაცემთა ბაზისთვის. არ არის საჭირო ამ გენერირებული პაროლის დამახსოვრება და არ დაგჭირდებათ დარჩენილი პაროლები, უბრალოდ დააჭირეთ შემდეგს გასაგრძელებლად. ამის შემდეგ, ინსტალერი შექმნის ახალ მონაცემთა ბაზას. დააჭირეთ ღილაკს შემდეგი.

ამის შემდეგ თქვენ უნდა მიუთითოთ სისტემის პარამეტრები:

• FQDN: დომენის სახელი ან სერვერის IP მისამართი.
• ადმინისტრატორის ელფოსტა: სისტემის ადმინისტრატორის ელ.ფოსტის მისამართი. აქ არის პროგრამა დამატებითი ინფორმაციისთვის ცვლილებების შესახებ.
• ორგანიზაცია: ორგანიზაციის დასახელება.

სხვა პარამეტრების წაშლა შესაძლებელია ცვლილებების გარეშე.

იმისათვის, რომ შეძლოთ ელექტრონული ფურცლების ამოღება კორესპონდენტებისგან, თქვენ უნდა დააყენოთ თქვენი შემომავალი ფოსტა.

იპოვეთ განყოფილება Configure Inbound Mail და მიუთითეთ საჭირო მონაცემები. მაგალითად, თუ იყენებთ Google საფოსტო პროვაიდერს, შეგიძლიათ შექმნათ პაროლი პროგრამისთვის და შეიყვანოთ შემდეგი მონაცემები:

• შემომავალი ფოსტის ტიპი: IMAPS
• შემომავალი ფოსტის ჰოსტი: imap.gmail.com
• შემომავალი ფოსტის მომხმარებელი: your_email_address
• შემომავალი ფოსტის პაროლი: your_app_password

კონფიგურაციის შესამოწმებლად დააჭირეთ ღილაკს. სულ რამდენიმე წამში გამოჩნდება შეტყობინება:

ფოსტის შემოწმება წარმატებით დასრულდა

დააწკაპუნეთ OK დარჩენილ ეკრანზე გადასასვლელად.

OTRS-ის დაყენება და დაყენება დასრულებულია!

Მნიშვნელოვანი!არ დაგავიწყდეთ კორისტუვაჩის გენერირებული პაროლის ჩაწერა [ელფოსტა დაცულია]და მთავარი გვერდის URL.

ახლა თქვენ მხოლოდ უნდა დაიწყოთ OTRS დემონი და გაუშვათ ეს cronjob:

sudo su - otrs -c "/opt/otrs/bin/otrs.Daemon.pl დაწყება"
sudo su - otrs -c "/opt/otrs/bin/Cron.sh დაწყება"

4: ზახისტური OTRS

ამ დროისთვის თქვენ გაქვთ სრულიად ფუნქციონალური დამატება. თუმცა, არ არის უსაფრთხო superkoristuvach-ის ანგარიშის OTRS-თან ვიკორისტოტვა. ამიტომ მას ახალი აგენტის შექმნა სჭირდება.

OTRS-ში აგენტებს უწოდებენ აგენტებს, რომლებსაც აქვთ წვდომა სისტემის ფუნქციებზე. თითოეულ აპლიკაციას აქვს ერთი აგენტი, რომელიც იძლევა წვდომას ყველა OTRS ფუნქციაზე.

ახალი აგენტის შესაქმნელად, დატოვეთ როგორც პროფესიონალი [ელფოსტა დაცულია]გახსენით შეტყობინება, გააუქმეთ ინსტალაციის ბოლოს და შეიყვანეთ მომხმარებლის სახელი [ელფოსტა დაცულია]და პაროლი (მე-3 ნაწილის დასასრული).

მთავარი პანელი გამოჩნდება ეკრანზე. თქვენ შეგიძლიათ განათავსოთ რამდენიმე ვიჯეტი, რომელიც აჩვენებს სხვადასხვა ინფორმაციას ბილეთების, სტატისტიკის, სიახლეების და ა.შ. თქვენ შეგიძლიათ მარტივად დააკონფიგურიროთ ისინი შეკუმშვის მეთოდით ან გამოწუროთ ისინი კორექტირებიდან.

თქვენ დაუყოვნებლივ უნდა შექმნათ ახალი აგენტი. მართვის პანელის ზედა ნაწილში, პანელი ნაჩვენები იქნება წითლად:

არ გამოიყენოთ სუპერმომხმარებლის ანგარიში OTRS-თან მუშაობისთვის! შექმენით ახალი აგენტები და იმუშავეთ ამ ანგარიშებით. →

ახალი აგენტის შესაქმნელად დააწკაპუნეთ შეტყობინებაზე და შემდეგ დააწკაპუნეთ აგენტის დამატებაზე. ეკრანზე ბევრი ველი გამოჩნდება. საბედნიეროდ, არ არის აუცილებელი ყველა ამ სფეროს დაფარვა - ტრენინგის უმეტესობა შესაფერისია სამუშაოსთვის. თქვენ მხოლოდ უნდა შეავსოთ სახელი, გვარი, მომხმარებლის სახელი, პაროლი და ელ.ფოსტის ველები.

ამის შემდეგ, თქვენ უნდა შეცვალოთ ახალი აგენტის ჯგუფური ანგარიშები. ახალი აგენტი ასევე იქნება ადმინისტრატორი და დასჭირდება წაკითხვისა და წერის უფლებები ყველა ჯგუფისთვის. ვისთვის უნდა დავაყენო ენსინი RW-დან Change Group Relations for Agent-ის პარამეტრებში.

დააჭირეთ გაგზავნას. ახლა შეგიძლიათ გამოხვიდეთ superkoristuvach ანგარიშიდან და დარეგისტრირდეთ ახალ აგენტზე. გადაცემათა კოლოფის ხატულაზე დაწკაპუნებით ეკრანის ზედა მარცხენა კუთხეში, შეგიძლიათ შეცვალოთ აგენტის პარამეტრები (შეცვალეთ პაროლი, აირჩიეთ ინტერფეისი, დააკონფიგურიროთ შეტყობინებები, ბარათები, ინტერფეისის თემა და მრავალი სხვა).

5: ქვითრების მართვა

ახლა მოდით გადავხედოთ კერუვანნიას ქვითრებით. კლიენტებს შეუძლიათ OTRS-ში ქვითრების დამატება ორი გზით: დამატებითი ინტერფეისის საშუალებით ან ელექტრონული ფოსტით.

http://your_server_ip/otrs/customer.pl

აქ შეგიძლიათ შექმნათ საბანკო ანგარიში და გაგზავნოთ ქვითარი.

თქვენ ასევე შეგიძლიათ შექმნათ ახალი ბილეთი ფურცლის გაგზავნით ელ.ფოსტის მისამართზე, რომელიც მითითებულია ჩასმის დროს. ფოსტით მიღებული ყველა ქვითარი ინახება ერთ ადგილას და აქვს უმაღლესი პრიორიტეტი. კლიენტის ყველა ქვითრის ნახვა შესაძლებელია კლიენტის ვებ ინტერფეისიდან, მიუხედავად იმისა, თუ როგორ გაიგზავნა ისინი.

სხვა ინტერფეისში შექმნილი ყველა ახალი ბილეთი დაუყოვნებლივ გამოჩნდება აგენტის პარამეტრების პანელზე. ფოსტით გაგზავნილი ქვითრები დაუყოვნებლივ ვერ გამოჩნდება დაფაზე, ამიტომ OTRS ამოწმებს ახალი ქვითრების ხელმისაწვდომობას ყოველ 10 წუთში.

აგენტის პარამეტრების პანელზე შეგიძლიათ იპოვოთ ინფორმაცია ყველა მიმდინარე ბილეთის შესახებ: მათი სტატუსი (ახალი, გახსნილი, ესკალაცია და ა.შ.), მათი „დრო“ (საათი, რომელიც გავიდა ბილეთის გაუქმების მომენტიდან) და თემა.

ბილეთის დეტალების სანახავად შეგიძლიათ დააჭიროთ თქვენს ნომერს ბილეთის # დახლზე. რომელ ფანჯარაშიც შეუძლია აგენტს ბილეთთან ურთიერთობა (პრიორიტეტის ან სტატუსის შეცვლა, სხვა ფანჯარაში გადატანა, დახურვა და ა.შ.).

შენიშვნა: შეგიძლიათ გაიგოთ მეტი OTRS პროგრამის შესახებ ოფიციალურ სახელმძღვანელოში.

ტეგები: ,