P.S. Насколько помню, раньше НАУЧНАЯ НОВИЗНА требовалась для кандидатских диссертаций, теперь уже и депломы новизной сверкать должны?

Мы так скоро весь научный мир за пояс заткнём.

Гораздо важнее для такого диплома, на мой взгляд, следующие вещи:

1. Общая методика. Назначение, цели, задачи, процедуры, роли -> организация контроля и оценки -> планирование и измерение KPI -> завязка на систему стимулирования.

2. Полнота системы метрик. Например, полный набор метрик для оценки какой-то должности, совмещающей несколько процессных ролей, или поставщика ИТ-услуг в целом.

3. Рациональность и обоснованность метрик. Смотрите книжку по прикладной информационной экономике, её можно найти и скачать в интернете.

4. Необходимость адаптации любых метрик под текущую задачу, процессные модели, возможности средств автоматизации. Бессмысленность копирования метрик.

Наконец, повышение эффективности — гораздо более широкая тема, чем просто измерение. Здесь я бы очень посоветовал внимательно прочитать книжку SS. Акценты в повышении эффективности будут меняться в зависимости от того, с каким вы работаете клиентом и на каком рынке.

Наткнулся на Вашу статью — очень интересная. Заметил что вы используете KPI. Нужна Ваша помощь. Работаю над написанием диплома «ITSM, повышения уровня эффективности предоставления IT услуг». Главное нужна в этой работе — НАУЧНАЯ НОВИЗНА! Посоветуйте идеи, например подобные KPI и как их рассчитать, и.т.д?

Заранее, огромное спасибо!

Тогда я ошибся в своём предположении.

Не знаю что вам даже про БГ сказать. Он мне и не нравится и не не нравится. Я практически музыкой не интересуюсь. Если у вас есть бесплатные билеты на его концертЮ то схожу, а если предлагаете диск купить, то воздержусь.

В итоге инцидент просрочен, с кого спрашивать непонятно (все работали).

Так ваша первая метрика именно на то и направлена, чтобы промотивировать участников оперативнее реагировать разве нет?

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

Ведь всё это звенья удлиняющие путь запросов пользователя. Пусть звонит на прямую специалисту.

Я не против заданий — пусть будут (контроль работ, учёт трудозатрат и так далее). Но реальное взаимодействие в Вашем примере будет телефонно-очным. Иначе никакие технологические цепочки не помогут.

Если мы часть активностей проводим в теневом формате, то нужна ли тогда метрика 1, которую мы обсуждали раньше?

Я просто для себя определяюсь, чтобы вашу мысль правильно понимать.

Если это а) инцидент и б) вопрос одного сервера, то конечно простым телефонным звонком, без всяких заданий и переназначений инцидентов.

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

Так всё же в приведённом мной примере случай функциональной эскалации или функциональная эскалация это только передача с первой линии на вторую, со второй на третью и т.д.?

Собственно можно сделать так:

По умолчанию штрафной бал 0. А если вы считаете, что смежник вас подвёл, то можете прописать ему какие-то штрафные балы.

Вы же сами говорили: «если Вы не можете сделать свою работу из-за смежников, которые не делают свою, у Вас хватит энергии один раз кликнуть мышкой».

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

Как обычно. Привлечение более высокой технической компетенции, если нашей не хватает.

«Группа 1 проводит поиск проблемы. Понимает, что для её решения надо остановить сервер. Сервре остановить может группа 2, после остановки сервера группа 1 проводит какие-то манипуляции, после чего группа 2 должна сервер запустить.»

Павел, признайтесь Вы что на практике реализуете такую обработку переназначением инцидента? Если «да», нескромный вопрос: «Зачем»?

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

Что же касается качества работы «смежников», то я при обсуждении первой метрики уже предлагал (или хотел предложить) использовать практику оценки результата. Т.е. каждый, кому вы переназначили инцидент может поставить вам оценку. Такие оценки, как мне кажется, вполен могут заменить обе этих метрики.

Если не сложно, уточните что вы понимаете под функциональной эскалацией?

В частности на примере, который я приводил. При такой схеме:

Группа 1 проводит поиск проблемы. Понимает, что для её решения надо остановить сервер. Сервре остановить может группа 2, после остановки сервера группа 1 проводит какие-то манипуляции, после чего группа 2 должна сервер запустить.

Передача от группы к группе будет функциональная эскалация или нет?

Да нет же, Павел Сказано как раз не так: «процесс должен использовать переназначение инцидентов только для функциональной эскалации» и далее три примера, один из которых Ваш. Речь не о том, что таких цепочек не бывает, а о том, что реализация таких цепочек переназначением инцидента — далеко не единственный (и на мой взгляд не лучший) вариант.

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

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

Но чтобы утверждать такое, необходимо проработать технологические карты инцидентов большинства типов.

А если мы обладаем технологическими картами, то более эффективно будет контролировать соблюдение этих карт. И метрика утрачивает смысл.

Вот как-то так.

Павел, я же специально добавил слово «ВАЖНО» и описал условия применимости данной метрики. Это не отвечает на Ваш вопрос?

Не совсем корректное допущение. Всё зависит от технологической цепочки. Например, вначале надо остановить сервер, а после каких-то с ним манипуляций запустить вновь.

Соответственно приходим к вопросу о необходимости типизировать инциденты и описывать их технологические карты. Иначе, мы будем вынуждены практически каждый случай разбирать индивидуально, и смысла в метриках не будет.

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