Система отслеживания проблем


Система отслеживания проблем (также ITS , система заявок на устранение неполадок , служба поддержки , управление запросами или система заявок на инциденты ) — это компьютерный программный пакет, который управляет списками проблем и поддерживает их . [1] Системы отслеживания проблем обычно используются в условиях совместной работы , особенно в больших или распределенных группах, но также могут использоваться отдельными лицами как часть режима управления временем или личной продуктивности . Эти системы часто включают в себя распределение ресурсов, учет времени, управление приоритетами и рабочий процесс надзора в дополнение к внедрению централизованного реестра проблем.

В институциональных условиях системы отслеживания проблем обычно используются в колл-центре поддержки клиентов организации для создания, обновления и решения проблем, о которых сообщают клиенты, или даже проблем, о которых сообщают другие сотрудники этой организации. Билет поддержки должен содержать важную информацию о соответствующей учетной записи и возникшей проблеме. [2] Система отслеживания проблем часто также содержит базу знаний , содержащую информацию о каждом клиенте, решениях распространенных проблем и другие подобные данные.

Система отслеживания проблем похожа на «систему отслеживания ошибок » , и часто компания-разработчик программного обеспечения продает и то, и другое, а некоторые системы отслеживания ошибок можно использовать в качестве системы отслеживания проблем, и наоборот. Постоянное использование системы отслеживания проблем или ошибок считается одним из «признаков хорошей команды разработчиков программного обеспечения». [3] Элемент заявки в системе отслеживания проблем представляет собой текущий отчет о конкретной проблеме, ее статусе и других соответствующих данных. Они обычно создаются в среде службы поддержки или колл-центра и почти всегда имеют уникальный ссылочный номер, также известный как обращение , проблема или журнал вызовов .номер, который используется, чтобы позволить пользователю или вспомогательному персоналу быстро находить, добавлять или сообщать о статусе проблемы или запроса пользователя.

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

Общая концептуальная основа между системами отслеживания проблем и багтрекерами заключается в том, что действительная проблема должна поддаваться решительному разрешению (например, «завершено», «исправлено» или групповому консенсусу относительно того, что проблема не стоит решать, например «не является проблема" или "не исправит"); что каждая проблема уникальна (дублирующиеся отчеты о проблемах в большинстве случаев быстро объединяются в одну активную проблему или заявку); и — после стадии отбора — что есть только одно лицо, которому назначена официальная ответственность за продвижение вопроса (эта формальная эстафетная палочка часто будет много раз подпрыгивать по мере развития вопроса). В баг-трекерах проблемы, как правило, связаны с качеством или функциями, связанными с кодовой базой (которая по своей сути является управлением проектами) .настройки), тогда как в обобщенных системах отслеживания проблем заявки часто связаны с услугами или отношениями, с более тесной связью с проблемами управления взаимоотношениями с клиентами (CRM). [4]

Проблемы могут иметь несколько аспектов. Каждой проблеме в системе может быть присвоено значение срочности, основанное на общей важности этой проблемы. Проблемы с низкой или нулевой срочностью являются незначительными и должны решаться, когда позволяет время. Другие сведения о проблемах включают сведения о клиенте, столкнувшемся с проблемой (внешней или внутренней), дату отправки, [5] подробное описание возникшей проблемы, попытки решения или обходные пути и другую соответствующую информацию. Каждый выпуск поддерживает историю каждого изменения.