OTRS Ticket rendszer

Fórumok

Sziasztok!

OTRS Ticket rendszerben járatos fórumozót keresnék.
Felvázolnám, hogy milyen igények lennének, aki jártas benne, minden bizonnyal meg tudja mondani, hogy megfelelő-e az OTRS ezekre az igényekre, vagy sem.
Amennyiben akad itt hozzáértő, akkor meg is bíznánk a rendszer beélesítésével (persze nem kérjük ingyen).
Használunk egy régebbi OTRS-t jelenleg is, nem vagyunk teljesen analfabéták benne.
Ha van köztetek olyan, aki segíthet, jelezzétek és írom az igényeket!

Mono

Hozzászólások

Az olvasások és jelentkezések számának arányából ítélve lehet, hogy jobb lett volna legalább egy kicsit körülírni, hogy mire is kell az OTRS. Mi épp most akarunk majd a cégnél átállni OTRS-re, mert az RT kissé bugzik.
Ha leírod, hogy mire is kellene, akkor lehet, hogy tudok tanácsot adni. Ha mást nem, akkor az RT-t :)

Mi kb 9 éve használunk RT-t, most járunk másfél millió ticket körül. Szeretjük, de persze nem a szépsége :) hanem inkább a stabilitása és jó testreszabhatósága miatt.
Biztos vannak bugjai (egy csomót mi is kijavítottunk már az évek során), de szerintem nincs benne megoldhatatlan feladat.
Mondjuk mi elég sokat hozzá is fejlesztettünk, csináltunk kb 40 plugint, meg saját témákat és saját fordítást is, ja és csomó helyen telepítettük és segítettünk bevezetni, jelenleg üzemeltetünk kb 30 RT-t.
Szóval ha valamilyen RT buggal kapcsolatban van kérdésed, akkor dobj egy privát üzenetet hátha tudok segíteni és talán akkor nem vérzik el az OTRS-el szemben...

Igazából nem az én döntésem, tehát a legkevesebb beleszólással rendelkezem. Én max megoldom azt amit fentről rám szórnak. :)
Legutóbb az egyik problémám abból akadt, hogy több tld alól is használjuk a rendszert, és nem sikerült a 3.8.8 feletti rendszerrel megetetni ezt. Emiatt visszakerült a 3.8.8. Ezután egy perl frissítés keserítette meg az életemet, mert pár oldalnyi kódot kellett átnyálaznom, úgy hogy nem vagyok programozó. Összességében nagyon jó rendszer, de a vezetőségnek nem tetszik.

"Összességében nagyon jó rendszer, de a vezetőségnek nem tetszik."

Hát az biztos, hogy elég rosszul adja el magát az RT, összehasonlítva mondjuk az OTRS, vTiger, Jira, stb.-vel.
Gyenge honlap, viszonylag csúnya kinézet, és nem eléggé felhasználóbarát felület (admin sem), szerintem nem a legjobb az alapkonfiguráció sem, és még a telepítés is nehézkesebb, mint más szoftvereknél (mármint forrásból). Pedig a "tudása" alapján szerintem van olyan jó, mint a többi hasonló szoftver, a fejlesztői pedig profik, csak sajnos nagyon kockák, ezért nem gyúrnak a kinézetre meg felhasználóbarátságra :(

Keresd a CNW-t ha hozzáértőt szeretnél. Nálunk is ők támogatják.
Vannak hozzá fejlesztéseik is.

Hello!

Mi OTRS-t használunk jó ideje. Volt szerencsém a teljes telepítési, konfigurálási folyamatot végigvinni (Oracle db, LDAP integrációval, API hívás másik rendszerből stb.). Ha van konkrét kérdésed, akkor szívesen válaszolok rá, ha tudok.

Nálunk 2013. augusztusában vezettem be az OTRS-t több-kevesebb sikerrel egyedül. Még nem használjuk ki a rendszer tudását teljesen. Elég sok buktató is volt, amelybe belefutottunk pl: zárolások feloldása. Ha van konkrét kérdésed, akkor szívesen segítek, ha tudok.

Köszönöm hozzászólásaitokat, abban sem voltam biztos, hogy bárki is itt hallott már erről, ezért nem írtam többet az elején. Kellemesen csalódtam! :)

