собираю информацию по использованию систем bugtracking'а и тикет-систем при работе с клиентами-заказчиками.
у кого есть примеры работы? на сколько легко клиенты соглашаются работать/адаптируются?
какие системы кто использует из платных/бесплатных?
я сейчас рассматриваю mantisbt в качестве основной. увидел в ней все что надо, достаточно простая в развертывании. из минусов - не совсем удобный интерфейс, на любителя.

(0) Посоветуйте систему учета заявок от пользователей (надо в браузере)

(1) спасибо, часть вопросов снято.
мне интересно как к этому относятся клиенты. на сколько наличие этой системы тормозит взаимодействие?
вообще, мне от системы учета заявок нужен их централизованный учет с возможностью доступа к ним клиентов.

(2) оформление заявки не запрещает звонок
заявка нужна для учета, звонок - если приперло

(5) только 5% клиентов будут сами заводить заявки, так что к этой системе тебе еще нужна и девочка секретарь ))

(3) однозначно да. допустим, по своей работе я имею консультационное направление, тут однозначно - все средства связи хороши. но вот когда речь идет о разработке, есть тенденция возврата к старым задачам. я для себя конечно веду учет выполненных работ во внутреннем формате - но это не видно клиентам. и мне приходится выполнять предварительную работу для пересылки результатов за период.

(4) скажем так, у всех с кем я работаю есть возможность это делать. к тому же процесс достаточно простой. но согласен, вскрытие покажет:)

(6) у всех есть возможность, но не у всех есть желание ))
большинству проще позвонить, а в заявке потом написать " ... а остальное как мы обсуждали по телефону"

> мне интересно как к этому относятся клиенты. на сколько наличие этой системы тормозит взаимодействие?

Самый важный параметр - скорость и стабильность реакции. Если На тикет ответ поступает не дольше чем через час, значит все принимают эту систему и всем удобно.
Если же пользователь не уверен, что на тикет будет ответ в ближайшее время, то эта система не работает, ее будут саботировать.

(7) Если ресурсами айти у вас рулит "большинство" а не внятный руководитель, то мне остается только пожалеть ваше айти.

(7) да, такое есть но мало, скорее это относится к консультациям. тут действительно друдозатрат по оформлению заявки больше чем отдача

(10) в ларьке да, удобнее пнуть админа за соседним столом, он ничо не делает. Управляемость от пользователя, плюс бардак.
А там где айти ресурса не хватает, или он задействован в серьезных проектах, там нужно наводить порядок, и дисциплина требует некоторых накладных расходов, как то время на составление заявки.

(8) по реакции. сейчас мне пишут на электронную почту. если скорость реакции важна - мне звонят. т.е. есть правила игры и они отработаны. я хочу понимать на сколько "дико" идея нововведения смотрится со стороны - будет понятны перспективы работы с ним.

(0)
на инфостарте есть статья

(12) пользователю будет неудобно - вопрос тогда ради чего городить огород? Если для тебя управление запросами, приоритезация критически важна, то делай и готовься к сопротивлению.

я очень люблю поддержку FastVPS или AGAVA - из десятков заявок *все* были обработаны не позже часа, и везде был результат. Я знаю что если оставлю тикет здесь, то могу про него забыть - он будет отработан с результатом, и меня побеспокоят только отчитаться.

и я ненавижу поддержку яндекс - это бездонная яма, отбойник для пользователей. Добиться ответа практически невозможно, да и результат будет нулевой

(11) я так понимаю, в вашей конторе при виде айтишников надо падать на колени и три раза говорить ку?

(16) в нашей конторе любят порядок и дисциплину, тогда все работает как часы, и всякие черви с своими косяками не мешают бизнеспроцессу. Черви это пользователи, админы, секре***ки и прочие любители работать не как положено, а как удобно.

(17) по тому как часто ты зависаешь на форуме, понятно как вы там любите порядок и дисциплину ))

