Service Desk *

Управление — это процесс планирования, организации, мотивации и контроля,
необходимый для того, чтобы сформулировать и достичь цели организации.
Википедия

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

ITIL[1] — библиотека книг в которых подробно и всесторонне описываются различные «хорошие» практики управления ИТ-услугами (IT Service Management). У книг ITIL разные авторы, описанные в них процессы и рекомендации никто между собой не согласовывал, так что любимый тезис специалистов по ITIL — ITIL нельзя внедрить, только адаптировать. Логическим выводом из этого будет то, что ITSM-решение нельзя получить из коробки.

Прежде, чем запустить Service Desk и завести первые тикеты, вам придется сначала получить сертификат по ITIL, пройти обучение по выбранному ITSM-продукту, пригласить консультантов, потратить несколько месяцев и несколько миллионов рублей на проект. Есть, конечно, бесплатные решения, которые можно настроить самому, но голову в процессе настройки придется поломать изрядно. Не лучший подход, особенно для небольшой ИТ-службы с ограниченным бюджетом и ресурсами.

Исходный тезис про необходимость адаптации сам по себе правильный. Конечно, потребуется несколько лет, чтобы обнаружить и автоматизировать несколько десятков процессов, описанных в ITIL. Однако если компания вообще не сталкивалась с ITIL и ITSM, то ни большей части этих процессов, ни какой-либо потребности в них у нее просто еще нет.

В реальности с чего все начинают внедрение Service Desk? С управления инцидентами или если проще с заведения тикетов. Откровенно говоря, не самый сложный процесс — пришла заявка открыли тикет. Выполнили заявку — закрыли тикет. На этом этапе автоматизации вникать в теоретические сложности и особенности системы не требуется.

На этой неделе вышел очередной релиз SmartNut-а — Service Desk системы для ИТ-компаний и ИТ-отделов.

Самое приятное из новостей: теперь появилась возможность автоматической обработки писем, приходящих на email техподдержки, и регистрация на основании этих писем заявок от пользователей/клиентов.

Так же появилось общее для аккаунта компании файловое хранилище, куда можно «складывать» техническую документацию, регламенты и все остальное, что требуется.

Под хабракатом — подробнее и в деталях.

При работе с OV SD 4.5 есть одно неудобство. Уведомления, которые приходят по почте, содержат слишком мало информации.
В нашей организации в письме содержится только краткое описание.
Получив такое сообщения, приходиться переключаться в окно толстого клиента и открывать заявку.
На открытие заявки может уходить до десяти секунд. При этом можно столкнуться с ситуацией, когда несколько сотрудников пытаются просмотреть заявку одновременно.
Поэтому была написана программа OV SD 4.5 Notifier, которая отображает уведомление с наиболее полной информацией о заявке.
О ней дальше и пойдет речь.

Привет Хабр!

Наконец-то мы можем заявить об официальном релизе системы SmartNut — удобной системе класса Service Desk, ориентированной на небольшие ИТ-компании, основной бизнес которых связан с предоставлением ИТ-услуг клиентам (абонентское обслуживание ПК, 1С-ники и т.д.). Впрочем, система подойдет и для небольших ИТ-служб.

В этом посте подробнее о возможностях системы, планах развития и ценах (спойлер: в довольно широком диапазоне использование бесплатно).

Я хочу поделиться с вами моим опытом по настройке системы регистрации и обработки заявок Atlassian JIRA, совместно с Atlassian Confluence в качестве системы тех. поддержки пользователей. Что пишут Atlassian по поводу этого можно почитать тут: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System

Есть несколько концепций организации тех. поддержки. Первая из них – это настройка отдельного проекта для каждого клиента. Но эта концепция не рациональна в связи с тем, что сотрудники тех. поддержки не видят общей картины и при большом количестве клиентов возникает переизбыток проектов. Поэтому я расскажу вам о другой концепции – с одним проектом Service Desk для всех клиентов с настроенными областями видимости.

Приветствую тебя, %habrauser%!

Предыстория:

В данный момент я работаю в небольшой конторе, которая занимается консультированием, аудитом и обслуживание в области IT. Хотя контора и небольшая, количество клиентов у нас росло быстрыми темпами, и без нормального хелпдеска обойтись было уже очень сложно. Рассмотрев приличный перечень продуктов, как платные так и бесплатные, наш выбор пал на продукт фирмы BestPractical, который называется весьма незамысловато Request Tracker.