Szóval használunk OTRS-t, kb. 15-20 frissítéssel le vagyunk maradva az aktuális verziótól, de nem feltétlen szükséges az adatok migrálása, egy új, tiszta rendszerrel is elindulhatnánk.
A jelenlegi felállás szerint vagyunk ketten adminisztrátorok, akik kapjuk a ticketeket és van két customer (?) jogú ügyfél, akik ugyanazon cégnél dolgoznak. Ők dobálják fel a ticketeket, mi pedig feldolgozzuk őket. Mindezt teljesen a webes felületen keresztül tesszük.

Amit szeretnénk:
- Legyen továbbra is meg a webes felület (gondolom ez nem probléma, de leírom :) )
- az ügyfelek általunk megadott módon láthassák, vagy ne láthassák egymás ticketjeit, attól függően, hogy egymásnak kollégái-e, azaz a mi szemszögünkből nézve egy ügyfélnél vannak-e/dolgoznak-e, vagy sem. Másként nézve valami csoportokat kellene tudni létrehozni egy-egy ügyfélhez, lesznek csoportok, melyekben egy-egy, míg másban több ügyfél felhasználó is van. A csoportoknál fogva lenne célszerű a ticketekre való "rálátási jogosultságot" meghatározni.

- mi, mint adminisztrátorok közül (lehet, hogy nem a legjobb megfogalmazás, mint ticketeket látó és feldolgozó egyének :) ) szintén legyenek megadhatóak, mely ügyfelek ticketje látszódhatnak, melyek nem. Másként fogalmazva ne minden "ticketfeldolgozó" lásson rá minden ügyfél ticketjére, csak azokra, melyek az ő hatáskörébe tartoznak.

- bizonyos ügyfelek számára úgy szeretnénk a hibajegyet felvetetni, hogy ő egy e-mail-t ír egy bizonyos címre. Ezt a rendszer fogadja, pattanjon vissza a feladónak egy automatikus e-mail üzenet, hogy "fogadtuk a problémáját, az Ön hibajegy száma a 1124334155 lett, kollégánk hamarosan válaszolni fog", a szám az legyen, amit a hibajegy rendszer generált. Ez az e-mailből generált hibajegy ugyanúgy kerüljön be a rendszerbe, mintha webes felületen jött volna létre (gondolom itt prioritás beállításra nem lesz mód, de ez nem is baj).
Ha utána a rá jogosult hibajegyfeldolgozó válaszolni akar erre a hibajegyre, akkor a rendszer tudja visszaküldeni arra a mail címre, ahonnan az eredeti kérés elindult - azt gondolom, hogy az e-mail tárgyában is szereplő hibajegy szám megfelelő összepárosító tényező lehet ehhez.
Az e-mailben generálódó hibajegyet az OTRS-en belül a rá jogosult feldolgozó egyének egymás között ki tudják beszélni, egymásnak át tudják adni, a ticket lezárásakor pedig e-mailben menjen a válasz az eredeti feladó e-mail címére.
Természetesen prioritást, eltöltött időt lehessen számolni ezen ticketekre is.

Hát kb. ennyi lenne. Soknak tűnik leírva (talán), de annyira szerintem nem bonyolult a dolog.
Egyfelől lényegében az ügyfelek és a ticket feldolgozó jómunkásemberek jogosultságait kellene szabályozni, ki mit láthat, ki mire láthat rá alapon.
Másfelől pedig néhány olyan e-mail címet kellene kezelnie, amire bármilyen feladói mail címről bárki bejelenthet egy hibát, ezeket is attól függően kellene társítani a feldolgozó egyénekhez, hogy milyen e-mail címre érkezett a beküldés - egy-egy ügyfélként fognánk fel a különböző fogadó mail címeket.