(14) огород городить вынуждает особенность работы по поддержке, а именно в части документирования обращений. возможно, для части клиентов придется либо как-то переделывать работу с заявками, либо вносить их самому. сейчас собираю полезные сведения :)

а так то, в любой крупной конторе с нормальным руководителем IT отдела, всегда есть на критическую группу пользователей, консультант + дежурный программист, которые могут помочь пользователю решить вопрос или сформулировать заявку.

(18) Есть ряд лиц, которым разрешен доступ к форумам. Они умеют управлять своим временем сами, поэтому им можно.

(19) Очень помогает при разборе полетов. Прямо таки лучшее средство от хитропопости некоторых нечистоплотных товарищей )

Надо пользователю объяснить, что заявки в ИТ нужны не ИТ, а ему самому, ибо:

1. Его заявка никогда не потеряется
2. Он всегда сможет посмотреть что с его заявкой происходит
3. Всегда можно выяснить по чьей инициативе сделана та или иная доработка

(22) такое к счастью бывает редко. чаще - забывают что заказывали или давно сделано и возвращаются с тем же опять.
(23) 3 х ДА!

(0) юзаем собственную поделку на 1С...

1. Пользователь отправляет письмо на support;
2. В системе автоматически создается тикет, клиенту отправляется сообщение о том, что тикет создан и о том, что всю дальнейшую переписку необходимо вести, указывая в теме письма номер тикета;
3. Программист также получает уведомление о том, что в систему был добавлен новый тикет;
4. При переписке с клиентом, программист также отправляет письма на support с указанием номера тикета; (таким образом сохраняется переписке по инциденту)

(25) а почтовое сообщение парсится самой 1с? через сайт отправляется, т.е. не в свободной форме?

(26) В свободной форме.

Если в теме письма не указан номер тикета (парсит 1С), то создается новый тикет. На основании заранее заполненных данных о почтовых получателях в системе, программа заполняет реквизиты Организация отправитель, Проект, etc...

Тело этого письма (парсит 1С) - есть содержание этого инцидента.

Если в теме письма указан номер тикета, то текущее содержимое этого сообщение добавляется в уже существующий тикет.

(25) имеем кучу писем с указанием номера тикета (даем пользователю право ошибки в единственном формализованном атрибуте?)

не проще ли все это хранить в едином треде

(22) Эт точно. В свое время два месяца воевал с сотрудниками (причем при полной поддержке руководства), когда вводил сервисдеск. Зато потом наступило щастье.

Пользователь десять раз подумает, прежде чем писать "тупую" заявку, непосредственно демонстрирующую его профпригодность; подчиненные из хелпдеска уже не пытаются лепить отмазки вроде "я другим был занят"; руководство не выпендривается при распределении бюджета "да вы там ничем не занимаетесь, только мышки меняете", ну и т.д. А когда еще до ума довел внутренний инвентарный учет (в том же сервисдеске), исчезла проблема "сломался монитор, а у нас ВНЕЗАПНО нет замены".

Короче, порядок, если его не доводить до бюрократического фанатизма - реальное подспорье в работе.

(28) не понял. поясни, плиз...

(28) Вообще достаточно не менять тему письма в переписке. Там как раз и находится номер тикета.

+(32) На основании этого сервисдеск и формирует "общий тред".

Кстати, "1С:ITIL" тоже так умеет, однако о практической пригодности этого продукта лучше умолчу :)

(32) (33) все верно...

тема письма могут быть такими:

1. Привет мир #ТН-9988
2. По задаче #ТН-9988
3. Fw: По задаче #ТН-9988
4. Re: По задаче #ТН-9988
5. #ТН-9988 отчет о завершении
6. etc.

и все это относится к тикету #ТН-9988

(35) можно еще забыть цифру из двух одинаковых, или 0 за О, и т.п. Если уникальный идентификатор можно править руками, значит обязательно будут ошибки

