Cégeteknél használjátok az OTRS rendszert?

Szoftver

igen
19% (42 szavazat)
nem, más nyíltforrású rendszert használunk (válaszban leírom)
15% (33 szavazat)
nem, más zártforrású rendszert használunk
35% (79 szavazat)
nem használunk hiba-, esetkezelő rendszert
31% (69 szavazat)
Összes szavazat: 223

( 1soproni | 2014. 09. 11., cs – 19:48 )

A mostani munkahelyemen OpenERP van. Az előzőnél OTRS volt, és nagyságrendekkel jobb volt.

( djsmiley v | 2014. 09. 11., cs – 21:17 )

RequestTracker, i know bughalmaz, de szeretjük.

( Tassadar v | 2014. 09. 12., p – 07:27 )

Általánosságban mi a véleményetek az issue-kezelő rendszerekről? Az átláthatóság mellett növelik a hatékonyságot is?

ha esszel hasznaljak, akkor igen, noveli, ill. nincs tobbe a tobbi level kozott megbujo ugy, ami elsikkad, mert az issue tracker-ben egeszen addig az arcodba vilagit a piros szin, amig meg nem oldod.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Emailt is meg tudsz jelölni.

Nálunk alapvetően implementálási hibák miatt az zavar benne, hogy jellemzően többen dolgozunk egy csoportban, de a ticketet csak 1 ember látja.
Így, előfordulhat, hogy más csuklóból megoldaná a problémát, de a ticket tulajdonosának utána kell néznie.
Vagy nem tudod, hogy más mivel foglalkozik, nem tudsz arra rákérdezni, a válaszából fejlődni.
A ticketet nincsenek feladat szerint csoportosítva, így csak a lezárás ideje számít, az megjósolhatatlan, hogy milyen jellegű feladat volt.
Illetve, általánosságban célként tekintenek rá és nem eszközként: a megoldás minősége nem számít, csak az idő és a ticket mennyisége.

A kis optimista (vagy irigyellek)

Még minden komolyabb rendszerben amit láttam volt olyan 80-200 közötti soha meg nem oldott issue.

Rámassignolva csak a dizájnerprojektben jelenleg 22 issue van, ez a "javítsunk ki kisebb usability hibákat egy oldalon"-tól a "tervezzük újra a teljes platformot bizonyos szempontból" méret közt váltakozik, az egyik issue most épp kerül ki, két gombot kell hozzáadni egy dialógushoz. Ezen kívül a fejlesztési projektben van még 4-5, többsége hirtelen lendületből került be oda vagy nem várt komplikációk léptek fel.

A dizájnerprojektben továbbá van kb 60 issue ami már akkor ott volt amikor jöttem. A fejlesztői projektekben százasával vannak ilyenek.

Egy részük könnyen lehet hogy sose lesz megoldva.

S ahány issue trackert láttam (mondjuk mindig fejlesztésben, és jellemzően jira-ról beszélünk) mind ilyen volt...

Egyrészt azért a van annak előnye, ha az ilyen issuek is látszanak (egyrészt adott esetben bekerülnek, másrészt ha nem, oda lehet tenni, hogy wontfix és miért), lehet velük tervezésnél törődni.

Másrészt operationsban azért ez kicsit más, mint egy bugtrackernek is használt fejlesztői issue tracker, márpedig az otrs inkább az. Ha még ráadásul itsm is van, és ezek a nyitott faszságok rá vannak linkelve a cmdbre, akkor az baromi hasznos, ha valaki valami más miatt hozzá kell nyúljon a nodehoz...

( zrubi v | 2014. 09. 12., p – 09:25 )

Nálunk teljes káosz van ezügyben, mert többféle egymástól teljesen független rendszer is létezik:

- SCOUT
Ez durván elbonyolított, a (webes) felülete teljesen hassználhatatlan, és k. drága is.

- JIRA
Egy fokkal átláthatóbb, de ezt nagyon keveset használom.

- OTRS
Open Source megoldás, ITSM modullal full ITIL kompatibilis, könnyen testreszabható, plugin-okkal bővíthető cucc.

--
zrubi.hu

( laja | 2014. 09. 12., p – 09:26 )

A mi cégünk is egy service management software-t készít és árul (TOPdesk), szóval azt használjuk. Meg fejlesztéshez JIRA + GreenHopper.

( freeoli v | 2014. 09. 12., p – 09:48 )

Használtuk, de voltak anomáliák a működésében, viszont tökéletesen testre szabható bármilyen munkamenetre. Akinek több kell egy os ticketnél annak ez megfelel.

( o_O v | 2014. 09. 12., p – 10:32 )

Jira
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

( Chas | 2014. 09. 12., p – 11:42 )

RT nálunk is.
A korábbit nem mókoltam tovább, felhúztam egy másik vasra egy frisset.
Nekem eddig megfelelt.

( necrolite | 2014. 09. 12., p – 12:14 )

Ugy tudom az egyik nemet telephelyen hasznaljak de van meg Jira-nk es a fantasztikus Remedyforce by Salesforce.

( horvalb | 2014. 09. 12., p – 15:32 )

1., CA Service Desk Manager
Helpdesknél incident/request/Problem management

2., Jira
fejlesztőknél inhouse alkalmazások bug és request követése

( jzola v | 2014. 09. 12., p – 22:09 )

OTRS jó.
De Zendesk el egyszerűbb az élet.

( szollosiimre | 2014. 09. 13., szo – 08:45 )

Otrs használókat kérdezném, 5/8 és 24/7 rendelkezésre állást, különböző SLA kat hogy kezel? Ezekről van lehetőség havi, éves reportra?

( arpi_esp v | 2014. 09. 14., v – 20:19 )

osTicket. egyik helyen 1.7, masikon 1.9 (eleg nagy a kulonbseg koztuk)

magyaritasa nincs, de az userek "imadjak" (az OTRS-re nem tudtuk ravenni oket, ezt hasznaljak szivesen)

A'rpi

( ubul_ | 2014. 09. 15., h – 10:18 )

OTRS-nek két problémája, hogy nem túl (fel)használó barát, adminként pedig nehézkes az archíválás. Az sajnos nem elég, hogy beállítom az archive flaget és ezzel kikerül a ticket az indexelésből. Nincs rá támogatott megoldás, hogy az 3 évvel ezelőtti ticketeket teljesen kiexportáljam és elmozgassam mondjuk szalagra.

De ez igaz más rendszerekre is. A data retention probléma az utolsó amivel foglalkoznak, de évek múltán elég égető kérdéssé válhat.

Máskülönben fantasztikusan felépített projekt. Ilyen fegyelmezetten felépített rendszert - főleg Perlben - még nem láttam.

( akoscomp | 2014. 09. 15., h – 10:51 )

glpi-t használunk már 6 éve.
Úgy otrs mint leltár, dokumentumkövető rendszernek tökéletes (IT szinten).