Nem tudom, hogy érthető voltam-e? - remélem igen :)
Mivel az OTRS-t ismerjük, megszoktuk, ingyenes, rendben kezeli az ékezetes betűket, illetve maga a webes felület is magyar (néhány ügyfelünk számára ez fontos szempont), lehetőleg maradnánk ennél.
De nem tudom, hogy egyáltalán ezeket a dolgokat tudja-e, s ha igen, akkor van-e olyan köztetek, aki már állított be így egy ilyen rendszert?

Válaszolok röviden:
- "bizonyos ügyfelek számára úgy szeretnénk a hibajegyet felvetetni...."
Ez a rész megoldható. Nálunk ugyanígy üzemel a rendszer. Itt testre lehet szabni, hogy pontosan mikor menjen ki az ügyfélnek a levél és milyen szöveggel. Természetesen a levélbe belekerülhet a hibajegy száma is. Ha erre a kapott levélre az ügyfél válaszol, akkor az automatikusan bejön az OTRS-be és a már meglévő hibajegyhez kapcsolódik. Így jól el tud levelezni az OTRS felhasználó az ügyféllel.

- "mi, mint adminisztrátorok közül..."
Ezt is megoldottam nálunk. Több várólista van és a várólistákhoz rendeltem a megfelelő szerepköröket/csoportokat a megfelelő jogosultsággal.

- A webes felület nem gond. :)

- "az ügyfelek általunk megadott módon láthassák..."
Ez a rész nem teljesen világos, még gondolkodok a megvalósításon. Nálunk még a customer felület nem üzemel.
Frissítés: Ha jól értem, akkor azt akarod, hogy bizonyos típusú hibajegyek láthatóak legyenek mindkét ügyfélnek vagy csak egyiknek. Lehet, hogy egyszerűbb lenne egy FAQ-t gyártani a megfelelő hibajegyekből, amit publikálsz az OTRS-ben megfelelő csoportoknak. Az FAQ-t testre is szabhatod, így nem kell belekerülnie a teljes hibajegynek.

1-2-3 pont tiszta jó! :)

A négyes:
"- "az ügyfelek általunk megadott módon láthassák..."
Ha jól értem, akkor azt akarod, hogy bizonyos típusú hibajegyek láthatóak legyenek mindkét ügyfélnek vagy csak egyiknek."
Igen! Eddig szerintem értjük egymást.
De példálózok, talán egyszerűbb.

Van Péter és Gábor, akik a ceg1-nél dolgoznak, saját customer belépésük van. Szórják fel a ticketeket, de mivel egy cégnél dolgoznak, szerencsés lenne, ha látnák, hogy melyikük mit rakott már fel, arra esetleg milyen választ kapott már eddig, stb.
Aztán van Juli, ceg2-nél, akinek szintén szeretnénk látni a hibajegyeit, de Juli ne lássa Péter és Gábor ticketjeit - és persze fordítva.
Mindannyiuk ügyfelek! Két cég van (csoport?), de három felhasználó, egyedi belépéssel.

Egyszerűbb lenne ceg1-el és ceg2-vel belépni, viszont várhatóak olyan hús-vér ügyfelek, akik több céget is képviselnek, így valamikor user, valamikor csoport szinten lehet (illetve érdemes) megadni a jogokat.

Így érthetőbb voltam esetleg? Vagy nagyon elbonyolítom? Mert ha ilyet is tud az OTRS, akkor már csak egy jelentkezőre várnék, akivel megegyezhetünk :)