(36) это все мелочи жизни
вот вывел интересную идею из переписки - надо клиентам давать возможность оставлять заявку несколькими разными способами с дальнейшей выгрузкой в хелпдеск. а уже из хелпдеска присылать уведомления со ссылками на тикет.

(36) стараемся учить клиентов юзать

Replay и Forward

(36) Научить пользователя использовать в почтовом клиенте кнопки "Ответить" и "Переслать" никак?

(38) Опередил :)

(37) например через сайт, по эл почте, через приложение..

(41) Нормальные системы сервисдеска имеют веб-морду, умеют принимать емыло. А о каком приложении идет речь?

(6) Гы-гы-гы.... У Вас 50% заявок будут "Все пропало", а оставшиеся 50% "Позвоните мне - я все расскажу".

(38) если есть время заниматься еще и социальной инженерией, то почему нет )

(43) да вы чо? :) у каждого своя сложившаяся специфика работы. я указал решаемые задачи.

(45) Специфика работы есть. Только на качество оформления заявок она никакого влияния не оказывает :)

Либо Вы сажаете на прием заявок оператора, пытающего с пристрастием юзверя, либо исполнитель сам потом будет пытать юзверя по телефону/почте, пытаясь понять, что он имел в виду. И как правило з/п оператора гораздо ниже.

Проверено жизнью неоднократно.

(43) (45) +100500.
Напомнило. Недавно была заявка.
Тема письма "Создать отчет". И все, ни файлов прикрепленных, ни описания, ничего.

(46) меня устраивает то что сейчас приходит на электронную почту. да, часто приходится выяснять, что конкретно хочет клиент, уточнять. но для меня это обычная работа. тут важно, чтобы клиент мог смотреть сделанные когда-то давно задачи, т.е. не все ведут свой журнал выполненных работ.

К нам в тикет как-то свалилась заявка "на точке воняет дохлой крысой"... :-)

(49) крысу приложили к заявке? :)

(50) Она не поместилась в электрописьме... :-)
Но тех поддержка сильно обиделась...

(48) с кем же ты работаешь? мои никогда не смотрят журналы им проще письмо по новой кинуть или позвонить ))

(52) как-то получается, что в основном общение происходит напрямую с руководством компаний. тут инициатор сам заинтересован в правильной постановке, т.к. меньше вопросов - меньше отрывают от главной работы. поэтому я практически избавлен от разного "мусора" и непоняток. но прецеденты бывают конечно.

(53) Никто не против внедрения Вами сервис-деска. Очень удобный инструмент. Но требующий некоторой организации, дисциплины и самое важно - не дойти до фанатизма при его использовании. Как в одной из контор, где я работал.

Как-то нам установили KPI "количество заявок, выполненных в срок". Вроде замечательная вещь. Но только нюанс - срок система ставит фиксированный из SLI, а примерно треть задач не связаны с поддержкой как таковой. Это минипроект. Местами со сроком исполнения в пару месяцев. Типа "Автоматизировать ведение налогового учета в ООО "Рога и копыта". Плюс иногда в день нужно выполнить 10 заявок с трудозатртами часов в 16 (и еще местами на проектную деятельность привлекают), но железка никак загруженность не учитывает.

Закончилось все чисто по-русски. Каждое обращение, которое раньше даже не регистрировалось (типа как настроить поля страницы при печати) стало полноценной заявкой с временем выполнения 5 мин. при норме в 2 дня (низкий приоритет). В итоге 100500 заявок за месяц было выполнено в срок. Ну и парочка просроченных, которые реально занимали массу времени. Картина получалась в итоге просто чудная. Но кому это все нужно - не понятно :(

При этом ессно на саппорте никто не хотел сидеть, ибо гемор. Проектной работой гораздо интереснее (и доходнее) заниматься было. Хорошо у меня выбор был, ибо дедовщину никто не отменял. И коллеги мучили эти заявки.

(54) спасибо за пример! задача учета выработки - достаточно сложная штука. я пока этот вопрос не рассматриваю, для этого есть внутренняя система :)