Я хочу внедрить ITSM в ИТ-отдел, состоящий из двух человек. У нас есть веб-система рабочего процесса, в которой определены пять типов запросов, которые попадают в наш отдел. Обоснование разделения типов запросов в основном связано с категоризацией, но пользователи часто не понимают, какой тип запроса выбрать.
Я планирую упростить систему, сделав видимым для пользователей только один тип запроса, а затем при необходимости мы изменим этот тип. Но вместо разделения по техническим областям (текущие типы запросов - это компьютерная поддержка, веб-поддержка, поддержка ERP, поддержка CRM и поддержка аналитиков), я думаю, было бы лучше разделить на инцидент, проблему, запрос на изменение и запрос на обслуживание. Старый способ категоризации будет заменен привязкой каждого запроса к проекту, который представляет связанную услугу, и это будет сделано нами, а не пользователями.
Теперь наша система рабочего процесса отображает все назначенные вам запросы в одном гигантском списке. Можно настроить отображаемые поля так, чтобы вы могли видеть, какие инциденты соответствуют запросам на изменение. Я подумывал написать свой собственный интерфейс, чтобы перечислить каждый тип запроса в отдельной группе на экране. Это заставило меня задуматься о приоритезации запросов. Каждому запросу назначается приоритет от 1 до 5, поэтому запрос на изменение приоритета 1 более важен, чем запрос на изменение приоритета 3. Но разве инцидент с приоритетом 2 более важен, чем запрос на изменение приоритета 1, потому что это инцидент? Поскольку нас в отделе всего двое, я не думаю, что мы можем работать над запросами на изменение, пока происходит инцидент. Я всегда придерживался мнения, что вы должны исправить то, что сломалось, прежде чем создавать что-то новое. Или я собираюсь пообедать по этому поводу? Должны ли мы игнорировать тип запроса и работать только на уровне приоритета?
Если я иду правильным путем, отдавая приоритет всем Инцидентам, а не всему остальному, как мне определить приоритеты для других типов запросов? Сначала я склоняюсь к тому, чтобы делать запросы на обслуживание, потому что я ожидаю, что они будут довольно быстрыми, за ними последуют запросы на изменение и, наконец, проблемы. Однако меня немного беспокоит то, что если Проблемы будут решены в последнюю очередь, они никогда не будут исследованы. Может быть, заказ должен быть «Инцидент», «Запросы на обслуживание», «Проблемы», «Запросы на изменение»?
Я собирался просто оставить это в комментариях, но на самом деле я собираюсь опубликовать ответ, потому что, хотя я думаю, что у вас хорошие намерения, я думаю, что вы делаете это более сложным образом, чем вам нужно.
Хорошо, что вы планируете какую-то систему продажи билетов, и я считаю, что для любых компьютеров, превышающих 20, это хорошая идея, чтобы отслеживать вещи. Что вам нужно иметь в виду, так это то, что системы службы поддержки бывают разных форм и размеров, от прославленного списка заявок до очень сложных систем со многими категориями, приоритетами, исполнителями, эскалациями, SLA и десятками других наворотов. Чем крупнее и изолированнее ваш ИТ-отдел, тем больше преимуществ имеют эти более сложные системы, но для небольших отделов они могут быть больше помехой, чем что-либо еще.
Для сравнения, я также работаю в ИТ-отделе из двух человек, и поэтому делаю все понемногу, поэтому слишком много разных вариантов в службе поддержки просто мешали бы мне. У нас есть относительно простая самодельная служба поддержки, у которой сторона обращена к пользователю, а сторона - к специалисту.
Сторона, обращенная к пользователю, имеет минимальное количество полей, чтобы не отпугнуть их информационной перегрузкой (заголовок, категория, приоритет, тег затронутого актива, описание проблемы). Здесь регистрируются все ИТ-проблемы, у нас нет разных систем для запросов на изменение, запросов на обслуживание и т. Д. Наши категории также намеренно широки, чтобы не путать вопросы (компьютерное оборудование, проблемы с принтером, Outlook, Интернет, общие /Другой).
На стороне технического специалиста есть еще несколько полей, но они все еще не очень сложные (исполнитель, статус, контрольная дата). Это дает нам достаточную гибкость для классификации заявок (в основном для целей отчетности), но не мешает на самом деле решить проблему. Мы можем оставлять комментарии к заявке, показывая, что мы сделали, и если одному из нас нужно поработать над заявками других, мы знаем, что уже было сделано.
Основная цель нашей службы поддержки - отслеживать проблемы, с которыми сталкиваются наши активы (и кто создает заявки), чтобы мы могли видеть, какие активы вызывают больше всего проблем или какие люди могут потенциально нуждаться в обучении. У нас нет ничего сложного, такого как категоризация инцидентов, проблем, запросов на обслуживание, запросов на изменение и т. Д. - это было бы ненужным для нас, все приходит как тикет, и мы решаем это соответствующим образом.
Если вы хотите сравнить приоритеты, наши, как правило, следующие. У пользователя есть возможность установить приоритет при создании заявки, но у нас также есть возможность привести его в соответствие с реальностью (мы все знаем одного пользователя, который создает билеты с приоритетом 1 абсолютно для всего: P).
Короче говоря, да, вам, вероятно, следует реализовать какую-то систему службы поддержки, но, возможно, не что-то такое сложное, как вы описываете в своем вопросе. В конечном счете, вам нужно взаимодействовать с этой системой каждый день, поэтому она должна быть максимально упрощенной и простой в использовании, насколько это удобно для вас. Сделайте так, чтобы процесс работал на вас, не пытайтесь работать с каким-то процессом, разработанным для десятков ИТ-отделов. Если вас не устраивает какая-либо часть процесса, измените ее немного и посмотрите, как это пойдет, и продолжайте совершенствовать ее, пока не будете довольны тем, что она работает эффективно для вас.