Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

Проблемы [ править ]

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

Функции [ править ]

Системы отслеживания проблем выполняют разные функции, в частности:

  • Внесение неисправностей, ошибок и запросов (например, вручную или по электронной почте Системы управления ответами)
  • Распространение и передача вопросов ответственным лицам
  • Мониторинг обработки, затраченного времени и качества работы
  • Обеспечение наблюдения за внутренними процессами путем принудительного контроля с помощью рабочих процессов
  • Статистический анализ количества билетов
  • Автоматическая генерация билетов системами тревожной сигнализации, например, мониторинг сети
  • Выполнение внешних соглашений об обслуживании (Соглашение об уровне обслуживания, SLA )
  • Систематический сбор вопросов и ответов на часто задаваемые вопросы
  • Присвоение приоритета каждой проблеме на основе общей важности этой проблемы, клиента, даты подачи, SLA
  • Содержит подробное описание возникшей проблемы, попытки решения или обходные пути, а также другую важную информацию.
  • Ведение истории каждого изменения

Рабочий процесс [ править ]

Представлен пример сценария, демонстрирующий, как будет работать обычная система отслеживания проблем:

  1. Технический специалист по обслуживанию клиентов получает телефонный звонок, электронную почту или другое сообщение от клиента о проблеме. Некоторые приложения предоставляют встроенную систему обмена сообщениями и автоматические сообщения об ошибках из блоков обработки исключений .
  2. Техник проверяет, является ли проблема реальной, а не просто предполагаемой. Техник также обеспечит получение от клиента достаточной информации о проблеме. Эта информация обычно включает в себя среду клиента, когда и как возникает проблема, а также все другие соответствующие обстоятельства.
  3. Технический специалист создает проблему в системе, вводя все соответствующие данные, предоставленные клиентом.
  4. По мере завершения работы над этой проблемой технический специалист обновляет систему новыми данными. Любая попытка решить проблему должна быть отмечена в системе проблем. Статус заявки, скорее всего, будет изменен с открытого на ожидающий.
  5. После того, как проблема была полностью решена, она помечается как решенная в системе отслеживания проблем.

Если проблема не будет полностью решена, заявка будет повторно открыта, как только технический специалист получит новую информацию от клиента. Run Book автоматизации процесса , который реализует лучшие практики для этих рабочих процессов и повышения ИТ - персонал эффективность становится весьма распространенным явлением.

Использование в разных секторах [ править ]

Правительство [ править ]

Смотрите также: Открытое правительство

Некоторые государственные службы используют систему отслеживания проблем, чтобы отслеживать проблемы и отображать их для общественности. Системы отслеживания проблем могут отображать все задачи, которые еще предстоит выполнить правительству (в очереди ожидания), завершенные задачи, выполняемые задачи, последовательность заказов и т. Д. [ Необходима цитата ] Завершенные задачи также можно предвидеть в отчете, показывая, что именно было сделано по проблеме. [ необходима цитата ]

Системы слежения Issue являются, например , используется для отслеживания законодательных векселей являются для голосования и итогов их. [4]

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

См. Также [ править ]

  • Программное обеспечение службы поддержки
  • Сравнение программного обеспечения для отслеживания проблем службы поддержки
  • Сравнение систем отслеживания проблем
  • Отслеживание климатических действий
  • Правительство по алгоритму
  • Протокол ошибки
  • Список национальных приоритетов
  • Ящик для предложений
  • Разработка программного обеспечения с открытым исходным кодом
  • Приоритезация
  • Распределение ресурсов
  • Пользовательские инновации

Ссылки [ править ]

  1. ^ Бертрам, датчанин. Социальная природа отслеживания проблем в разработке программного обеспечения. Архивировано 8 ноября 2016 г. в Wayback Machine . Дисс. Университет Калгари, 2009 г.
  2. ↑ Джоэл Спольски (8 ноября 2000 г.). «Безболезненное отслеживание ошибок» . Проверено 29 октября 2010 года .
  3. ^ Метод и устройство для выполнения удаленных операций в среде отслеживания проблем , 2013-08-29 , получено 2019-04-05.
  4. ^ Например: «Помощь отслеживателя сената - Сенат Флориды» . flsenate.gov . Проверено 17 января 2021 . «Результаты законодательного поиска» . congress.gov . Проверено 17 января 2021 . "GovTrack.us: Отслеживание Конгресса США" . govtrack.us . Проверено 17 января 2021 .
  5. ^ Отслеживание хода сообщения о дорожной неисправности или проблеме

Внешние ссылки [ править ]

  • Программное обеспечение для отслеживания ошибок в Curlie  : название этой категории вводит в заблуждение, поскольку в ней перечислены системы отслеживания ошибок и проблем.
  • Программное обеспечение службы поддержки в Curlie  : служба поддержки и программное обеспечение для отслеживания проблем в DMOZ
  • Инструменты разработки отслеживания проблем Java в Curlie  : в этой категории перечислены системы отслеживания проблем, разработанные на Java .