Поскольку посетители данного портала имеют некоторое отношение и к управлению услугами, и к организации работы первой линии поддержки, не могу не поделиться своими впечатлениями. Звонил тут как-то в банк, в котором я являюсь ипотечным заёмщиком. Технология общения с клиентом потрясает. Итак, набираю номер, мне, как обычно, отвечает робот. Далее последовательность действий следующая:

• приветственное слово (Здравствуйте, Вы позвонили, …, мы очень рады…);
• IVR 1-го уровня. Прослушиваю список, выбираю пункт «Кредиты»;
• IVR 2-го уровня. Прослушиваю список, выбираю пункт «Ипотека»;
• сообщение о том, что если я ещё не являюсь заёмщиком, я зря выбрал этот пункт меню IVR, мне здесь не помогут. Пауза;
• заверение о том, что теперь мой звонок переведён специалисту (наконец-то!). Пауза;
• неожиданно механический начальник контакт-центра предлагает мне оценить работу сотрудника (какую? какого?). Отказываюсь. Пауза;
• сообщение «В настоящий момент все наши операторы помогают другим клиентам». Мне не повезло. Зато честно. А может быть месть за то, что не оценил работу сотрудника. Длинная пауза;
• трубку снимает оператор, но к ипотеке она отношения не имеет и, внимательно выслушав мой вопрос, предлагает перевести меня на специалиста. С радостью соглашаюсь (я всё ещё надеюсь). Пауза;
• трубку снимает СПЕЦИАЛИСТ (УРА!). К сожалению, мой вопрос надо пересказывать заново – информацию ей не передали. Объясняю повторно;
• выслушав вопрос, СПЕЦИАЛИСТ просит меня назвать номер договора. Диктую и … тут звонок обрывается. Призовая игра!

Аплодисменты. Приз зрительских симпатий. Вот теперь я понимаю смысл слов, сказанных в самом начале: «Ваш звонок очень важен для нас»!

Если этот банк когда-нибудь купит мои консалтинговые услуги, я уже знаю, какую технологию работы с пользователями порекомендовать ИТ-директору. Зуб за зуб.

Мы как-то уже делали интеграцию OMNITRACKER с АТС по обработке входящих звонков. Схема стандартная. Идёт звонок, агент АТС вызывает обработчик, который по телефонному номеру находит пользователя и открывает его карточку в OMNITRACKER. Соответственно, сразу и текущие обращения видны, и новое одним кликом можно создать (разумеется, с предзаполнением заявителя).

Но вчера по запросу одного из потенциальных клиентов мы за несколько часов собрали аналогичное по функциональным возможностям решение по интеграции со скайпом. При входящем звонке через скайп появляется диалог с запросом, надо ли обрабатывать звонок в OMNITRACKER. Если оператор отвечает утвердительно, автоматически снимается трубка в скайпе (начинается разговор), а параллельно по skype id находится пользователь в OMNITRACKER. Причём skype id в OMNITRACKER может храниться просто как ещё один телефонный номер с подтипом «Skype» – полная унификация

Просто не мог не похвастаться. Всё штатными средствами – и со стороны Skype, и со стороны OMNITRACKER. Никому не надо?