"Lehet, hogy egyszerűbb lenne egy FAQ-t gyártani a megfelelő hibajegyekből, amit publikálsz az OTRS-ben megfelelő csoportoknak. Az FAQ-t testre is szabhatod, így nem kell belekerülnie a teljes hibajegynek."
Itt viszont totál elvesztettem a fonalat... :( Nem értem ezt a FAQ dolgot :(

Péter és Gábor CustomerID-je ceg1, Juli CustomerID-ja ceg2, és létre kell hozni 2 Customer Company-t, melyek CustomerID-ja nem meglepő módon szintén ceg1, illetve ceg2. Azt pedig be lehet állítani, hogy azonos Customer Company-hoz tartozó Customer-ek lássák egymás hibajegyeit (talán ez alapbeállítás is, a Customer portálon a Tickets->Company Tickets alatt látszanak).

Tiszta és világos az igényed. Hétvégén letesztelem nálunk timar kolléga megoldását és le is írom az eredményt.

Az FAQ jelentése gondolom tiszta. OTRS-nél meg tudod azt tenni, hogy egy ticketből FAQ-t generálsz, amelyet aztán az OTRS FAQ oldalán publikálsz. Így egy jól kereshető, használható tudásbázist építhetsz fel az ügyfeleknek. Pl: 10. alkalommal jön ugyanaz a kérdés, akkor hivatkozhatsz az FAQ-ra. A https://www.otrs.com/try/ oldalon nézhetsz demokat is - a standard verziókat nézd.

Nektek az ITSM modulra van szuksegetek, ez lehetove teszi, hogy a customerekhez kulonfele customer usereket rendeljetek, kulonfele jogosultsagokkal.

A customer a ceg1 es ceg2 lenne, ezen belul lenne Peti es Laci mint customer user.

A problemat valoszinuleg inkabb az az elvetett mondat jelenti, miszerint elkepzelheto, hogy lennenek olyan customer userek, amelyek egyszerre tobb ceghez is tartoznak. Ez az, ami szerintem kisse nehezen megvalosithato, bar nem mondom azt, hogy lehetetlen, mert nem tudom, az ITSM enged-e egy customer usert tobb customerhez felvenni.

Igazabol itt az a kerdes, hogy erre miert lenne szukseg. Nehez olyat elkepzelni, hogy valaki egyszerre ket cegnek is dolgozik...
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Viszonylag frissek az emlékeim, a sima OTRS Help Desk 3.2-es verziót vezettem be (nem ITSM). Ebben még azt is meg lehet csinálni a korábban említetten kívül, hogy a customer user CustomerIDs mezőjébe fel lehet venni azokat a CustomerID-kat pontosvesszővel elválasztva, akiket magán kívül látnia kell. Ez használható arra, hogy több céget lásson, mivel a CustomerID-nak nem kell egyedinek lennie, használhatjuk a customer company-k azonosítására és a felhasználók cégekhez rendelésére. (link)

Igen, ez a ganyolos ut. Ezt olvastam en is, de eroteljes ketelyeim vannak az upgradelhetoseget illetoen, illetve en egyszeruen pocsek megoldasnak tartom.

Az ITSM modulnak mar a Core resze tartalmazza a Customer Company-kat, nem is kell semelyik ITSM modult engedelyezni pluszban hozza, raadasul anelkul teszi ezt mukodokepesse, hogy akar az adatbazissemaba, akar az OTRS kodjaba magaba bele kellene nyulni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Ha még aktuális a dolog, akkor mi nagyon szívesen segítünk. Alaposan beleástuk magunkat a rendszerbe, és mi is meglepődtünk, hogy a 4-es verzió mennyi mindent tud már! Egyértelműen frissíteni kell a korábbi verziókról, a biztonsági javítások mellett sok új funkciót is tartalmaz - és a magyar nyelvi támogatás is sokkal jobb lett. A http://otrs-megoldasok.hu/ oldalon fel tudod venni velünk a kapcsolatot.

Annyit mondhatok, hogy az OTRS db sema szinten egy okadek. De tenyleg, egy mocsok. A Redmine ellenben nem. Ott van nemi nyoma a tervezesnek. Ezen kivul mar tul vagyok nehany Redmine upgrade-en is, es mindig total gordulekenyen ment, tulzas nelkul par perc alatt. OTRS-t egyszer probaltunk, aztan inkabb letettunk rola :)

Persze tisztaban vagyok vele, hogy a ketto elegge tavoli rokona egymasnak. De a rendszertol fuggetlenul igaz, hogy minel kevesebb szemetet (=pluginek es tarsai) raksz fel, annal kevesebb fejfajastol kimeled meg magad a kesobbiekben.

Éppen kutatok egy jó rendszer után, amiben kvázi egy dashboard-ot kellene letrehoznom, különféle külső rendszerek (Salesforce, Jira, stb) integrálásával. Olyan ötletek is vannak, hogy az üzleti folyamataink által generált logok feldolgozása utáni hibajegyeknek, riportoknak is valahogy meg kellene jelennie, tehát erős scriptelési lehetőségek kellenek (lehetőleg Perl, vagy Python)

Redmine-ban van ilyesmire lehetőség? Más tippek is érdekelnek, de az OTRS kicsit nem szimpi a fent olvasottak fényében.

Köszönöm!

En dolgoztam mar az OTRS semajaval, egeszen turheto, csak tudni kell, hogy epul fel maga az OTRS belulrol.

A Redmine-nal inkabb a gyakran valtozo API a problema. Nekunk van par fejlesztesunk, amik egyre kevesbe mukodnek az ido elorehaladtaval, mert eleg gyakran valtozik a belso API. Ugyanakkor en fejlesztettem az OTRS-hez is, es mindosszsen az SQLite db modul valt mukodeskeptelenne, valoszinuleg az is inkabb azert, mert eleve nem egy 100%-os modult csinaltam, es olyan semat kellene legyartania, amire nem keszitettem fel.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

az OTRS sémája egyértelmű és jól átlátható.

DE

mi az, hogy étírod egy jegy dátumát. Az OTRS lényege pont az, hogy ITIL alapú. Olyan nincs, hogy te adatbázisban átirogatsz dolgokat. NO WAY! Ugyanúgy, ahogy törölni sem lehet, csak invalid-ba tenni, mivel olyan nincs, hogy egy auditálható rendszerből te eltávolítasz meg átírsz adatokat.

Hidegen hagy az ITIL. Ahol volt olyan nap, hogy egyszeruen leirni nem volt ido, miket csinaltunk, csak masnap, viszont elo volt irva, hogy minden napra kell az ido legalabb 90%-at lefedo ticket, kulonben levonjak a beredbol, akkor szukseg volt ilyenre is.

Es egyebkent is, tokeletesen irrelevans a hatter. A lenyeg, hogy ha ugyanaz az adat 5 helyen van tarolva, akkor az teljesen egyertelmuen hibas tervezes, ITIL ide vagy oda. Ez 2-es verzio volt, a 3-assal nincs tapasztalatom, elorelathatolag nem is lesz.

Az OTRS-ben sehol nincs két, vagy több helyen tárolva az adat. Nem értem miről beszélsz, de mivel nem is fogsz vele foglalkozni asszem nem is érdemes ezen tovább rugózni. :D

De az adatbázisa a lehető legtökéletesebben van megtervezve...

Valószínűleg azért nem volt idő semmire sem, mert annál a cégnél nem szabályozták a folyamatokat ITIL alapján. :D

Szia,

Szerintem uljunk le es beszeljuk at a pontos igenyeket, budapesti vagyok.
Tudok segiteni a telepitestol az integracioig, van benne tapasztalatom.
Alapvetoen amit eddig lattam a hozzaszolasokban kivitelezheto, de gondolom ez csak egy nagyon kicsi resze az igenyeknek.

Udv:
Mark