Добрый день!

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

Прелагаю в качестве примера:

Тип: Обращение
Категория: ПО
Подкатегория: Заведение нового пользователя
Дополнительно: Наименование базы.

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

Цель одна - обеспечить работу всех сервисов на должном уровне, оптимизировать все процессы, внедрить SLA , KPI.

(2) Вот в этом путаница  и есть , не совсем понимаю как правильно сделать классификацию и не спутать это все с услугами.

Запрос на обслуживание
Запрос на изменение.

Что ещё надо?

А  если конкретно к твоей компании - собрать статистику, классифицировать.

Либо можно считать например:

Услуга - 1С
Сервис - Конфигурация УПП
Тип - Ошибка
Категория - ПО
Подкатегория - Имя базы данных
Комментарий - описание

(5) Это уже процессы. Это уже отдельная ветка.

(8) Это не процессы... Это причины инцидентов.

(0) 1. Набили фейсы
2. Опустили на бабки
3. Приковали наручниками к батарее

P.S. Если есть проблемы с классификатором - стоит задуматься о целесообразности классификации.

(10) Проблем нет с классификацией. Хочу понять как правильно это сделать. Нужно ли глубоко опускаться до мелочей или достаточно будет более крупными блоками это сделать. Хочется посмотреть пример хотя бы из 2 -3 строчек. Для себя понять тоже.

(11) 2 строчки я тебе уже привёл ))
Остальное зависит от твоей ИС. Можно составить список сервисов и к ним привязаться.
Типа
телефония - обслуживание
телефония - ошибка
телефония - развитие.
и т.п.

(11) Более углубленно имеет смысл проваливаться ?
Например не понятно будет при анализе инцидентов и проблем:  тип ошибки , развитие какого блока. Или я это глубоко пытаюсь пойти и смысла в этом нет ?

(13) если тебе это надо, то имеет. Если нет нужды в анализе - то не имеет.

(14) Спасибо. Как понимаю для себя лучше сделать следующим образом.

Услуги - 1С
Сервис - Конфигурация
Тип - ПО
Категория - обслуживание
Подкатегория - ввод нового пользователя

Услуги - 1С
Сервис - Конфигурация
Тип - ПО
Категория - развитие
Подкатегория - Разработка нового отчета

Правильно я понял ?

(15) Не развитие. Изменение.
Используй термины ITIL

(16) Да конечно, спасибо. Попробую составить.

(17) Не будет лень - опубликуй. Обоср^W Обсудим
))

Хорошо

немного рассуждений про коня в сферическом вакууме. могу быть не прав. в первую очередь должен быть составлен каталог услуг при том основанный на потребностях бизнесса, а не ит отдела. допустим часть каталога услуг: ПО - 1с - Доступ к УПП (ЗУП, УТ и т.д.). Теперь к инцидентам/запросам на обслуживание/изменение. Инцидент - это грубо говоря случай, когда ит-услуга по тем или иным причинам не может быть предоставлена. Ошибка в коде и печатная форма не формируется. Если пользователь не знает как например отчет формировать, то это запрос на обслуживание. повторюсь. могу путаться в показаниях. идем дальше, а точнее к kpi. тут уж вам самим определять глубину и она зависит от структуры отдела (каталог услуг так же зависит). Если в штате например один 1сник, то к чему тогда разделение на конфигурации? он сам себе жнец и на дуде игрец. а если же крупный отдел, где есть разделение ответственности по подсистемам (логистика, финансы и т.д.), то тогда уже имеет смысл и глубже копать. Захотели ввести kpi по количеству программных ошибок. Каждый прог отвечает за свою подсистему. Соответственно при возникновении ошибки в подсистеме логистике будет понятно, что это зона ответственности Иванова и его косяк/недоработка, если механизм нетиповой. буду рад комментариям и замечаниям.

(20) "к чему тогда разделение на конфигурации"
Чтобы было можно определить, куда уходит больше времени. И принять решение. Может - отправить пользователей на курсы, может - взять дополнительных сотрудников, может - сменить программу

Отдел большой. В шатате есть аналитик, архитектор бд и программисты.

(20) Думаю что сотрудник ,который сидит на первой линии тех.поддержки и занимается только распределение заявок на разные потоки не всегда сможет понять что это такое "Изменение" или "обслуживание". Думаю что в этом случае общими словами тут сложно будет обойтись.

(23) А первая линия и не должна классифицировать инциденты.
Максимум - ошибка или добавление. Ну и направление, куда его передать - админам, программистам, ТП.
Ошибка распознаётся по воплю в трубку, добавление - по содержательному письму на help@
А дальше уже ответственный на соответствующем направлении разбирается и классифицирует.

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

(25) Обращение - уже есть инцидент, поскольку сотрудник на него потратил время.
зачастую первая линия некомпетентен в классификации. Максимум - "у меня 1с не запускается". И вешают на 1сника. А выясняется, что там или ключ не виден (проблема админа) или вообще 1с не установлена (проблема ТП)