Продолжаем публикацию материалов по измерению процесса управления инцидентами. Чтобы предотвратить «футбол» (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к метрике своевременности (которая бурно обсуждалась в заметке «Измеряем Incident management») нужна вторая метрика – результативности. О ней и поговорим в этой заметке.

Традиционно одна из метрик управления инцидентами была посвящена контролю возвратов на доработку и рассчитывалась по формуле «доля инцидентов, возвращённых на доработку, от общего количества инцидентов, решённых за период». В чём недостатки такой метрики? Их (как минимум) два:

• её трудно связать с группой специалистов. В самом деле, после возврата на доработку инцидент фактически мог быть решён другой группой – не той, которая отрапортовала о неверном решении и привела к возврату на доработку;
• эта метрика учитывает только передачу решения заявителю, но не учитывает внутренние передачи инцидентов между группами ИТ. Однако внутренние передачи инцидентов также могут быть нерезультативными, то есть увеличивать общее время обработки.

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

Тогда по каждой из групп метрику результативности можно представить в виде:

где  – KPI группы по результативности обработки инцидентов;

N – общее количество инцидентов, решённых за период (с участием данной группы);

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

Как обычно, метрика нормирована в диапазоне [0; 1]: 1 – отлично, 0 – наихудший результат.

ВАЖНО. Данная метрика применима только при соблюдении следующих условий:

• процесс должен использовать переназначение инцидентов только для функциональной эскалации. В моей практике встречались и другие случаи. Вот некоторые примеры:
  • возврат на Service Desk при передаче решения пользователям;
  • возврат группе, отвечающей за прикладное ПО, после устранения инцидента в базовой инфраструктуре;
  • последовательное переназначение инцидента (или обращения пользователя), требующего выполнения работ силами нескольких групп;
• при возврате инцидента на доработку (отказ пользователя) он должен изначально попадать на обработку той же группе, которая сообщила о решении (встречал случаи возврата на Service Desk, что лично мне кажется не очень логичным).

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

P.S. В следующей заметке я вернусь к тому, как из нескольких метрик (в нашем примере – метрики своевременности и результативности) можно сделать один KPI. И если Вы сразу готовы предложить среднее арифметическое, не спешите

Я очень хотел написать серьёзный пост. Про метрики, все дела. Сам понимаю, что период постновогоднего стёба несколько затянулся. Но открыл новости ... и не смог. А как пройти мимо такого? РПЦ освящает в Москве катки, чтобы сделать их менее травмоопасными. Цитата: "Освящение льда делается для того, чтобы снизить травмоопасность. На наших зимних праздничных мероприятиях всегда присутствует батюшка, он освящает лед, проводит молебен ... Вчера за все время народных гуляний не было зафиксировано ни одной травмы. Хочется верить, что это потому, что лед был освящен".

Это ж какой неисчерпанный (а может и неисчерпаемый) резерв? Священнослужитель освящает ваши информационные системы и они становятся надёжней. Количество инцидентов сокращается. Качество услуг растёт. Быстро, без хлопот, недорого. Потом можно будет и за мозги взяться... Ну позовите уже кто-нибудь, расскажете потом о результатах!

Ура, наконец-то вышла моя статья про изменения в стандарте ISO 20000-1 2011 года, написанная ещё в октябре. Может быть, она придётся в тему, как другой поворот в дискуссии, начатой Костей в его заметке. Полный текст статьи, как обычно, доступен на нашем сайте по адресу http://www.cleverics.ru/ru/subject-field/hot-issues/changes-in-the-iso20000-1-2011.

Помню в далёких девяностых на рынках многочисленные «предприниматели» предлагали гражданам свои услуги: «Золото, доллары куплю», «Доллары куплю / продам» и иже с ними. Помню одного гражданина, который пошёл существенно дальше других. Так одно время около Горбушки стояла девятка, в которой сидел спортивного вида мужчина, а на лобовом стекле была наклейка «Рассмотрю любые предложения». Вот она, культурная установка – всё для клиента. Прошли годы. Эта же установка никуда не делась, просто приобрела новые, более цивилизованные формы. И недавно на сайте одной компании я прочитал: «Основное направление деятельности компании Х – наиболее качественное удовлетворение покупательского спроса». Прекрасное направление деятельности

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

• Доктор Живаго. Борис Пастернак.
• Завтра была война. Борис Васильев.
• Жизнь и судьба. Василий Гроссман.

Коллеги / товарищи / граждане / господа, давайте успевать читать не только профессиональную литературу. А тем, кто не читал конкретно эти книги, но интересуется историей России ХХ века, настоятельно рекомендую. Это не только сильные литературные произведения, но и живой исторический материал.

Искренне ваш, ДИ.

Продолжаем публикацию находок по измерению процессов управления ИТ, начатую в заметке «Измеряем Problem management».

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

Пришло решение использовать в качестве одного из KPI групп поддержки метрику, значение которой рассчитывается по формуле:

где К_группы – KPI группы по своевременности обработки инцидентов;

N – общее число инцидентов, в обработке которых участвовала данная группа, за период;

v_i – 0 или 1. 0, если i-тый инцидент решён в срок. 1, если инцидент просрочен;

t_i – время обработки i-того инцидента силами данной группы, включая время реакции на назначение (время с момента назначения инцидента до переназначения в другую группу или окончания работы);

T_i – общее время обработки i-того инцидента (от регистрации до решения).

Поясню смысл формулы. За каждый инцидент, в обработке которого поучаствовала какая-то группа, она получает балл от 0 до 1. 1 – идеальный вариант, инцидент решён в срок. 0 – наихудший вариант, срок нарушен и ответственность за это целиком лежит на данной группе. Промежуточные значения соответствуют нарушению срока в результате работы нескольких групп. Причём штраф распределяется по группам пропорционально их доле в общем времени обработки просроченного инцидента. Значение метрики формируется усреднением баллов по всем инцидентам, прошедшим через данную группу. Оно также изменяется строго в пределах [0; 1]: 1 – отлично, 0 – наихудший результат. Поэтому для него легко установить целевое значение и использовать полученный KPI для контроля, а также стимулирования работы старших групп поддержки.

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

В литературе не встречал, поэтому решил опубликовать. Критикуйте, пожалуйста. Пользуйтесь на здоровье.

P.S. Примечательно, что эта метрика естественным образом «масштабируется» с уровня отдельной группы до уровня всего процесса. В самом деле, будем укрупнять группы поддержки до предельного состояния, когда единственная группа поддержки – это весь персонал поставщика услуги. В этом случае t_i становится равным T_i и формула принимает привычный вид метрики «доля инцидентов, решённых в срок»:

P.P.S. Предложенная метрика также легко может быть модифицирована для учёта того, как сильно просрочены инциденты (если нам не всё равно, был ли срок превышен на одну минуту или в несколько раз). Для этого каждому инциденту можно присвоить вес w_i. Вес равен 1, если инцидент решён в срок. Если же срок превышен, то вес может определяться, например, как отношение фактического времени решения инцидента T_i к установленному сроку. Тогда формула для расчёта метрики примет вид:

Чтобы лучше её осознать, введём обозначение:

Тогда метрика принимает привычный вид взвешенного арифметического среднего:

Где вес w_i определяет, на сколько (как сильно) был превышен срок обработки i-того инцидента, а рейтинг r_i – в какой степени ответственность за просрочку лежит на данной группе.

P.S.P.S. Чтобы предотвратить "футбол" (быстрое, бездумное перекидывание инцидентов в другие группы) плюс к предложенной здесь метрике своевременности нужна вторая метрика – результативности. Она также считается несложно, о ней напишу в отдельном топике. Вместе метрики своевременности и результативности образуют сбалансированную пару KPI для оценки деятельности групп поддержки.

ДОПОЛНЕНИЕ

По итогам обсуждения с Павлом Солоповым (за что ему спасибо) предлагаю альтернативный алгоритм расчёта метрики в P.P.S. Основное отличие – сокращение влияния действий других групп на значение метрики для заданной группы (за счёт нормировки не на общее время обработки T_i, а на срок решения инцидента T_i⁰).

Формула сохраняет вид взвешенного среднего в P.P.S, меняется только определение операндов. Вес w_i равен 1, если инцидент решён в срок. Если срок превышен, то вес равен отношению времени обработки инцидента силами данной группы t_i к сроку решения инцидента T_i⁰ (таким образом, вес может быть и больше, и меньше единицы), но не меньше 1.

Рейтинг r_i определяется выражением:

Нормировка [0; 1] сохранена.

Процесс управления проблемами часто считают процессом устранения ошибок в ИТ-инфраструктуре. Получается своего рода «компенсатор», корректирующий ошибки, заложенные на этапе проектирования и внедрения и проявляющиеся в ходе эксплуатации информационных систем. Однако многие инциденты (предотвращением которых занимается процесс управления проблемами) связаны не с техническими ошибками, а с организацией труда – исполнением, взаимодействием, принятием решений, контролем. Поэтому на моей практике ряд компаний (кто-то постепенно, кто-то сразу – при проектировании процесса) включили оргвопросы в охват управления проблемами.

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

Встречается редко. Собственно, рабочее управление проблемами вообще встречается редко, а уж это вообще высший пилотаж

В последнее время благодаря нашим клиентам мы довольно много времени уделяем обсуждению сервисного подхода в целом (как способа управления ИТ) и SLA в частности (как одному из артефактов). И я не могу не поднять эту тему, хоть и долго пытался сдерживать себя. А тема такова: бизнес-подразделениям / руководителям SLA нужны только в очень ограниченном наборе случаев (ВАЖНО: я не говорю здесь о SLA между участниками коммерческих отношений, только про SLA между ИТ-подразделением и бизнес-подразделениями, зависящими от ИТ).

Почему? Основная причина проста – соглашение предполагает равенство участников (во всяком случае в тех аспектах, которые касаются интересов сторон соглашения). Помните, как Пифагор определил дружбу? «Дружба это равенство». Если же одна сторона является заведомо подчинённой (ИТ-подразделение), то доминирующей стороне SLA не нужен – он ничего не гарантирует, однако зачем-то вносит ограничения. Именно такие отношения наиболее распространены вокруг нас. Тому есть несколько причин: традиции декларативного управления, исключительно поддерживающая роль ИТ-подразделения (в противовес лозунгам о стратегическом партнёрстве), неготовность ИТ-подразделения предоставить гарантии выполнения обязательств, существенная разница между потребностями бизнес-подразделений и предлагаемыми условиями SLA…

Случаи, когда SLA действительно могут быть востребованы бизнесом, крайне редки. Например:

• ИТ-подразделение в существенной степени независимо от потребителей. Например, в международной компании европейский ЦОД может предоставлять услуги подразделениям в разных странах (и необязательно на коммерческой основе), которые на сотрудников и руководство ЦОДа имеют крайне слабое организационное влияние, а SLA такое влияние может предоставить / усилить.
• Бизнес-руководитель высокого уровня, курирующий ИТ, зависит в оценке своей работы (в своих бонусах, например) от качества работы ИТ-подразделения. В этом случае он может быть заинтересован в SLA как в защите своих интересов.

В большинстве других случаев ИТ-шники сколько угодно могут сетовать на то, что «бизнес до них не дорос», «незрел» и так далее. Суть не в зрелости, а в том, что бизнес-руководителям это просто не нужно. Это не в их интересах.

Мне могут возразить и привести массу контрпримеров. Но прежде чем приступить, проверьте себя:

• Содержатся ли в Вашем примере SLA такие компоненты как L (Level – набор измеримых характеристик услуги) и A (Agreement – осознанное соглашение двух сторон)?
• SLA, который Вы выдвигаете в качестве примера нужен именно бизнесу?
• Если это так, используется ли он бизнесом после того, как однажды был подписан: выполняется ли его пересмотр, контролируется ли его соблюдение и так далее?

Вместе с тем, уж простите за крамольную мысль, SLA вовсе не является обязательным инструментом и неотъемлемой частью сервисного подхода (как и вообще процесс управления уровнем услуг). Более того, "навязывание" SLA может повредить, а не помочь. Поэтому развивая сервисный подход на предприятии нелишне подумать: «А зачем SLA потребителям моих услуг? Поможет ли он повысить их удовлетворённость, решить их задачи»?

Портал superjob.ru опубликовал аналитический отчёт по позиции "Директор по ИТ" на рынке труда. С оригиналом отчёта можно ознакомиться здесь: http://www.superjob.ru/research/articles/2024/direktor-po-informacionnym-tehnologiyam/.

К сожалению, авторы отчёта использовали аналитику только по регионам — ни по отрасли, ни по размеру компании деления нет. Поэтому цифры по зарплате получились сильно усреднёнными. Далее, опыт показывает, что поиск директора по ИТ посредством публикации вакансии на superjob.ru — не самая распространённая практика. Чаще в ход идут рекрутинговые агенства и личные связи / рекомендации. Видимо поэтому цифры по заработной плате в отчёте на мой взгляд занижены (по крайней мере по Москве, в диапазонах 3-4). Впрочем, в отчёте указано, что данные по зарплате приведены "без учёта бонусов, дополнительных льгот и компенсаций", поэтому ориентироваться на них становится вообще невозможно.

Добавлю также, что по нашим данным на позицию директора по ИТ обычно очень высокий конкурс — более ста человек на место. При этом большинство кандидатов на данную позицию откровенно "не тянут". Поэтому ни относительно высокая заработная плата, ни большое количество претендентов не облегчают задачу поиска — найти грамотного директора по ИТ весьма непросто.

"Узок круг этих людей. Страшно далеки они от народа" (почти по Ленину)

Иногда тянет пофилософствовать. На днях много думал о требованиях к сотрудникам (аналогичное упражнение, кстати, выполняется в рамках нашего курса «Управление персоналом ИТ»). Мысли решил оформить – жажду обсуждения.

Идеальный работник...

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

1. Интеллект (I, Intelligence). Позволяет решать новые задачи, изобретать, стимулирует учиться.
2. Энтузиазм (E, Enthusiasm). Обеспечивает энергию для достижения результата, целеустремлённость для преодоления трудностей.
3. Дисциплина (D, Discipline). Помогает не распыляться и не тратить времени попусту (самодисциплина), помогает работать в команде и делать не только то, что нравится, но и то, что необходимо (внешняя дисциплина). Нельзя надеяться только на вдохновение («придёт – сделаю, не придёт – извините»), надо уметь работать «здесь и сейчас», каждый день, в заданный срок.

Опыт (X, eXperience) является функцией времени и перечисленных трёх факторов:

X = f (I, D, E, t)

Наличие IDE позволяет компенсировать и нехватку знаний, и недостаток опыта. С другой стороны избыток опыта ведёт к потере мобильности («Опыт позволяет нам ошибаться гораздо уверенней») и трудностям в адаптации к новой команде («Мы и сами с усами»).

Характеристики IDE скорее являются не кратковременными факторами, а свойством личности. Напротив, знания и опыт – локальные факторы, поскольку зависят от конкретной задачи. Сотрудник с высокими показателями IDE является долгосрочным активом, поскольку пригодится не только для решения одной задачи, но может расти на задачах и тем самым обогащать команду.

… и консультант

Приведённые выше рассуждения не специфичны для консалтинга. В чём же профессиональная специфика консультанта? В трёх навыках:

1. Навык задавать правильные вопросы. Начинающие консультанты думают, что «сила» в знании нужных ответов. Однако глубокий анализ той или иной ситуации, а также возможность искать индивидуальные решения (вместо применения типовых) требуют умения спрашивать. Поговорка про консультанта: «Умный ищет истину, дурак уже нашёл».
2. Навык слышать собеседника. К чему задавать вопросы, если ответы не будут услышаны? Консультант – больше уши, чем язык. Тезис «Этот процесс описан в авторитетной книжке, книжка утверждает, что он правильный, поэтому лучше работайте так» к консалтингу не имеет никакого отношения. Это тезис массовой Internet-культуры – воспроизводить, а не создавать.
3. Навык воодушевлять команду (убеждать, передавать часть своего энтузиазма). Красивые идеи есть у многих. Их легко услышать и повторять (воспроизводить). Ценность для заказчика не в самой идее, а в возможности превратить её в результат. А консультант в области управления за заказчика результат получить не может. Его задача – сделать так, чтобы этого результата заказчик достиг сам.

И немного мыслей на будущее

Есть идеи, как можно измерять IDE при подборе персонала (частично мы уже это делаем, но, думаю, можно делать больше). Есть понимание, как постепенно развивать навыки консультанта (пока нет идей, как сделать это быстро – за неделю). Буду ещё думать, потом тоже напишу.

Идеи, мнения, возражения – приветствуются. Со страшной силой.

Во вторник 04.10.2011 на CIO Summit’е прослушал очередной доклад про облака. Задал докладчику вопрос, но, к сожалению, несмотря на несколько попыток других слушателей вернуть автора к поставленному вопросу, ответ так и не получил. Вопрос был про то, не превращается ли поставщик облачных услуг, который предоставляет и серверные мощности, и системы хранения данных и даже (как в упомянутом докладе) виртуальные рабочие станции в незаменимого поставщика услуг? Помимо риска утечки конфиденциальных данных, который уже много обсуждали, не становится ли таким же значимым риск возникновения критичной зависимости от поставщика облачных услуг? Насколько вообще реально «перевезти» действующую виртуальную инфраструктуру, приложения и данные к другому поставщику?

В разговоре докладчик в том числе сформулировал мысль о том, что для многих предприятий разумным является путь реализации приватных облаков. Но, простите, я вообще с трудом понимаю, чем термин «приватное облако» образца 2010—2011 годов отличается от массовой виртуализации 2005—2009 годов, а она, в свою очередь, от «адаптивного предприятия» 2003—2005 годов? Серьёзно, что вообще такое «приватное облако» как не внутренние мощности, называемые новыми словами?

Хотелось бы разобраться. Вообще, надо очень стараться избегать «облаков» в профессиональном разговоре, даже если он – про облака Туман напустить каждый может, изложить содержательно и ясно – существенно сложнее. Есть желающие?

Эта тема уже была затронута мной в одном из постов. Однако развития она не получила, а мне кажется важной (не хотел бы, чтобы она потерялась в глубине комментариев). Контекст обсуждения был таков: прежде, чем внедрять какие-то процессы (медицинская аналогия – принимать лечение), сначала надо выполнить всестороннее обследование (медицинская аналогия – поставить диагноз). И мысль безусловно правильная, но, как мне кажется, есть и другая сторона вопроса. Итак:

Операционные процессы управления ИТ (inc, reactive prb, chg+rel) – это не «лечение», которое должно быть индивидуально показано пациенту, а «физкультура», которая может применяться всеми «без рецепта» (при должной адаптации, разумеется). Это базовые процессы, которые могут применяться как для поддержки сервисного подхода, так и независимо от него. Эти процессы структурируют операционную деятельность, которая существует независимо от веры организации в ITSM. Обследование в данном случае скорее должно отвечать не на вопрос «Нужны ли эти процессы?», а на вопрос «Как их правильно организовать, на чём сделать акцент?».

Как раз сервисный подход, напротив, «показан» далеко не всем, есть пререквизиты.

• Формальная сторона сервисных отношений – обязательства (обещать то, что можешь, и делать то, что обещал) – требует возможности предсказуемого управления операциями (то есть зависит от операционных процессов).
• Неформальная сторона сервисных отношений – сотрудничество (искать способ содействия потребителю ИТ-услуг в решении его задач) – требует определённой культуры, изменить которую в рамках одиночного проекта силами только внешних консультантов едва ли возможно.

Вот здесь обследование действительно должно дать ответ на вопрос «Надо ли? И если надо, то кому и зачем?».

Спорно? Давайте поспорим.

Публикую мысли, сформулированные одним из наших заказчиков. Без правки и корректировок — как есть. И давайте срочно обсуждать. И так:

Основные причины обратиться к Agile — неудовлетворенность сроками внедрения решений/процессов и соответствия результатов требованиям в динамично меняющейся среде.

Итак, что такое Agile применительно к внедрению и развитию процессов?

Берем Agile manifesto (есть терпимый перевод на Википедии). Выписываем. Меняем слова.

Ценности Agile:

1. Individuals and interactions over processes formal rules and tools.
Личности и их взаимодействие важнее, чем формальные правила и инструменты

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

2. Working software processes over comprehensive process documentation.
Работающий процесс важнее, чем полная документация по нему

3. Customer collaboration over contract negotiation.
Сотрудничество с заказчиком важнее, чем контрактные обязательства

Это не очень четко ложится на процессную тематику, но тоже поддается расшифровке.

4. Responding to change over following a plan
Реакция на изменения важнее, чем следование плану

Аналогично корректируем
Принципы Agile:

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

Ключевое отличие подходов waterfall и agile:

• waterfall фиксирует scope (требования), стоимость и сроки являются зависимыми величинами
• agile фиксирует срок (продолжительность итерации), scope является зависимой величиной

Очевидные плюсы и минусы:

Плюсы:

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

Минусы:

• существуют риски получения конечного результата (в нашем случае — полноценного всеохватывающего процесса) в более долгие сроки, чем при waterfall подходе
• более высокие требования к квалификации и дисциплине команды, чем при waterfall
• Agile практически не совместим с Fixed-price контрактным подходом, подходит только для внутренних процессных команд или внешних подрядчиков, к которым у заказчика есть полное доверие
• предполагает частые, но небольшие изменения процесса, что каждый требует дополнительной организационной работы (хотя непонятно, почему ИТ не так сильно заботит то, что бизнес каждый раз должен корректировать свои процессы при выходе новой версии ПО)
• Agile считается ограниченно годным для критичных для организации ПО процессов (хотя к ИТ это может относиться только разве что к Incident Management, и то не везде) и для крупных проектов (хотя я пока не видел ITSM проекта, в котором бы участвовало более 20 проектировщиков).

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

В очередной раз в обсуждении с заказчиком я сталкиваюсь с серьёзным непониманием отличий процесса управления проблемами от управления инцидентами. Корневых причин такого непонимания (простите за каламбур) я вижу две: невнятный текст про взаимодействие этих процессов в книгах ITIL (в частности, однозначная рекомендация привлечения PRB к решению major-инцидентов) и отсутствие специфичных алгоритмов обработки проблем в средствах автоматизации процессов ITSM, по которым зачастую осознают процессы как заказчики, так и консультанты.

Размышляя об этом явлении, хотел бы сформулировать основные отличия этих процессов. Главный тезис заключается в том, что процесс управления проблемами – это не «медленный» инцидент-менеджмент и не «другой» инцидент-менеджмент, который работает по отношению к наиболее страшным инцидентам и так далее. Это совсем другой процесс. Отличия начинаются с разницы в назначении процессов (этот факт известен всем), но на этом не заканчиваются. Вот ключевые отличия от управления инцидентами в организации деятельности:

• Определение сроков. В отличие от инцидента, у проблемы нет единого срока устранения, и в общем случае он не может быть определён (тем более при регистрации проблемы). Вместо этого есть сроки обработки проблемы на различных этапах – диагностика, решение и так далее. Часть этих сроков может быть нормирована, часть – является результатом планирования (например, срок решения проблемы может определяться по результатам планирования изменения, необходимого для решения проблемы).
• Обработка известных ошибок. В отличие от инцидентов, которые должны быть устранены как можно быстрее любым приемлемым способом, управление проблемами регулярно сталкивается с ошибками, которые определены, но не могут быть сразу устранены. Поэтому процесс управления проблемами должен организовывать деятельность по контролю известных ошибок, которая управлению инцидентами абсолютно не свойственна.
• Триггеры процесса. Если управление инцидентами в основном запускается пользователями (внешним триггером) и они не заставят себя ждать, процесс управления проблемами сам собой работать не начнёт, если не определить способы порождения проблем и не контролировать, что эти способы применяются.
• Ролевая структура. Серьёзное отличие от управления инцидентами – необходимость диагностирования проблем с привлечением различных групп специалистов. Это приводит к необходимости назначения координаторов отдельных проблем, что в целом для управления инцидентами нехарактерно (пожалуй, за исключением MIM). Процесс также должен определять порядок контроля деятельности координаторов проблем.
• Метрики. Забудьте о метрике «доля своевременно решённых проблем», это метрика инцидент-менеджмента. У процесса управления проблемами своя логика работы и свои метрики (см., например, здесь).

Про проактивное управление проблемами даже не упоминаю. В первую очередь потому, что проактивное управление проблемами – суть тактический процесс, стоящий рядом с управлением мощностями и доступностью. Это совсем не просто «довесок» к реактивному управлению проблемами, и я склонен выделять их в разные процессы.

Готов дискутировать с несогласными.

Вчера присутствовал на курсе "Process management and improvement", который вёл Роман Журавлёв. На курсе в очередной раз была поднята тема «Что писать в SLA, когда мы только запускаем SLM, и бизнес не готов формулировать требования»? Конечно, обсудили типичные «ходы»: запуск не по всем, а только по наиболее критичным услугам (где выше потребность и понимание сторон), оценка необходимости SLM до внедрения (ибо, в отличие от поддержки пользователей, этот процесс управления «показан» далеко не всем организациям) и так далее.

Однако недавний инцидент у нас в компании навёл меня на дельный совет: пишите требования к резервированию и восстановлению данных. Это тема очень понятна заказчикам и вполне проработана для того, чтобы правильно задавать наводящие вопросы:

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

И так далее, всем понятно.

Наличие бэкапов, которые предсказуемо (без сюрпризов для владельцев информационных ресурсов) позволяют восстанавливать данные, значимо не только для заказчиков, но и для ИТ-шников. Если без процессов управления ещё как-то спится по ночам (только вечера и выходные почему-то загружены), то без бэкапов – вообще не жизнь. Вот с этого и можно начать. А если эти требования уже когда-то и где-то зафиксированы, можно проверить их актуальность и зафиксировать «as is».

Опыт показывает, что потребность в восстановлении данных зачастую возникает не в связи с глобальными отказами, а из-за банальных человеческих ошибок. Их не исключить, остаётся только страховаться. Именно такая ошибка и привела к серьёзному нарушению целостности одной из баз данных у нас в компании. Перекрестились и восстановили, в соответствии с договорённостями (письменных SLA нет, но тему проговаривали и согласованные требования остались). Свят-свят…

Обсуждали тут как-то с коллегами Agile, как подход к разработке ПО. Мне эта идея была нова (хотя название уже давно «на слуху») и в ходе разговора показалась любопытной. Более того, показалось любопытной возможность применения Agile к ITSM (этим летом я несколько раз обсуждал возможность итерационного внедрения процессов ITSM, короткими циклами с минимальной «бюрократией» с одним из заказчиков, и разговор про Agile напомнил мне об этой идее).

И вот довольно быстро я нашёл интересную заметку на сайте Скептика "Tipu: a framework for service management Continual Service Improvement (CSI)". Суть оказалась очень созвучна идеям, которые бродят в голове, подбрасываются заказчиками и более того – уже находят практическую реализацию в проектах. И так, суть, коротенько:

• CSI – не просто «надстройка» над базовыми процессами управления ИТ-услугами, а фундаментальный элемент системы управления. Организовывать CSI надо не после внедрения процессов (как крышу после стен дома), а с самого начала – в рамках первых же инициатив по внедрению процессов ITSM. Используя CSI, можно постепенно и органично «достраивать» систему управления ИТ-услугами;
• внедрение системы управления ИТ-услугами «в нарезку» по отдельным процессам – довольно странная идея, поскольку один изолированный процесс не так уж часто является оптимальным ответом на управленческую задачу заказчика. Разумнее отталкиваться от реальной задачи (need, problem, risk) и для её решения «подбирать» набор процессных элементов, которые направлены на решение и могут быть внедрены в относительно небольшие сроки, образуя пусть на относительно невысоком уровне зрелости, но целостный элемент системы управления;
• не надо строить идеальных процессов. Стройте то, что «как-то работает», а при появлении дальнейшей необходимости наращивайте уровень зрелости, используя интегрированный подход CSI (и к услугам, и к процессам).

Скептик называет этот подход словом «Tipu», что на языке коренных жителей Новой Зеландии – народа Маори – означает «рост», «расти». Насколько я понял, это уже не просто идея, а более-менее целостный подход, который ожидает апробации, публикации и будущего развития сообществом профессионалов, открыто и бесплатно для потребителей. То есть Tipu будет строиться по принципам Tipu.

Мне показалось очень любопытным и созвучным с моими мыслями. Вполне возможно, что удастся принять участие в «росте роста» и тем самым подрасти Это было бы здорово.

2 марта 2011 года я написал заметку в блог по итогам оценки эффективности расходов на ИТ в РФ, которая была выполнена счётной палатой. Вывод, сформулированный счётной палатой, был просто фантастическим: 99% госбюджетов на ИТ расходуется эффективно. Работая в отрасли, я внутренне с этим выводом согласиться не мог, в моих сомнениях меня также поддержали мои коллеги. Мы сошлись во мнении, что, видимо, пока счётная палата не получила достаточного стимула для реальной оценки положения вещей.

И вот мэр ушёл, и стимул пришёл! И счётная палата дала оценку эффективности расходования на ИТ в Москве в период 2008—2010 и начала 2011 года. Любопытно сопоставить результаты.

Оказалось, не всё так шикарно. Вот некоторые примеры:

• Департаментом информационных технологий по результатам исполнения 33 государственных контрактов на общую сумму 3 296 359,7 тыс. рублей предполагалось разработать и ввести в промышленную эксплуатацию 86 ИСиР и отдельных подсистем. По состоянию на 15.06.2011 распорядительными документами Правительства Москвы в промышленную эксплуатацию введено 25 ИСиР (подсистем), кассовый расход на их создание составил 542 131,9 тыс. рублей. Не введена в промышленную эксплуатацию 61 система (подсистема), расходы в сумме 2 754 227,8 тыс. рублей произведены безрезультатно. Замечу, не введена в эксплуатацию 61 система из 86!
• В ходе выборочной проверки установлено, что для нужд города более пяти лет не используется оборудование и вычислительная техника на общую сумму 452 428,5 тыс. рублей, закупленные в рамках проектов по созданию общегородских ИСиР.
• Не имеют перспектив ввода в промышленную эксплуатацию 45 ИСиР, разработанных в рамках шести государственных контрактов 2008—2009 годов на общую сумму 338 470,0 тыс. рублей.
• Работы по поставке и монтажу оборудования для создания телекоммуникационных узлов РОСПД с общей ценой работ 1 566 137,8 тыс. рублей (1526 комплектов) были завершены в декабре 2008 года. По состоянию на 15.06.2011 Департаментом информационных технологий решение о приемке работ не принято. Государственные контракты на эксплуатацию РОСПД в период 2008—2011 годов не заключались, сроки гарантийного обслуживания оборудования истекли.

И так далее. Иными словами, проценты в существенной степени определяются тем, как и для чего (а также про кого) их считают.

Выводы (которые сделаны уже давно и только подкрепляются этим отчётом КСП Москвы):

• Действующие нормы в части госзакупок неэффективны (есть множество примеров и в данном отчёте, и из жизни).
• Результаты контроля расходования средств (в том числе на ИТ) используются не безусловно, а в соответствии с политическим заказом.
• Эффективность управления, которую демонстрируют чиновники (которые по идее являются профессиональными управленцами), оставляет желать лучшего.

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

P.S. Да, забыл добавить, что, с учётом распределения бюджетов между Москвой и регионами, расходование на ИТ с эффективностью 99% в масштабах страны при таком положении дел в Москве требует от регионов работы с эффективностью выше 100% При этом моё личное мнение — в регионах в среднем всё обстоит ничуть не лучше.

Доля правды

Для того, чтобы измерить пользу, которую приносит тот или иной процесс управления организации, разумно отталкиваться от назначения процесса (подробнее о назначении процесса смотри http://www.realitsm.ru/2011/07/purpose-goals-and-objectives).

Для процесса управления уровнем ИТ-услуг назначение может быть сформулировано следующим образом: обеспечение качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий. В такой редакции SLM ответственен за реализацию цикла PDCA над оперативной деятельностью в рамках жизненного цикла услуг, направленного на постепенное устранении несоответствий между ожиданиями заказчика услуг и реальными показателями предоставляемых услуг. Именно такой подход (без привязки к ИТ) зафиксирован в разделе 0.2 «Process approach» стандарта ISO 9001:2000 «Quality management systems – Requirements».

Традиционный подход к измерению качества ИТ-услуг основан на введении индекса качества, который даёт интегральную оценку степени соответствия различных характеристик услуги целевым значениям в заданном SLA. Объединяя затем индексы качества по всем SLA с данным потребителем, можно получить итоговую оценку качества предоставляемых ему услуг. Такой подход, однако обладает рядом недостатков. Главный, на мой взгляд, заключается в том, что точка зрения заказчика услуг учитывается исключительно как набор зафиксированных целевых значений к параметрам услуг. На практике это нередко приводит к тому, что «по показателям» у ИТ-подразделения «всё в ажуре», при том, что заказчики ИТ-услуг удовлетворены далеко не на 100%.

Вместе с тем, в случае оказания индивидуальных услуг (в отличие от производства массовых товаров) возможен другой, более остроумный подход. Он заключается в том, что оценивается непосредственно удовлетворённость заказчика услуги. Для его реализации можно зафиксировать набор ключевых вопросов, задаваемых заказчикам на регулярной основе. Например (только суть, на вординг внимания не обращайте):

1. Степень удовлетворённости достигаемой utility услуг?
2. Степень удовлетворённости достигаемой warranty услуг?
3. Степень соответствия показателей warranty реальным потребностям заказчика?

Ответы даются по шкале 0-1 (0 – полное несоответствие, 1 – полное соответствие). Для определения итогового показателя можно использовать взвешенное арифметическое усреднение.

Ценность такого подхода не только в его простоте, но и в том, что он даёт оценку степени соответствия результатов деятельности поставщика услуг непосредственно «из первых уст» – уст заказчика услуг. Кроме того, он может включать в себя оценку не только warranty, но и utility услуг. А всякие «доли инцидентов, решённых в срок» оставим профильным операционным процессам.

Доля шутки

У такого подхода также есть весьма забавная геометрическая интерпретация. Обозначим ответы на вопросы 1-3 в примере выше как X_i. Поскольку X_i изменяется от 0 до 1, можно представить его в виде косинуса некоторого угла Ф_i (изменяемого от 0 до Pi/2). Тогда:

• если X_i = 1 (поставщик полностью соответствует ожиданиям заказчика по i-тому показателю), то Ф_i = 0. Фактически, заказчик и поставщик смотрят в одну сторону, воспринимают происходящее «под одним углом»;
• если же X_i = 0 (полное рассогласование), то Ф_i = Pi/2. То есть заказчик и поставщик воспринимают происходящее абсолютно по-разному, перпендикулярно друг другу;
• промежуточные значения 0<X_i<1 соответствуют «некоторому повороту» 0<Ф_i<Pi/2 взгляда поставщика относительно взгляда заказчика.

Идеальной ситуации соответствует равенство Ф_i=0 для всех i. То есть имеет место полное «выравнивание» между поставщиком и потребителем. Вот вам наглядная геометрия BITA

P.S. Да, придумал сам.

P.P.S. Нет, не курил.

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

Знания, навыки и личностные характеристики кандидата на исполнение роли менеджера процесса можно оценить и проанализировать. У нас даже есть типовая анкета, которую мы используем в проектах при выборе менеджеров процессов. Она состоит из трёх разделов: личностные качества, навыки и знания управленца, мотивация. Но по большому счёту эта анкета предназначена для оценки характеристик, общих для линейных менеджеров и руководителей среднего звена (в ней не представлены вопросы стратегического планирования, а сделан акцент на оперативное управление). То есть никакой специальной «заточки» под процессное управление в ней нет.

Вопрос собственно заключается в том, есть ли в процессном управлении серьёзная специфика, значимые отличия от функционального управления (управления отделом, группой).

Поясню на примере. Обычно у линейных менеджеров (старших групп, начальников небольших отделов) из двух базовых компетенций – в предметной области (сети, СУБД, приложения и так далее) и в организации труда – компетенция в предметной области развита сильнее. Да, это приводит к некоторым негативным последствиям, проявляющимся из-за неумения правильно распределять задачи и контролировать их исполнение, планировать и так далее. Но если бы такой руководитель не знал матчасть, то негативные последствия могли быть куда серьёзнее. То есть на линейном уровне менеджер прежде всего является предметником. Менеджер процесса, напротив, управляет деятельностью, в которую вовлечены разные подразделения, разные предметники. Следовательно, ему просто необходимо иметь более выраженные навыки управленца, уметь организовывать работу, не полагаясь на свою компетенцию в предметной области.

То есть разница конечно есть. Однако даже в приведённом примере навыки организации работы, которые должны быть более выражены у менеджера процесса, являются общими навыками для руководителя – целепостановка, планирование, организация исполнения (делегирование, распределение задач, мотивация, …), контроль и оценка. Есть ли у процессного менеджера какие-то свои, специфичные требования? Любой ли грамотный управленец может стать эффективным менеджером процесса? Конечных ответов для себя пока не сформулировал, взываю к общественности.

P.S. По идее, если отвечать на вопрос системно, надо исходить из анализа специфики объекта управления. Например, менеджер сквозного процесса управляет не своими ресурсами (ресурсами подразделений, которые подчиняются своим руководителям). То есть получается, что функциональный менеджер является владельцем ресурсов, а процессный менеджер "получает" их для достижения заданной цели. Может быть надо думать в этом направлении?

Удивительно, как иногда простые идеи долго доходят до сознания. Неожиданно осознал идею ITIL разделять purpose, goals и objectives по отношению к процессам. Более того, пришёл к выводу, что мы уже давно используем это в своей проектной практике, просто называем немного другими словами.

И так, purpose. Назначение процесса

Роман Журавлёв как-то опубликовал классную заметку «Some heretical opinions on ITIL service lifecycle» на itsmportal.com, в которой высказал точку зрения, что назначение бывает не у процессов, а у функций. Попробую поспорить (не в целом конечно, а только по этому поводу). Думаю, назначение процесса существует. Это формулировка, которая определяет место процесса в процессной модели, то есть натурально отвечает на вопрос «зачем нужен этот процесс, за что он отвечает». Примеры:

1. Управление инцидентами и запросами пользователей – обеспечение качества ИТ-услуг за счёт скорейшего устранения инцидентов и своевременного выполнения запросов на обслуживание.
2. Управление проблемами – повышение надёжности ИТ-услуг за счёт предотвращения повторов инцидентов посредством определения и устранения корневых причин их возникновения.
3. Управление уровнем услуг – обеспечение качества ИТ-услуг за счёт согласования и контроля соблюдения обязательств поставщика ИТ-услуг, а также организации устранения выявленных несоответствий.

И так далее. Вряд ли эти формулировки будут значительно меняться от внедрения к внедрению, если только не пересматривать процессную модель в целом.

Ответственный за определение назначения процесса – дизайнер (технолог / проектировщик) процессов (то есть специалист по процессам, а не управленец).

Goals. Цели процесса

Цель определяет, что должен обеспечить процесс в некоторый фиксированный отрезок времени (в отличие от назначения, которое определяется без привязки к конкретному периоду планирования). Например, для управления инцидентами это может быть «обеспечить увеличение доли своевременно решённых инцидентов до 95%» или «довести долю обращений, обработанных на первой линии, до 30%» и так далее. Ключевые характеристики целей:

1. формулировка с применением глаголов совершенной формы;
2. измеримость (причём скорее всего метрика будет присутствовать непосредственно в формулировке цели);
3. привязка к отрезку времени (цель ставится на месяц, на квартал, и так далее, а не вообще – навсегда).

Короче, SMART. Все помнят, зачем повторяться.

Ответственный за определение целей процесса – владелец процесса. Цели процессов должны регулярно пересматриваться (уровень зрелости 3+ и выше). Наличие у процесса ясных и актуальных в данный момент времени целей является одним из важнейших индикаторов того, что владелец процесса действительно исполняет свои функции.

Интересно, что регулярный пересмотр целей приводит к тому, что цели процесса бессмысленно фиксировать в регламенте процесса (иначе его попросту придётся постоянно пересматривать). Разумно фиксировать цели процесса в текущих планах управления, картах целевых показателей и так далее (кто что использует). Это ещё одно явное отличие целей от назначения процесса.

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

Objectives. Задачи процесса

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

С задачами, также, как и с целями, связываются метрики. Как правило, задачи меняются гораздо реже целей (если только цели не меняются столь кардинально, что требуют постоянного пересмотра процесса). А потому разумно фиксировать задачи процесса непосредственно в регламенте данного процесса.

Ответственный за определение задач процесса – менеджер процесса. С методической точки зрения ему может / должен помогать дизайнер процесса, но ответственность за то, что цели процесса соответствуют не только назначению, но и целям лежит именно на менеджере. Причины понятны – менеджеру ставится задача, он обеспечивает её реализацию, включая выбор способа.

Итог

Собственно, вот и вся история. Из песни слова не выкинешь – все три уровня нужны. Немного жаль только, что в книгах ITIL они сформулированы столь … небрежно. Может быть от того и так долго доходят

И опять из навеянного недавними встречами и обсуждениями с Заказчиками. Вообще назначение процесса управления релизами и его организация вызывают массу вопросов:

• Нужен ли процесс управления релизами как отдельный процесс?
• Для обработки каких изменений будет привлекаться процесс управления релизами?
• В каких отношениях находятся процессы управления релизами и изменениями (кто кому выдаёт задания, кто перед кем отчитывается, кто принимает решения, а кто их исполняет)?

Часть из этих вопросов уже поднималась в предыдущих обсуждениях на этом сайте.

Стремясь привести свои давние мысли на этот счёт в порядок, я решил освежить свои знания первоисточников, коих использовал три: ITIL, BMC Service Management Process Model (SMPM), IBM Tivoli Unified Process (ITUP). Свои выводы (наверняка для многих весьма спорные) решил обнародовать.

И так, несмотря на то, что в разных источниках используется одно и то же название «Release management», речь на самом деле идёт о разных процессах (что и вызывает путаницу). Разных не только по способу организации, а по назначению, по месту в процессной модели. Для того чтобы лучше с этим разобраться, возьмём произвольную ИТ-организацию и выделим в ней два подразделения: одно будет отвечать за эксплуатацию информационных систем, другое – за разработку и сопровождение (границы между эксплуатацией и сопровождением берём согласно ISO 12207 «Software Life Cycle Processes»). Так вот в такой ИТ-организации возможны два разных взгляда на управление релизами.

Первый: управление релизами осуществляется в рамках подразделения разработки / сопровождения.

В этом случае на вход процесса попадают требования к изменению ИС (неважно, в виде запроса на изменение или просто в виде служебки с функциональными требованиями), на выходе будет релиз, которые эти требования реализует. Содержание процесса:

• анализ требований;
• разбивка их на логические группы;
• планирование с учётом политик релизов;
• организация разработки;
• квалификационное тестирование;
• выпуск (передача к внедрению в продуктив).

Далее релиз передаётся в подразделение эксплуатации (то есть выполняется приёмка релиза), где в рамках управления изменениями внедряется в продуктив. Похоже, именно о таком процессе написано в SMPM. Вот характерные признаки такого процесса:

• он обрабатывает только нестандартные запросы на изменения (стандартные обрабатывает процесс управления изменениями);
• он самостоятельно (не управление изменениями!) отвечает за авторизацию изменений на CAB’е;
• он имеет дело только с изменениями в приложениях (изменения в инфраструктуре также обрабатываются процессом управления изменениями самостоятельно);
• естественное определение релиза – набор компонент, которые вместе тестируются и внедряются в продуктив.

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

Второй: управление релизами осуществляется в рамках подразделения эксплуатации.

В этом случае получаем привычный Release management, который отвечает за объединение нескольких изменений в релиз и организует безопасное и контролируемое внедрение. Содержание процесса (каноническое, жизнь потребует корректив):

• определение охвата и содержания релиза;
• сборка релиза;
• тестирование релиза;
• планирование развёртывания релиза;
• информирование всех участников и потребителей услуг;
• развёртывание релиза.

Именно о таком процессе написано в ITIL и в ITUP. Вот характерные признаки такого процесса:

• стандартные изменения, не требующие всей бюрократии процесса управления изменениями, могут попадать напрямую в управление релизами (то есть, в отличие от BMC-шной модели, это управление релизами прекрасно может выполнять стандартные изменения);
• за авторизацию изменений (и, в частности, за CAB) отвечает управление изменениями, управление релизами – «инструмент» управления изменениями, отвечающий именно за внедрение;
• он может применяться и по отношению к приложениям, и по отношению к инфраструктуре (например, развёртывание стандартного рабочего места для нового сотрудника вполне может быть работой управления релизами);
• естественное определение релиза – набор изменений, которые вместе тестируются и внедряются в продуктив.

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

Что называется, почувствуйте разницу. Если в беседе вы зафиксируете тему не просто в виде «Release management», а договоритесь, о каком именно управлении релизами идёт речь, вы сможете избежать непонимания и обоснованно ответить на заявленные вопросы в начале поста.

P.S. Для подготовки этого описания я сознательно упрощал картинку. Можно развернуть целую дискуссию по уточнению характеристик этих двух различных процессов управления релизами. Думаю, не стоит. Чтобы осознать разницу, надо упрощать. Мне здесь интереснее именно принципиальная разница между двумя видами управления релизами.

Как известно, есть ложь, есть гнусная ложь и есть статистика. А статистики по пользе от применения ITIL (в частности) или реализации сервисного подхода к управлению ИТ (в целом) практически нет (извините за каламбур). Цифры, которые легко встретить в Internet, потрясают. Только два примера:

1. Внедрение волшебной ITSM-программы (в принципе, Вы можете подставить любое название) повысило эффективность персонала более, чем на 80% (!!).
2. Внедрение процесса управления инцидентами сократило (!) количество инцидентов на 40%. Вот так. Невзирая на цель процесса управления инцидентами. Сократило и всё.

Поэтому внимание, вопрос. Во-первых, если Вы видели и другие примеры подобных профанаций, пишите. Так по крайней мере хоть немного снизится вероятность, что их будут использовать для зомбирования клиентов. А во-вторых (и это наверно главное), если Вы знаете действительно интересные примеры / расчёты, делитесь. Потому что такая информация вообще на вес золота.

Речь идёт об автоматическом распределении работ (в виде заявок пользователей, заданий и так далее) по различным группам и специалистам. Как обычно, пост создан по следам недавних дискуссий с заказчиками. Мой тезис прост – не все автоназначения, как и йогурты, одинаково полезны. То есть всё не так однозначно. Чтобы разобраться, начать надо со следующего: большинство продуктов различают два вида назначений – на группы и на специалистов (персональные назначения в пределах групп).

С назначениями на группы по-моему всё просто. Большинство продуктов умеют выполнять назначение на группы автоматически. По различным критериям – классификация обращения / задания, заказчик, регион и так далее. Мне кажется, это полезный механизм – он помогает сократить время обработки за счёт сокращения ошибок при выборе ответственной группы. Сокращаются также и непроизводственные трудозатраты, поскольку специалистам «на вход» попадает меньше непрофильных задач.

А вот с персональными назначениями в пределах группы всё сложнее. Для автоматизации персональных назначений обычно используется один из трёх алгоритмов (или их комбинация):

1. Циклический (round-robin). Задачи назначаются на членов группы по очереди: Пете, Диме, Васе, Пете, Диме, Васе и так далее.
2. Выравнивание нагрузки. Задачи распределяются так, чтобы на каждом члене группы было одинаковое число открытых задач. То есть если на мне «висит» 5 задач, а на моём коллеге 6, новая задача будет назначена мне (не зависимо от очерёдности).
3. Профилирование нагрузки. Задачи распределяются так, чтобы количество открытых задач на каждом члене группы было пропорционально некоторым весам (например, отражающим уровень компетенции или целевой уровень загрузки оперативными задачами). Так, если на мне «висит» 5 задач и мой весовой коэффициент 1, а на моём коллеге «висит» 6 задач и его весовой коэффициент 2, новая задача будет назначена моему коллеге (не зависимо от очерёдности).

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

1. Ни один из приведённых алгоритмов не принимает во внимание сложность задачи. Тот факт, что на мне 2 задачи, а на моём коллеге 5, ещё не означает, что я быстрее освобожусь или меньше загружен. Это существенно зависит от задач.
2. Все приведённые алгоритмы существенно зависят от точности учёта недоступности специалистов (ведь если специалист недоступен, оперативность реакции на назначенные задачи будет низкой). И если с длительными отсутствиями (отпуск, командировка, болезнь) это вопрос вполне решаем, то с кратковременным отсутствием (визит к заказчику, совещание, обед) всё гораздо хуже.
3. Циклический алгоритм, помимо минусов 1-2, абсолютно игнорирует различия в компетенции персонала.
4. Алгоритмы с выравниванием и профилированием нагрузки, помимо минусов 1-2, узаконивают процветание принципа «дурака работа любит». Чем быстрее вы выполняете работу, тем больше вас будут грузить. И пусть ваши коллеги отдохнут.

В качестве краткого вывода могу сказать, что если автоматическое назначение на группы как правило сокращает время обработки, то автоматическое назначение в пределах групп напротив – в большинстве случаев увеличивает время обработки (за исключением самых простых сценариев с одинаковыми сотрудниками и потоком однотипных задач, например маршрутизация звонков в call-центре), то есть ведёт к обратному эффекту.

На мой взгляд, распределение задач между членами группы – обязанность руководителя и неотъемлемая часть его работы. Это совсем не значит, что он будет вручную распределять все задачи. Это значит, что он должен так организовать работу, чтобы они распределялись правильно (для этого есть вполне отработанные подходы). Более того, разумное участие линейного менеджера в распределении задач – необходимая мера для совмещения оперативной работы с плановой / проектной работой. Стимулировать линейного менеджера выполнять свою работу в данном случае также достаточно просто – достаточно включить в оценку его работы метрики по своевременной реакции на поступающие задачи и их своевременному выполнению.

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

Уже давно бродит эта тема. А последней каплей стало то, что за последние 2-3 недели я обсуждал её 3 (!) раза с разными людьми. И так, вопрос: «Насколько осмысленно (или в каких случаях) выделять обработку сервисных запросов и управление инцидентами в отдельные процессы»?

За:

• Соответствие ITIL v3. Строго говоря, тут надо учесть, что понятие «процесс» в ITIL v3 используется довольно неоднозначно. Но средства автоматизации ITSM-процессов «меряются» количеством процессов, а значит для вендоров – это плюс.
• И раз уж заговорили про вендоров ITSM-продуктов, надо упомянуть, что такое деление (на инциденты и сервисные запросы) стимулируется рядом программных продуктов, в которых сервисные запросы и инциденты – это не просто разные категории одного объекта, а просто-таки разные объекты (с весьма различными возможностями по обработке).

Видимо, отсюда песня и пошла в народ. Но рассмотрим также и …

Против:

• Рациональность организации управления. О чём, кстати, говорится в ITIL v2: «A request for new or additional service (i.e. software or hardware) is often not regarded as an Incident but as a Request for change (RFC). However, practice shows that handling of both failures in the infrastructure and of service requests are similar, and both are therefore included in the definition and scope of the process of Incident Management.». И в самом деле, зачем выделять отдельный процесс, который будет заниматься практически тем же, чем уже занимается управление инцидентами?
• Устранение вероятных конфликтов. На практике (в проектах) граница между инцидентом и сервисным запросом вызывает массу вопросов. Обычно они выливаются в дискуссии типа «А замена картриджа принтера? А сброс забытого пароля?» и так далее. Логично предположить, что путаются не только «идеологи», но и специалисты при исполнении процесса. А значит должна быть возможность переклассификации. Но если сервисный запрос и инцидент теперь принадлежат к разным процессам управления (и не дай Бог, эти процессы управляются разными менеджерами), вопрос «что это – инцидент или сервисный запрос» превращается в вопрос «кто за это отвечает». И это не на пользу.
• Рациональность автоматизации. В моей практике разница в обработке инцидента, поданного пользователем, и запроса, поданного пользователем, не так велика, как разница между инфраструктурным инцидентом и обращением пользователя (тут и разная классификация, и разные процедуры выявления / регистрации, и разные процедуры закрытия). То есть деление, выполненное в HP OpenView Service Desk, мне кажется гораздо более разумным, чем деление, например, в HP SM или в BMC Remedy ITSM Suite. Это конечно тема смежная, поскольку декомпозиция объектов в модели данных ITSM-продукта может не иметь никакого отношения к декомпозиции процессов управления. ... но всё же

Выводы делаем сами. Ну и спорим, естественно.

P.S. Хотя меня конечно так и подмывает закончить известным «Никто не сказал ни слова, выводы были ясны». © БГ.

Конечно они повсюду, спору нет. Но, как обычно, медленнее всего меняются головы, а не технологии.

И вот вам пример. На конференциях 12.05 и 19.05 мы (компания Cleverics) предлагали посетителям приобрести наши книги «Реальный ITSM» и «Овладевая ITIL». Оплата – здесь же через наш интернет-магазин (карточки, мобильный, электронные деньги и проч.) и сразу получаешь книгу, прямо в руки. Очень многие подходили, и интересовались, и хотели купить. Но за наличные. За две конференции банковской картой для оплаты воспользовались только 2 (два) человека. И это при том, что посетителями обоих мероприятий были в основном люди, нечуждые ИТ.

Участвовал вчера в конференции OSP «Стратегическое управление ИТ». Обо всём мероприятии не скажу, а финальная дискуссия удивила. Может быть мне показалось, но я услышал в речах собравшихся следующее: «ИТ обеспечивают конкурентные преимущества бизнесу, поэтому стратегия в области ИТ для бизнеса является важной задачей».

Я не во всём согласен с Н. Карром, но всё-таки думаю, что для большинства компаний ИТ конкурентные преимущества не предоставляют. Скорее верно утверждение: ИТ обеспечивают возможность не отставать от конкурентов, находиться на уровне «хороших» практик. По крайней мере, в настоящее время я не знаю ни одной компании (кроме, может быть, лишь непосредственно ИТ-компаний), которой ИТ-решения обеспечивали бы конкурентные преимущества. А где искать в первую очередь – понятно: банки, страхование, инвестиционный бизнес, телеком. Пожалуй, ритейл. Кстати, немного наврал – в инвестиционном бизнесе мне один такой пример известен. Но «один» для обсуждения явления как-то маловато.

Более того, весьма распространено обратное явление – борьба за сокращение ИТ-затрат и ИТ-рисков. Это не совместимо с картиной, в которой ИТ являются фактором конкурентных преимуществ. Ведь конкурентное преимущество это то, чего пока нет у конкурентов. Это «что-то» требует исследований, инноваций. То есть проб и ошибок. А это конечно и деньги, и риски. Сокращение же затрат и рисков ведёт к унификации применяемых решений, то есть не к конкурентным преимуществам, а к выравниванию со среднеотраслевой практикой.

Короче, мне показалось, что в этой финальной дискуссии желаемое выдавалось за действительное. Потом в финале ещё алкоголь подарили двум участникам. Так и закончим тостом: «Выпьем за то, чтобы наши желания всегда совпадали с нашими возможностями». Аминь.

Учитесь формировать заголовки, господа. Например, новости на cnews. Открываю список новостей, читаю: «Рейтинг стран по использованию ИКТ: Россия поднялась на 3-е место». Удивляюсь (долго искал этот приличный вариант слова). Открываю новость. Читаю: «Россия поднялась с пятого на третье место среди стран с ресурсно-ориентированной экономикой в рейтинге по эффективному использованию ИКТ». Это другое дело. Далее смотрю цифры и все окончательно становится на свои места: Малайзия, Чили и потом сразу Россия. То есть, как ни крути – мы в тройке лидеров!

Учитесь формировать заголовки

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

Со мной приключилась история. Я нахожусь в отпуске, в другом городе. Поскольку планировал много разъезжать, взял в прокат машину. Перед тем, как отдавать, её, конечно, надо помыть и заправить. Опуская детали, скажу, что я заправил арендованную машину с бензиновым двигателем дизельным топливом. Вот такой дятел, никак по-другому и не скажешь.

Звоню в прокат автомобилей, объясняю ситуацию. И вот тут наступает момент истины. Я много раз сталкивался с тем, что как только что-то идёт не так, компании «теряют лицо» – начинают невежливо или просто неприветливо обращаться с клиентом, всячески дают ему понять, что он создал компании проблемы, «угрожают» финансовыми последствиями и так далее. Если обычная работа с компанией позволяет оценить её технологию продаж и оказания услуг, то работа с той же компанией в нештатной ситуации – её отношение к клиенту. Для компаний, занятых оказанием услуг, это очень важный момент, который даёт возможность получить по-настоящему лояльного клиента.

И так, звоню в прокат автомобилей, объясняю ситуацию. Со мной вежливы, открыты, слушают меня, считаются с моими планами (а мне надо улетать и быстрее сдавать машину). И если всё закончится хорошо, то я совершенно точно вернусь в эту компанию за следующей арендованной машиной. К сожалению, так умеют очень немногие.

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

P.S. Впрочем, посмотрим, чем вся эта история закончится. Пока до финала ещё далеко.

Здесь уже несколько раз поднималась тема "А как у них" (в смысле за рубежом). Сейчас довольно много приходится работать в контакте с немцами. Вот личные впечатления человека "оттуда" (не статистика, не аналитика, а именно личные впечатления):

• в России на то же количество бизнес-пользователей в среднем приходится большее число ИТ-специалистов. Причина — зарубежные коллеги активнее используют различные формы аутсорсинга.
• при приобретении программных продуктов "мы" больше думаем о сокращении стоимости покупки (выторговывая скидки), "они" — больше про сокращение TCO. Во многих случаях вопрос TCO "нашими" не задается и не изучается. Для зарубежных коллег это одна из основных причин миграций.

Тема разницы в зрелости управления ранее уже поднималась с другой стороны — то были мои личные впечатления (см. http://www.realitsm.ru/2010/11/trudnosti-perevoda/). Теперь вот получен своего рода "фидбек".

И снова "попаразитирую" на блоге. Коллеги, что-то уже видел этот продукт? Использовал? Анализировал на пригодность для решения реальных задач? Поделитесь впечатлениями, пожалуйста. Почему-то все клиенты, "примерявшие" продукт на себя, выдают не самые восторженные отклики.

Как оказалось, один из моих хороших знакомых, являясь специалистом по HP Service Manager, уже довольно давно ведет тематический блог. Такие "записки с полей". Адрес давать не буду ибо там встречается ненормативная лексика. Я вообще понял так, что это своего рода автопсихотерапия человека, который вынужден выплескивать наболевшее, чтобы как-то продолжать жить

С большим сожалением опуская красочные детали и речевые обороты, суммирую сложности при работе с HPSM следующим образом:

1. Неприличное количество ошибок в интерфейсе и логике приложения
2. Проблемы с русским языком (ошибки в переводе, разные переводы одних и тех же терминов в разных местах)
3. Реальные проблемы с отсутствием контроля ссылочной целостности, к которой клиенты HP имели неосторожность привыкнуть в HP OpenView Service Desk
4. Сложность разработки (разные языки программирования, рады, не допускающие модификации, множество случаев "тронь в одном месте, повалится в других" и так далее)

Тем не менее, клиенты продолжают выбирать и использовать этот продукт. Бренд делает свое дело. Для примера один из наших клиентов сейчас заканчивает миграцию с HP OpenView Service Desk 4.5 на HP Service Manager 7 (не помню, по-моему на 7.10). Миграция началась в августе 2010 года, на дворе апрель.

Не могу не закончить цитатой: "И скажите спасибо НР за увлекательно проведенное время".

Внимательно читаем ISO 20000 и не перестаем удивляться. Часть 2, страница 20, черным по белому: "Targets for resolution should be based on priority." Мне неизвестно, откуда взята эта рекомендация (в ITIL я такого утверждения не помню). И хорошо, что не в первой части стандарта (то есть не требование, а рекомендация).

И так, легенда: срок инцидента должен рассчитываться на основании приоритета.

В моем понимании это — широко распространенное заблуждение и пример серьезного непонимания модели определения приоритета на основании уровня влияния и срочности, описанной в ITIL. По идее приоритезация работ (любых, не только устранения инцидентов) должна способствовать своевременности их исполнения. Однако расчет сроков на основании приоритетов — эту идею "убивает". Подробнее об этом можно почитать здесь: http://www.cleverics.ru/ru/services/omnitracker/180-using-priorities. Таким образом, расчет срока на основании приоритета существенно снижает ценность приоритезации вообще.

К сожалению, многие программные продукты работают именно так — срок рассчитывается по приоритету. Из "молодцов" могу вспомнить только Remedy ITSM Suite. Гибкость продукта такова, что Service targets могут "привязываться" не только к приоритету, но и к уровню влияния, и к другим параметрам (само по себе это, впрочем, ничего не гарантирует, поскольку за выбор правильного способа расчета сроков в данном случае отвечает внедренец). И к сожалению я совсем не помню как этот функционал реализован в Assyst'е. Подскажите, кто знает, пжл.

Освежал сегодня в памяти содержание стандарта ISO 20000. Опять наткнулся на странность, которая меня каждый раз заставляет задуматься — определение релиза. В общем-то, текст стандарта ISO 20000 стройностью и полнотой терминологии никогда не отличался. Например, стандарт с названием "Information technology — Service management" не содержит определения Service. А определения терминов Service desk и Service management и вовсе выглядят комично. Но сейчас не об этом — о релизе.

Определение в стандарте звучит так:

Release — collection of new and/or changed configuration items which are tested and introduced into the live environment together.

Это немного странно. Например потому, что если мы говорим о дельта-релизе, то релиз может превратиться не в набор CI, а в набор изменений в одной CI (вспоминаем, что release unit >= CI).

Глоссарий ITIL хитрее:

Release — a collection of hardware, software, documentation, processes or other components required to implement one or more approved Changes to IT Services.

Тут уже CI к делу не пришьешь — это слово в определении не встречается Но суть по-моему остается — это набор компонентов. С бытовой точки зрения — все ОК. Например, вот релиз ПО. Он состоит из диска с дистрибутивом и пары книжек. Но если мы говорим об определении термина релиз в рамках процесса управления релизами, то мне непонятно, почему бы не дать определение релиза как "Совокупность одного или нескольких изменений, которые тестируются и внедряются в продуктив совместно"? Это определение и точнее (нет проблем с дельта-релизами), и ближе к сущности процесса управления релизами.

Последние две с половиной недели прошли в работах по завершению нового релиза CleverENGINE. Основное новшество — реализован модуль управления изменениями и релизами (предыдущие версии умели все, кроме изменений и релизов). Это оказалось большой работой. Больше, чем я ожидал изначально. Но в итоге сделано все, что запланировано. И я испытываю большую радость и даже немножко горд

Когда я учился на кафедре теоретической физики, был у нас на кафедре один дядечка, который своими руками сделал половину приборов в нашей лаборатории. То есть он ту самую физику, которую мы "слушали и читали", изучал самым непосредственным способом — "своими руками". И сейчас я, неожиданно для себя, почувствовал определенный левел-ап в управлении ИТ-услугами. Когда строишь решение для конечного заказчика, решаешь конкретные задачи, смотришь под определенным углом. Когда строишь решение общее, претендующее на некую толику универсальности, картинка становится более объемной. Более цельной. Такой тренинг "IT service manager своими руками".

Среда реализации — платформа OMNITRACKER. Инструмент, который заставляет очень серьезно относиться к проектированию и проработке архитектуры. Задачей было — найти правильный баланс между функциональностю и гибкостью (для последующих внедрений), увязать между собой опыт, полученный в разных проектах, в разных ситуациях. И при всем этом — не слишком далеко отойти от идеологии HPOVSD, совместимость с которым требуется для обеспечения возможности миграции. Интересная задача.

Многие заложенные в продукт идеи — плод проектной практики. Те же принципы определения приоритетов и сроков, отличающиеся от реализаций в других продуктах, контроль известных ошибок в рамках управления проблемами, логика взаимосвязи изменений и релизов, функционал связей между CI и так далее. Поэтому я надеюсь, что применять это решение в проектах будет относительно легко (поскольку не придется бороться с чужеродной нам логикой, заложенной производителем). Собственно, в 2010 было два внедрения. Подождем новостей в 2011

Тема конечно горячая. Вот и itSMF недавно собирался ее обсуждать (я, к сожалению, не смог принять участие). Насколько я понял из кратких отзывов, основной тезис выступавших — show me the money. Если я не прав, поправьте, пожалуйста. Деньги показать в принципе можно (по крайней мере, иногда есть варианты). Однако с экономическим обоснованием связаны два очень важных фактора, которые, по-моему, осознаются далеко не всеми:

1. Неглавный (и очевидный) — в большинстве случаев явная связь между реорганизацией процессов управления ИТ и прибылью организации отсутствует (это довольно общее утверждение могу четко обосновать, но не здесь и не сейчас). Подчеркну — в большинстве случаев, так как есть исключения (и как они прекрасны!). Неглавным этот пункт я считаю в том числе потому, что ИТ-управленцев он смущает больше, чем их коллег вне сферы ИТ (возможно сказывается превалирующее техническое образование). Действительно, большинство организаций регулярно осуществляют инвестиции, непредвзятая оценка доходности которых вызывает сомнение. Например, организация приобретает представительский автомобиль для директора. Какова доходность такой инвестиции (в сравнении с альтернативами)? Или другой пример — помасштабней — недавний ребрендинг Сбербанка. Как можно более-менее точно предсказать влияние нового зеленого логотипа на доход компании (в сравнении со старым зеленым)? Думаю, никак. В обоих случаях, для оценки делается множество предположений, не всегда самоочевидных. И в обоих случаях руководство принимает решение об инвестициях, подчиняясь не столько методам оценки инвестиционных проектов, сколько внутреннему пониманию их необходимости (оценка скорее всего также делается, но больше "для порядка"). Более того, многие эксперты полагают, что только финансовая оценка деятельности организации ущербна, так как зависит от большого числа внешних факторов (не все из которых поддаются управлению), и упускает из вида внутренние факторы, оказывающие долгосрочное влияние на эффективность и конкурентоспособность. Вывод прост — до начала проекта надо постараться донести до руководства внутреннее ощущение необходимости (выгодности) ITSM. Если вы сможете — и с цифрами будет проще, и в проекте будет меньше рисков.

2. Главный (и чуть менее очевидный). Консалтинговый проект (и ITSM-проект — не исключение) в лучшем случае помогает организации в изменении практики управления, в худшем — заканчивается внедрением специализированного ПО Примем лучший случай — предположим, управленцы теперь лучше умеют ставить некоторые задачи и контролировать их исполнение (например, в части поддержки пользователей). Насколько могут сократиться потери организации от простоев пользователей за счет сокращения времени устранения и количества инцидентов? Но ведь это прежде всего зависит от самих управленцев — какие они поставят цели, например, на ближайший год. Без целепостановки — просто по метрикам — деятельность не улучшается, выгоды не реализуются. Если же цель будет обозначена, на ее основании можно сделать расчет, и успешность проекта будет определяться не абстрактным значением ROI (NPV, IRR, ...), а возможностью организации реализовать поставленные цели (которые ясны заказчику и могут обеспечить определенный финансовый результат). Такой подход к целепостановке все расставляет на свои места. Однако применяется он очень редко (в том числе и потому, что заказчики также боятся брать на себя такую ответственность). Возьмем типичный тендер. Цель проекта в RFP заявляется как "внедрить процесс такой-то", победитель — на 80% определяется ценой (и это при том, что конкурсанты зачастую предлагают совершенно разные услуги, то есть по цене сравниваются, например, продажа паровоза, строительство коттеджа и уборка снега на территории Сибири). Желаете рассчитать экономическую эффективность? Успехов

И, наконец, последнее. Оба перечисленных фактора в равной степени определяются и умением консультантов, и уровнем зрелости заказчика. Давайте взрослеть.

"Попаразитирую" немного, фактически используя блог в качестве форума. Коллеги, поделитесь, пожалуйста, практикой — как у вас (или у ваших заказчиков) организован PIR в управлении изменениями. Как это устроено организационно? Как PIR поддерживает система автоматизации процессов управления услугами? Что в этой практике вам кажется полезной или наоборот — вредно-бесполезным?

Головы здесь порой собираются приличные. У таких и совета не грех попросить

Не верите? Я сам читал: http://www.cnews.ru/news/top/index.shtml?2011/03/02/430392

Удивительная оценка... На этом фоне даже закон о полиции не кажется недоразумением  Вы еще не знаете как измерить эффективность? Вызывайте счетную палату!

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

Идея, вкратце, такова. Есть матрица. По вертикали — функции (отделы, группы, ...), по горизонтали — процессы. Пересечение функции и процесса означает, что данная функция участвует в реализации данного процесса. А это значит, что функциональный руководитель отвечает за предоставление ресурсов, необходимых для реализации процесса. Чтобы стимулировать его содействие процессам и оценивать результаты управления с функциональным руководителем можно связывать процессные метрики его подчиненных, назначать им целевые значения и контролировать соответствие. Важно то, что при этом функциональный руководитель в процессах управления никаких функциональных обязанностей может не иметь (грубо говоря, в матрице RACI он не является R ни за одну из процедур процесса). Такой подход (через метрики) является одним из способов "включения" функциональных руководителей в процессное управление, что очень важно для работы процессов.

При глубокой иерархической структуре или географическом распределении организации этот подход можно использовать на каждом из уровней, агрегируя метрики i-го уровня на уровне i+1. Например, начальник определенной функции на каждой из территорий оценивается по набору процессных метрик подчиненных, начальник соответствующей функции в HQ — по метрикам региональных начальников.

Являясь вполне рабочим, такой подход, однако, требует умелого обращения с метриками. В частности те метрики, которые используются как индикаторы (KPI), должны быть сравниваемы даже в пределах разных процессов (то есть иметь одинаковую шкалу, обычно — от 0 до 1, и одинаковое направление оценки, обычно — чем ближе к 1, тем лучше). Например, по базовым оперативным процессам (управление инцидентами, управление проблемами, управление работами) для начальника отдела можем построить следующий набор метрик (это просто пример, не конечное решение):

1. Доля заданий, выполненных в срок, от общего количества заданий на сотрудников отдела за период (К1).
2. Доля инцидентов, принятых в работу своевременно, от общего количества инцидентов, назначенных на сотрудников отдела за период (К2).
3. Доля инцидентов, решенных в срок и с первой попытки, от общего количества инцидентов, назначенных на сотрудников отдела за период (К3).
4. Коэффициент обновления по проблемам за период, подробнее смотри http://www.realitsm.ru/2010/12/measuring-problem-management (К4).

Итоговый рейтинг руководителя R за период строится из коэффициентов К1-К4 любой приемлемой математикой (арифметическое среднее, геометрическое среднее, взвешенное среднее, среднее по доле от целевых значений — кому как нравится). Аналогично из итоговых рейтингов R функциональных руководителей на площадках рассчитывается итоговый рейтинг их общего руководителя в HQ. И так далее.

Сам по себе подход не нов. Более того — не имеет никакой "ИТ-шной" специфики (что хорошо, так как означает использование общих практик менеджмента в ИТ, что понятней "не ИТ-шному" руководству). Тем не менее, в ходе обсуждений, выяснилось, что его осознают и применяют не все. Поэтому и пишу. Мнения приветствуются.