Система отслеживания проблем (также ITS , система тикетов по проблемам , тикет поддержки , управление запросами или система тикетов по инцидентам ) — это пакет программного обеспечения для управления и ведения списков проблем . [1] Системы отслеживания проблем обычно используются в совместных условиях, особенно в крупных или распределенных совместных проектах, но также могут использоваться отдельными лицами как часть режима управления временем или личной производительности . Эти системы часто охватывают распределение ресурсов , учет времени, управление приоритетами и надзорный рабочий процесс в дополнение к внедрению централизованного реестра проблем.
В институциональной среде системы отслеживания проблем обычно используются в колл-центре поддержки клиентов организации для создания, обновления и решения сообщенных проблем клиентов или даже проблем, сообщенных другими сотрудниками этой организации. Билет поддержки должен включать важную информацию о соответствующей учетной записи и возникшей проблеме. [2] Система отслеживания проблем часто также содержит базу знаний , содержащую информацию о каждом клиенте, решениях распространенных проблем и другие подобные данные.
Система отслеживания проблем похожа на « багтрекер », и часто компания-разработчик программного обеспечения продает и то, и другое, а некоторые багтрекеры могут использоваться как система отслеживания проблем и наоборот. Постоянное использование системы отслеживания проблем или ошибок считается одним из «отличительных признаков хорошей команды разработчиков программного обеспечения». [3] Элемент тикета в системе отслеживания проблем представляет собой текущий отчет о конкретной проблеме, ее статусе и других соответствующих данных. Они обычно создаются в среде службы поддержки или колл-центра и почти всегда имеют уникальный номер ссылки, также известный как номер журнала кейса , проблемы или вызова , который используется для того, чтобы позволить пользователю или персоналу службы поддержки быстро находить, добавлять или сообщать о статусе проблемы или запроса пользователя.
Эти тикеты так называются из-за их происхождения в виде небольших карточек в традиционной настенной системе планирования работ, когда этот вид поддержки только начинался. Операторы или сотрудники, получающие звонок или запрос от пользователя, заполняли небольшую карточку с данными пользователя и кратким описанием запроса и помещали ее в позицию (обычно последнюю) в колонке ожидающих слотов для соответствующего инженера, таким образом определяя сотрудника, который будет заниматься запросом, и приоритет запроса.
Общая концептуальная основа между системами отслеживания проблем и багтрекерами заключается в том, что допустимая проблема должна поддаваться решительному решению (например, «завершено», «исправлено» или групповому консенсусу о том, что проблема не стоит решения, например, «не проблема» или «не будет исправлено»); каждая проблема уникальна (дублирующиеся отчеты о проблемах в большинстве случаев быстро объединяются в одну активную проблему или тикет); и — за пределами стадии проверки — что есть ровно один человек, назначенный формальной ответственностью за продвижение проблемы (эта формальная палочка часто будет подпрыгивать много раз по мере развития проблемы). В багтрекерах проблемы, как правило, связаны с качеством или функциями по отношению к кодовой базе (которая по своей сути является настройкой управления проектами ), тогда как в обобщенных системах отслеживания проблем тикеты часто связаны с обслуживанием или отношениями, с более тесной связью с проблемами управления взаимоотношениями с клиентами (CRM). [4]
Проблемы могут иметь несколько аспектов. Каждой проблеме в системе может быть присвоено значение срочности, исходя из общей важности этой проблемы. Проблемы с низкой или нулевой срочностью являются незначительными и должны решаться по мере наличия времени. Другие сведения о проблемах включают клиента, столкнувшегося с проблемой (внешнего или внутреннего), дату отправки, [5] подробные описания возникшей проблемы, предпринятые решения или обходные пути и другую соответствующую информацию. Каждая проблема сохраняет историю каждого изменения.
Системы отслеживания проблем выполняют различные функции, в частности:
Ниже представлен пример сценария, демонстрирующий, как будет работать обычная система отслеживания проблем:
Если проблема не будет полностью решена, тикет будет открыт повторно, как только технический специалист получит новую информацию от клиента. Процесс автоматизации выполнения заданий , который внедряет лучшие практики для этих рабочих процессов и повышает эффективность ИТ-персонала, становится очень распространенным.
Некоторые государственные службы используют систему отслеживания проблем для отслеживания проблем и демонстрации их общественности. Системы отслеживания проблем могут показывать все задачи, которые еще предстоит выполнить правительству (в очереди ожидания), завершенные задачи, задачи в процессе выполнения, последовательность заказов и т. д. [ требуется цитата ] Завершенные задачи также можно предвидеть с помощью отчета, показывая, что именно было сделано по проблеме. [ требуется цитата ]
Системы отслеживания вопросов используются, например, для отслеживания того, какие законопроекты выносятся на голосование, и каковы их результаты. [6]
Проблемы транспорта и инфраструктуры (например, препятствия на дорогах, жалобы и т. д.) также могут быть зарегистрированы с использованием систем отслеживания проблем. [7] Затем проблемы могут быть решены соответствующими государственными службами.