Хотя, может я путаю немного понятия диспетчера 1линии и специалистов 1линии.

(26) разве обращение классифицируется как инцидент сразу же? ок. пользователь звонит и просит - сделайте мне корпоративную почту. или подключите интернет. это разве инцидент?

(28) В данном случае - да. Инцидент типа "запрос на обслуживание".
Инцидент - это запись о том, что у пользователя случилось. А если случился новый пользователь, то это тоже случилось.

(29) в корне не согласен. на сколько помню - это уже устаревшая классификация.

(30) Зато действенная.

Как я понимаю. Есть диспетчер,который принимает входящие звоники и заявки в серис деске. Он способен по общим вопросам понять на какое подразделение это отправить, т.е на администраторов или программистов. Далее включается 1 линия тех.поддеркжи, которая и пытается классифицировать это обращение. Инцидент появляется на 1 линии, если она не справляется то передается на 2 линию. Классификация наверное должна быть на 1 линии, а не у Диспетчера.

(32) Инцидент появляется (как я вижу) в момент обращения (если это не вопрос "сколько время"). А дальше он только классифицируется, уточняется и маршрутизируется.

(32) смысл лишнего уровня (я про диспетчера)? сразу на первую линию, которая либо решает вопрос, либо передает его дальше.

(34) Первая линия в это время бегает и меняет картриджи и чистит мышки, они не могут принять звонок.

Без диспетчера никак, толпы будут в кабинете

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

Деление на диспетчеров и 1 линию нужно только когда частые обращения по одним и тем же косякам. А ля интернет провайдер, который чинит свою сеть

(37) Да пусть они сразу начальнику отдела звонят... И тот сразу побежит менять им мышку. У них же критический приоритет, и наплевать, что в это время сотрудник меняет картридж генеральному...

(39) не надо перегибать. я речь веду про диспетчеров и 1-ую линию поддержки.

(40) Я тоже.
А у меня были случаи, когда по поводу картриджей звонили мне, а не моему подчинённому.
Потому что первой линии не было.

Древний город Фенхуан и красота Китая
Фенхуан — древний город в китайской провинции Хунань. Фенхуан в переводе с китайского языка означает "феникс". Поселение хорошо известно своим сохранившимся старым городом, воспетым во многих легендах. Фенхуан находится во власти деревянных зданий на сваях. Город уникален, изящен, окружен живописными реками и горами — время здесь словно остановилось, а сооружения украшены красными китайскими фонарями.
Это действительно волшебное место, которое многие считают самым красивым городом в Китае. Древний город Фенхуан является объектом Всемирного наследия ЮНЕСКО. Древнее сообщество, расположенное в западной части провинции Хунань, более походит на Венецию Востока, только не подверженную модернизации и современному влиянию. Деревянные лодки, простые речные перекрестки, китайские здания на сваях, традиционная еда и одежда — все выглядит так, как будто это место застыло во времени.
[img]http://img-fotki.yandex.ru/get/5506/248960749.31d/0_118832_5a370501_XL.jpg[/img]
Очарование Фенхуана — это нечто выше простой естественной красоты. Во время прогулки по городу можно бесконечно восхищаться красоте древней архитектуры. Большинство узких улочек вымощены булыжником, а в магазинах продают абсолютно странные продукты — от головы свиньи, до мяса полевых крыс.
подробнее [url=http://vova-91.livejournal.com/5675315.html]тут[/url]

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

(43) Взяли сотрудника. Он и стал диспетчером de-facto.

(44) ок. может у меня подмена понятий. какой функционал он у Вас выполняет?

(45) Приём звонков, ответ на вопрос "сколько время", ввод заявок, разбор почты на help@ с редиректами.
И знаешь, свободного времени у него - только на обед да покурить сходить.

(46) а 1я линия поддержки?

(47) А первая линия, как я уже говорил, облизывает пользователей, мышки и картриджи меняет.

(48) ну и вывод напрашивается сам собой. выше мне кажется это озвучивал. все зависит от структуры отдела и количества обращений. у кого то есть отдельные эникейщики для принтеров, мониторов и мышек, а у кого то это делает сис.админ, который так же занимается сетью, серверами и т.д. и понять эффективность той или иной структуры и размера штата как раз поможет накопленная статистика по обращениям. обобщено я могу высказать свою мысль след. образом: количество уровней должно быть минимизировано для уменьшения отклика на решения проблемы без ущерба для эффективности работы. если есть производственная необходимость в доп. линии диспетчеров, то не вопрос. просто кто исключает возможность того, что, к примеру, доп.сотрудник на 1ую линию будет эффективнее, нежели чем два диспетчера? я не прав?

(49) Там где-то выше про статистику уже было, в начале.
Я согласен. Нужно набирать оную.

(49) "доп.сотрудник на 1ую линию будет эффективнее, нежели чем два диспетчера"
Прав, не спорю. Всё зависит от размера компании и количества обращений.
Но мы же ларьки не рассматриваем: ))