Кто-нибудь, кто когда-либо настраивал службу поддержки / систему продажи билетов, проходил через один и тот же повторяющийся процесс создания «правильных» категорий заявок?
Редакция 1:
Все кажется хорошим, пока вы не поймете, что у вас есть указанные выше функции на каждом сайте компании, поэтому вы пытаетесь встроить индикатор сайта в иерархию, и все снова кажется хорошим. Затем вам приходит в голову, что крупный босс захочет узнать все заявки на инфраструктуру в совокупности, но поскольку у вас есть 16 различных сегментов инфраструктуры - по одному на сайт, - вы не можете легко ответить на вопрос. И так далее, и так далее, и так далее.
Основная проблема в том, что мы пытаемся использовать статическую иерархию для моделирования чего-то, что по своей сути является многомерным. И проблема не только в том, чтобы разрезать и разрезать данные. Чем более «полная» иерархия, тем труднее аналитику службы поддержки правильно классифицировать каждый тикет («Это сервер, но он находится в офисе в Нью-Йорке, поэтому он относится к серверу или Нью-Йорку?»). Та же проблема. существовали для реляционных баз данных, поэтому со временем были созданы кубы. И он существовал для сообщений в блогах, поэтому в конечном итоге вы могли пометить сообщение несколькими категориями. Маркировка - это ответ, но большинство продуктов для отслеживания билетов не поддерживают это понятие, поэтому мы возвращаемся к статическим иерархиям.
Учитывая это, мне интересно посмотреть, как люди выстроили свои иерархии категорий, чтобы они были как можно более широкими, сохраняя при этом актуальность, не усложняя жизнь аналитикам.
Спасибо
Мой бесполезный ответ - стараться удерживать теги или сильно полагаться на поиск.
По моему опыту, чем больше времени вы вкладываете в иерархию и чем длиннее становится набор вариантов, тем реже люди на самом деле тратят время на выбор правильной категории. Легче оставить значение по умолчанию или выбрать наиболее расплывчатую категорию, чем потратить несколько дополнительных секунд работы, чтобы выбрать наиболее конкретную.
Вы совершенно правы, когда говорите, что проблема в том, что вы пытаетесь использовать только одно поле категории для кодирования чего-то, что по своей сути является многомерным. Вам потребуются дополнительные поля для других измерений.
Мы используем IssueTrak, и в нем доступна стандартная иерархия категорий. Но в нем также есть отдельное поле для местоположения, поэтому вы можете делать отчеты и подсчеты по местоположению, по категории или по обоим направлениям. Есть и другие поля, которые можно включить или отключить для вашего конкретного сайта. Например, вы можете объединить местоположения в регионы, если хотите, и называть их иначе, чем местоположения и регионы, если хотите. Вы можете включить отделы, если хотите их использовать. Есть организации. Существуют элементы активов, поэтому вы можете связать заявку, например, с Server01, а Server01 может иметь собственный набор характеристик, по которым вы можете создавать отчеты.
Опять же, я считаю ошибкой пытаться закодировать различные измерения в иерархию. Мне кажется, вам нужны отдельные поля для различных типов вещей, о которых вы, возможно, захотите сообщить.
Сделайте их максимально простыми и убедитесь, что категории отражают то, о чем вы будете сообщать. Если вы хотите сообщать о сбоях только по серверу или рабочей станции, то нет смысла добавлять большие иерархические деревья, которые мешают перемещаться по каждой записи журнала.
Если вы не слишком озабочены отчетностью, вообще не создавайте заранее определенных категорий. Почти наверняка вы столкнетесь с тем, что не соответствует вашей схеме и из-за этого придется неправильно классифицировать.
Вы ищете таксономию класса, категории, типа и элемента. Вы застряли, потому что не хватает какой-то базы данных конфигурации (которая поможет со списком ITEM). Другая проблема заключается в том, что вы должны использовать свое программное обеспечение службы поддержки, чтобы определить, какие службы затронуты той или иной проблемой, а не какие серверы имели наибольшее время простоя. Если вы выберете модель на основе услуг, определение классов, категорий, типа и элемента станет намного проще. Я рекомендую думать об этом как о группе (класс), приложении (категории), услуге (типе), о том, что на самом деле сломано (элемент). Кроме того, вы можете использовать отношения времени и тикетов, чтобы показать влияние проблемы на вашу среду. Вот пример:
Пользователь звонит, потому что его команда не может получить доступ к его электронной почте (CCTI может быть Windows, Exchange, электронной почтой, клиентом), специалист по обмену проверяет обмен и сообщает, что обмен работает нормально для всех остальных, и отслеживает его сетевую проблему. Его заявка должна быть закрыта, а новая заявка открыта им, чтобы сетевая группа посмотрела на инфраструктуру. обменный билет должен быть связан с новым (CCTI, Network, Internal, Connectivity, Desktop), поскольку оказывается, что коммутатор вышел из строя, поэтому билет закрывается с этим разрешением. Теперь, когда вы запускаете отчет о доступности по электронной почте, вы должны увидеть сбой и то, что это было связано с проблемой сети.
У меня аналогичная дилемма для вас. В настоящее время у нас есть 3 бизнес-подразделения, которым необходимо использовать этот трекер, и мы используем матрицы выбора, чтобы определить, кого следует уведомлять о какой категории, а также кто может публиковать сообщения в какой категории.
Поскольку у нас есть сотрудники, которые перемещаются между предприятиями, мы фактически используем категорию уровня 1 для названия компании, а категорию уровня 2 - для области поддержки. например:
Эта схема все еще довольно новая, поэтому мы не сталкивались с ней (пока)
Мне запомнились две вещи; перечитываю ваш вопрос.
У нас есть несколько вспомогательных офисов, но они очень маленькие и в основном могут обслуживаться одним ИТ-специалистом. Настоящее решение - не тегирование, а подписка. Возможность выполнять несколько заданий - ключевая особенность, если вы действительно не можете справиться с вещами как есть.
Другой пример: Launchpad предлагает «также влияет» и объединяет комментарии в один поток. Что-то вроде этого может подписаться как на специалистов Нью-Йорка, так и на специалистов по серверам и задокументировать взаимодействие, которое происходит (или не происходит).