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

Поэтому в ответ на вопрос "вы следуете регламенту [название]", получаю ответы: "да, но только вот тут и вот тут мы уже работаем иначе", "нет, не следуем, документ далек от практики" и т.д.

Практика показывает, что наиболее распространенные причины кроются в том, что:

1. Непонятна цель создания документа. 
2. Непонятны потребители документа.
3. Документ разработан одним-двумя сотрудниками без вовлечения в разработку всех заинтересованных лиц.
4. Документ не прошел согласование и ему не придан статус официального.

Список причин конечно можно продолжать: 

1. Не зафиксирован ответственный за обновление документа.
2. Нет триггеров и процедуры обновления документа.
3. Участники регламентируемой деятельности не информированы о существовании документа.
4. Доступ к документу затруднен.
5. Отсутствует контроль за соблюдением положений документа.

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

1. Стоит определить цель создания документа и его потребителей. Например, если вам необходимо обеспечить единообразное выполнение процедур всеми участниками процесса, то вряд ли им стоит давать в руки пятидесятистраничное описание процесса, а вот краткая ролевая инструкция подойдет, если ее структура позволит быстро найти описание необходимых действий. 
2. В разработку документа или его согласование необходимо вовлечь ключевых специалистов, которые смогут внести в документ специфику той области в которой они работают, оценить реалистичность описываемых действий и скорректировать документ так, чтобы его требования были выполнимы.
3. Разработанный документ должен быть утвержден на уровне руководства и доведен до сведения сотрудников как обязательный к исполнению.
4. Должен быть определен порядок обновления документа и ответственный за его обновление.

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

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

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

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

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

На днях закинули в CleverTEST очередной пробный экзамен по ITIL, пока кидали, на глаза попался вопрос:

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

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

Вспомнился недавний разговор с одним знакомым, который жаловался на несовершенство используемой им системы мониторинга, "которая заваливает их спамом, а толку никакого".

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

• понимаем кто потребитель информации
• понимаем его требования
• строим модель данных
• данные собираем
• периодически оцениваем полезность данных и пересматриваем модель данных.

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

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

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

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

Недавно, улетая в командировку, решил довериться современным информационным технологиям, а именно — пройти электронную регистрацию на рейс, распечатать посадочный талон и не стоять в очереди. Тем самым я должен был сэкономить минут 20 времени. Заказав такси с учетом этой экономии я приступил к регистрации. Подумав некоторое время, сайт авиакомпании выдал заключение "Ваш билет в порядке, но приезжайте в аэропорт и регистрируйтесь обычным способом". "Ничего", подумал я. Есть еще электронные шайтан-машины, которые стоят в аэропорту и тоже умеют регистрировать быстро и без очереди. В общем, в этот день что-то не задалось в электронных мозгах системы регистрации, т.к. шайтан-машины тоже не смогли мне помочь.

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

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

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

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

С точки зрения теории можно сколько угодно долго рассуждать на тему: в чьей области ответственности находится контроль выполнения всех мероприятий в момент передачи в эксплуатацию. На практике же ситуацию спасает только возведение мероприятий, которые должны быть выполнены до передачи в эксплуатацию в ранг ОБЯЗАТЕЛЬНЫХ требований, ничем не отличающихся от функциональных требований к системам, без реализации которых эксплуатация просто не может начаться. Ведь закладываются же на начальном этапе планирования проекта сроки на реализацию функционала, почему не заложить туда же дополнительные дни и трудозатраты на подготовку системы. Принцип, "главное взлететь, а как потом садиться будем, разберемся по ходу полета", не только с самолетами не доводит до добра

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

У меня родился типично-пятничный пост. В одном из недавних проектов столкнулись с чисто технической проблемой — нежеланием Internet Explorer 6 работать в своем основном качестве (в качестве браузера). Начали разбираться, оказалось, что версия давно уже признана неудачной даже самим производителем. И, видимо, для того чтобы снизить поток обращений за поддержкой, а так же очистить свою карму от проклятий, производитель запустил удивительный сайт "The Internet Explorer 6 Countdown" со слоганом "Moving the world off Internet Explorer 6".

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

Думаете, это чья-то шутка? Домен зарегистрирован на компанию microsoft. Вот выдержка из who-is:

OrgName: Microsoft Corp
OrgId: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 1998-07-10
Updated: 2011-04-26

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

Тема отказа от устаревших продуктов в компании скорее всего будет не актуальна, т.к. переход редко когда выполняется на добровольной основе — все делается централизованно. А вот тема "Вы все еще делаете эти глупые ошибки?" вполне может быть интересна, тем более с рейтингом "ТОП-10 отделов с самыми часто звонящими по глупостям пользователями".

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

... тяжеловесный конфиг, пожирающий массу ресурсов, мог быть реализован в виде пары процедур в процессе управления изменениями и в процессе «Контроля и оценки», плюс разовый проект по созданию CMDB. А вы как думаете?;)

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

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

2. Важен контроль соответствия CMDB потребностям, информации должны доверять, а для этого необходим контроль не только наполненности CMDВ, но и соблюдения установленных правил учета. Т.к. нам важно наличие достоверной информации в CMDB, на основании которой можно принимать решения, а не просто знать, что "что-то там написано по этому поводу, но лучше проверить". Поэтому контроль соблюдения процедур процесса, правил учета очень важен. Именно поэтому я обычно рекомендую ограничивать круг лиц, которые имеют возможность обновления CMDB. Т.к. обучить и проконтролировать работу 5 человек проще, чем 150.

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

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

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

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

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

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

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

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

Мыслей по этому поводу конечно же еще вагон. Но с этих, мне кажется, стоит начать. Если не согласны, то готов обсуждать.

Предлагаю отвлечься от великих теорий, суровых практик и немного поразвлечься. Вам никогда не приходилось делать ремонт в старой квартире? Настолько старой, что обои в ней наклеены на газеты. И газеты те 50x-60x годов. Мне вот приходилось, и я с удовольствием читал обрывки статей и удивлялся как сильно меняются приоритеты в некоторых областях (например, политика, наука и т.д.) и насколько неотличимы новости 50летней давности от современных в других областях (спорт, например).

Идею с газетами оказалось легко реализовать на всеми нами любимом портале http://www.itsmportal.com. Отмотав на начало ленты новостей, я начал читать анонсы.

• Некоторые новости вызывали радость узнавания, например: 24/09/2002 BMC buys Remedy from Peregrine.
• Некоторые — улыбку: 06/11/2002 IT Service Management: what's it good for? с анонсом "В США и Канаде просыпается интерес к Управлению ИТ-сервисами.".
• Другие — приятные воспоминания: 15/01/2003 New qualification in IT Service Management.

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

В общем, если есть лишняя минутка времени, то есть шанс посмотреть как все расло, изменялось и развивалось.

Коллеги, который раз сталкиваюсь с необходимостью проектирования процессов "верхнего уровня" (иногда их называют тактическими процессами): управление мощностями, доступностью и т.д.  Занятие это весьма интересное и сильно зависящее от конкретной ситуации в компании. Мне видится два подхода:

• Сделать процесс в рамках которого осуществляются все активности связанные с соответствующими параметрами ИТ-услуг.

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

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

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

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

Не секрет, что некоторые магазины (от автосалонов до магазинов бытовой техники) любят навязывать сервис со словами "купили у нас, значит надо устанавливать/обслуживать тоже у нас, иначе потеряете гарантию". Недавно столкнулся с подобной ситуацией, при этом стоимость навязываемого сервиса составила 70% от стоимости товара. Естественно "грабители с большой дороги" остались ни с чем и товар был приобретен в другом месте.

Но закралась мысль о том, как часто бизнесу приходится сталкиваться с ситуацией, когда у них нет другой альтернативы. ИТ работает плохо, кушает много, но отказаться от них невозможно, т.к. они — какая-никакая, а кладезь знаний об инфраструктуре, ИТ-системах и т.д. и если их разогнать, то высоки риски полной остановки бизнеса. Поэтому переключение на другую ИТ-команду, внешнюю или новую внутреннюю, мне кажется весьма трудоемкой задачей, подготовка к которой должна начинаться задолго до перехода. Является ли стандартизация ИТ-процессов шагом на этом пути? Какие еще шаги необходимо предпринять?

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

Недавнее общение с представителями сервисной организации натолкнуло на следующие размышления. 

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

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

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

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

• получить ПК на складе — 2 часа
• установить ОС — 1 час
• установить прикладное ПО — 1 час
• установить ПК пользователю — 1 час

затем составляем из мелких работ смету на решение задачи, например, установка нового рабочего места. Это способ тоже прекрасен, но:

1. Таким образом мы получаем плановые трудозатраты, которые могут отличаться от фактических. Например, ПК может не оказаться на складе, ОС не поставилась с первого раза, у пользователя не оказалось свободной розетки и пришлось еще идти за удлиннителем.
2. Составить, а потом еще и поддерживать в актуальном состоянии свод всех атомарных работ, из которых потом можно будет компоновать любые другие, — это, мне кажется, отдельная весьма и весьма трудоемкая задача, у строителей ей занимаются целые институты.
3. Как быть с такими "творческими" работами, как диагностика и поиск решения инцидентов? Для запросов на обслуживание такой подход еще может быть оправданным, а вот там, где последовательность и объем работ нельзя заранее спрогнозировать, есть риск сильно ошибиться. Не будем же мы вводить нормативы "думать 2 часа, что придумаем за это время, то и будем использовать".

Что в итоге? Вообще не учитывать трудозатраты? 

Мне кажется, что учитывать стоит, но вручную. Если у сотрудников есть необходимость отчитываться о выполненных работах, то указание трудозатрат для них не составит труда. Это требует определенно дисциплины, но в конечном итоге является делом привычки. При этом конечным потребителям этом информации необходимо понимать степень достоверности этой информации. Опытный руководитель всегда распознает приписки в отчете "перетрудившегося" сотрудника. 

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

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

Как и любому человеку, имеющему отношение к ИТ, мне не чуждо чувство любопытства, которое начинаешь испытывать при виде окна с сообщением об ошибке. Особенно если это окно обнаруживается в неожиданном месте. Например, на мониторе рекламной стойки. Следует отметить, что рекламные ролики при этом продолжали крутиться, но на 60% они были перекрыты данным окном. Почитав надписи в окне, гласившие о сбое в какой-то библиотеке, я уехал, не придав этому значения.

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

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

Чего не хватило для того, чтобы подобной ситуации не произошло? 

Как мне кажется, довольно простой вещи: есть основное назначение ИТ-сервиса — показывать рекламу и именно этот параметр либо не отслеживался, либо игнорировался. Бизнесу не важно, работают ли сервера, запущены ли программы (как мы видим, в этом случае все работало, но результат работы был странным, явно не тем, который ожидал рекламодатель).

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

Если отойти от примера с рекламой, есть ли аналогии в ИТ? Полно. Опять же пример из жизни. Банальная электрическая почта. ИТ обещает бизнесу, что почта будет работать. Обещает, что отправка сообщений будет происходить моментально. Так и происходит — когда пользователь нажимает "отправить", почта от него моментально уходит. Только до адресата она идет 8 часов. С почтой все просто, если общение активное, то рано или поздно пользователи от своих получателей узнают, что почта ходит слишком долго.

А как быть с другими параметрами, которые не так явно могут быть отслежены пользователями? 

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

И с этой проблемой можно встретиться не только у нас в России  

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

В продолжение темы "Гнусная ложь и статистика". Недавно наткнулся на отчет компании Dimentional Research, в котором сравнивались два монстра автоматизации ITSM процессов. Умышленно не буду их называть, т.к. не в этом суть, да и рассматриваемые в отчете версии не самые последние, так что если захотите, то найти отчет не сложно. Меня поразил подход к сравнению. Приведу пример, в отчете есть две фразы:

Продукт №1: A simple notification e-mail took four weeks to implement.
Продукт №2: A simple notification e-mail was implemented in the XXXXX product in two days. 

Если исследователи хотели этими фактами привлечь меня к одному из продуктов, то им это не очень удалось, т.к. есть продукты, в которых "simple notification", как я это понимаю, реализуется за 15 минут. А вообще конечно "интересный подход", сравнивать трудозатраты на решение задачи, которая толком не поставлена: что такое "simple notification" — непонятно.  

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

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

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

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

А вы что думаете?

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

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

Пока сдавал вспомнился экзамен IPRC, он тоже заставлял задуматься и после окончания экзамена еще долго думалось, а как же все-таки правильно  

Если кто собрался сдавать, то с примерами экзаменов можно познакомиться вот тут: http://www.cleverics.ru/ru/tests

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

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

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

И ведь не побоялись гнева пользователей (водителей) и сложности сопровождения и всего остального

Не знаю как Вам, но мне такое чудо больше не попадалось.

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

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

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

Шутки шутками, но в некоторых ситуациях подобный инструмент и правда может быть полезен. Кстати, речь не идет о публичных социальных сетях. можно ограничиться корпоративной, например на базе бесплатного: https://www.yammer.com/

Многие компании освоив первый столп ITIL — процессный подход начинают задумывать о втором — сервисном подходе.

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

Можно ли про такие компании сказать, что у них работает сервисный подход или чего-то не хватает? 

Интересно было бы узнать Ваше мнение по вопросу: что является неотъемлемой частью сервисного подхода? Не по книжке, а в реальном ITSM.

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

Как показывает практика, негативное отношение, часто связано с:

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

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

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

Мне кажется, что важны следующие моменты:

1. Необходимо объяснять сотрудникам, руководителям, менеджерам роль метрик в управлении процессами. Упрощенно говоря, нарушение целевых значений метрик, это прежде всего повод разобраться в причинах, не всегда нарушение это вина специалиста, возможно требуется внести корректировки в процесс, обучить пользователей, нанять дополнительных ИТ-специалистов и т.д.
2. Не стоит торопиться с использованием метрик в схемах мотивации, пусть процесс поработает и люди привыкнут к своим новым обязанностям, а заодно станет понятно, что такое хорошо, а что такое плохо (пороговые значения метрик).
3. Метрики нужно придумывать так, чтобы влияние "специальных действий" специалиста было минимальным. В некоторых случаях это невозможно, тогда необходимо определиться какие еще есть индикаторы, которые позволят увидеть истинное положение дел.
4. Не нужно бояться использования неавтоматических методов сбора данных для метрик: опросы, анкетирование пользователей и т.д. могут дать более объективную картину, чем данные из системы автоматизации.

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

В рамках мастер-класса предполагается рассмотреть следующие вопросы:

• Цели и задачи автоматизации
  • структура системы автоматизации
• Определение требований к системе автоматизации
  • классификация требований
  • практика формирования требований
  • подход к автоматизации
• Выбор системы автоматизации
  • формирование списка кандидатов
  • формирование критериев выбора
  • гибкость
  • базовая общепринятая функциональность
  • готовая автоматизация процессов
  • поддержка
  • стоимость
• Миграция

Продолжительность мастер-класса 4 часа. 

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

Желающие могут зарегистрироваться по телефону: +7 (910) 44-12-789

или E-mail: m.kolesnikova@cleverics.ru

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

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

Ниже привожу тоже самое, но в текстовом виде.

Для примера предлагаю рассмотреть следующую схему:

1. Есть ИТ-сервис (например, электронная почта)
2. ИТ-сервис зависит от работы ИТ-системы (например, "Почтовый сервер")
3. ИТ-система установлена на сервер 
4. Теперь представим, что ИТ-системы две и они располагаются на двух серверах, при этом сервера расположены на разных площадках.
5. При этом, для нормальной работы ИТ-сервиса необходимо, чтобы ИТ-системы обменивались данными.
6. Т.к. сервера, на которых стоят ИТ-системы, расположены на разных площадках, то для работы ИТ-сервиса важно, чтобы работала связь между площадками.

Вопрос: как отразить эту зависимость ИТ-сервиса от канала связи?

Вариантов несколько:

1. Напрямую связать ИТ-сервис и канал связи. Не нравится, т.к. таких компонентов будет много и ясности картинке это не добавит. Мы получим ИТ-сервис, связанный напрямую с кучей ресурсов, что не только ненаглядно, но и трудоемко в актуализации. Нам придется каждый чих в инфраструктуре отражать в связях ИТ-сервиса (если есть детальная спецификация, то и в ней).
2. Сказать, что канал связи влияет на работу ИТ-систем и как следствие на ИТ-сервис. Не нравится, т.к. это не всегда будет соответствовать действительности. ИТ-системы могут прекрасно продолжать работать и без канала связи, но при этом ИТ-сервис будет предоставляться со сниженным качеством, причем снижение качества может стать заметно очень не сразу.
3. Ввести некую несуществующую конфигурационную единицу "App. Data Exchange", которую связать с каналом, сетевым оборудованием и остальными компонентами, которые будут необходимы для обмена данными между ИТ-системами. И уже ее связать с ИТ-сервисом.

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

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

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

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

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

Единственное, что мне кажется допустимым, это единая система хранения информации.

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

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

В одном из проектов решали такую задачку. Есть две метрики: "Доступность первой линии" и "Количество обращений пользователей решенных на первой линии". Понятно, что улучшение показателей по первой метрике, с учетом ограниченности ресурсов, ведет к ухудшению показателей по второй метрике. В терминах ITIL V3, это Tension Metrics (в русском глоссарии Сопряженные метрики). В итоге волевым решением выбирали, что для нас более важно и насколько мы готовы ухудшить показатели второй метрики. Таким образом, получили приемлемое значение первой метрики, но при этом не гнались за идеальным значением, понимая, что это приведет к совершенно недопустимым значениям второй метрики. 

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

А вы что думаете? Может у кого есть еще интересные примеры?

Тема для обсуждения предложена читателем нашего портала. (См. раздел "Задать вопрос").

"Как с помощью ITSM-процессов улучшить качество ИТ-услуг? Есть несколько процессов. Все эти процессы, конечно, косвенно влияют на качество сервисов, инциденты решаются своевременно, проблемы не остаются без внимания, изменения не приводят к новым инцидентам. Однако, если взглянуть на статистику, то оказывается, что количество инцидентов не только не уменьшается, но даже потихоньку растет, соответственно можно сказать, что качество сервисов по основному показателю ухудшается. Корень проблемы видится в том, что имеющиеся метрики и построенная на них система мотивации нацелены исключительно на качество работы процессов (своевременная и упорядоченная обработка инцидентов, проблем и т.п.). В итоге получился скорее менеджмент ITIL-процессов, а не сервисов, так как за сами сервисы никто как бы и не отвечает."

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

С ИТ-сервисами примерно такая же история. Говорить о снижении качества ИТ-сервиса мы сможем после того как определим показатели, по которым мы этот сервис оцениваем, и зафиксируем ожидания от значений этих показателей. Например, по ИТ-сервису "Электронная почта" важен показатель доступность. Определим его целевое значение как 95%. Тогда сможем говорить, что в декабре доступность была 98%, а в ноябре 80%, значит в декабре ИТ-сервис был качественным, а в ноябре нет. Естественно возникает вопрос, откуда мы возьмем перечень показателей и их целевые значения. Ответ в разных ситуациях может быть разным, например, это может быть процесс SLM или некая деятельность на него похожая. В идеале, показатели и их целевые значения должны исходить от потребителей.

Поэтому в отношении такого показателя как "количество инцидентов" возникает вопрос, интересен ли он потребителям? Скорее всего нет, ведь 2 крупных инцидента за месяц могут остановить работу ИТ-сервиса на более продолжительное время, чем 10 мелких. К тому же рост числа инцидентов может быть продиктован объективными причинами, которые не связаны с качеством ИТ-сервиса. Например, выросло число пользователей, многие из которых видят ИТ-систему впервые, или вышло обновление ИТ-системы и пользователям стали доступны новые функции. 

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

1. Поняли какие ИТ-сервисы мы предоставляем (например, "Электронная почтв").
2. Поняли какие параметры ИТ-сервисов важны заказчикам (например, "Доступность").
3. Поняли как на эти параметры можно повлиять (например, обработка обращений пользователей, контроль компонент инфраструктуры, аккуратное изменение инфраструктуры и т.д.).
4. Поняли как организовать свою деятельность (например, в виде процессов управления инцидентам, событиями, изменениями) так, чтобы она решала задачи п.3. Деятельность можно выдумывать самостоятельно, а можно обратиться к ITIL, ISO и т.п.

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

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

А вы что думаете?

Компания Prolin сдержала свое слово (см. "Прародители HP OV SD могут дать ей второй шанс") и выпустила продукт под названием Power Server, который вместе с выпущенным ранее Smart Client 10, призван заменить HP OV SD 4.5. По словам производителя, продукты построены на базе современных технологий, что дает прирост производительности по сравнению с HP OV SD 4.5, при этом клиент обладает некоторыми возможностями, которых не было в HP OV SD 4.5. Кроме того, Power Server может работать параллельно с HP OV SD Application Server, что позволяет произвести переход постепенно, с минимальными рисками.

Для компаний, которым полюбилась старая-добрая и такая родная HP OV SD, это шанс сохранить сделанные ранее инвестиции в автоматизацию процессов, обучение людей и т.д.

В продолжение темы. Чат, как средство контакта встречал, но редко, а вот другие менее экзотичные способы попадаются чаще, но тем не менее в каждом случае ответ на вопрос "что использовать?" не всегда однозначен.

Начну издалека. На днях общался с оператором интернет магазина. Разговор состоялся примерно следующий:

— Добрый день, я хотел бы заказать ГРАВИЦАПУ ГТВ-4. Скажите, сколько она у вас стоит и как быстро вы сможете ее доставить?
 — Все написано на сайте
 — На сайте указано "уточните у менеджера" и ваш телефон.
 — Если все будут мне звонить, и каждому я буду все объяснять, мы ничего не продадим, напишите мне по почте, адрес на сайте, как освобожусь — отвечу.

Очень все это напоминает первую линию поддержки и способы обращения на нее. Обычно это именно: телефон, e-mail, веб-портал.

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

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

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

А что вы думаете по этому поводу?

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

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

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

"Есть возможность смотреть журналы", — скажете вы. Теперь представьте, что в нашем примере обращений сотни, смотреть журналы вы замучаетесь.

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

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

Если вы ответили: "конечно да, без них никак", то скажите мне, как вы обеспечите корректность таких данных? Можно ли принимать решение на основании таких данных?

На днях опять вспомнилась тема управления мощностями. Столько всего понакручено вокруг нее. Решил немного про это порассуждать.

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

1. Откуда взяться требованиям к мониторингу? 
2. Откуда взяться пороговым значениям?
3. Как реагировать? Что значит для нас превышение того или иного порога?

Бывает, что на эти вопросы отвечают так (конечно утрирую): "собираем все важное, пороги поставили разумные, если жахнет, то разберемся".

При таком подходе, есть риски:

1. За грудой данных не увидеть опасной тенденции или значений характеристик ресурсов.
2. Вообще не следить за теми параметрами, которые важны, т.к. про них не подумали.
3. Не понять, что собираемые данные иллюстрируют поведение не совместимое с требованиями к ресурсам.

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

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

Про цепочку из теории BCM — SCM — RCM (business — service — resource capacity management) все слышали и знают. Но вот на практике эта цепочка выстраивается с бооольшим трудом. Построить сервисно-ресурсную модель связей между сервисами и ресурсами типа "Сервер используется для предоставления сервиса" конечно можно и многие вполне успешно это делают. Но для мощностей этого мало, необходимо понять, как изменение характеристик ИТ-сервиса (например, количество пользователей, или объем оформляемых документов) влияет на загрузку ресурсов. Очень редко можно с уверенностью сказать, что каждая 1000 пользователей, это 100мб места на жестком диске в неделю и 10% средней загрузки процессора. Часто на помощь приходит наблюдение на трендами по характеристикам ИТ-сервиса и ИТ-ресурсов, для выявления корреляции. Иногда выручают производители ПО, которые предоставляют Sizing модели, которые позволяют по нескольким входным параметрам определить требования к ресурсам. Ну и последнее, даже определив взаимосвязь характеристик остается еще наладить отношения с бизнесом, для того чтобы они заблаговременно предоставляли данные о своих планах, да еще и в терминах характеристик ИТ-сервисов.

Зато если цепочка будет выстроена и каждое звено будет работать, то есть шансы получить те самые преимущества, которые описываются в ITIL. 

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

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

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

Опять послушал производителей ПО (не производители средств автоматизации ITSM процессов), опять много думал: некоторые в своих докладах употребляют слова "сервис", "сервисно-ресурсная модель", и обещают большую красную кнопку в новом продукте, которая "весь этот ITSM сделает за вас и ни о чем не надо будет думать", "при этом повысит эффективность вашей работы на 92%".

Еще недавно в России было не так много средств автоматизации ITSM процессов. Я, например, начинал проектировать процессы имея ввиду, что автоматизировать их придется на HP OV SD. Т.е. процессы конечно же проектировались, и отличались друг от друга, и подгонялись под задачи и возможности заказчика, но все равно на них (на нас при проектировании) давило то, что продукт не многое позволит. И поэтому полет фантазии приходилось загонять в угол и откладывать на потом.

Что мы имеет теперь? Руки развязали, все продукты, по заявлениям производителей, супер-мега-гибкие движки — делай что хочешь, никто тебя не ограничивает. Сбылась мечта, можно доставать из углов идеи для процессов. Вот только надо ли? Стоит ли усложнять процессы дополнительными мульками на все случаи жизни, или остаться в рамках, простых, понятных процедур, которые и без навороченных алгоритмов дадут результат. 

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

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

В общем, для себя я сделал вывод, что руки развязали, но надо держать себя в руках.

Пишу редко, но сегодня появился повод. Вчера вечером смотрел на Яндекс.пробки и пришла в голову мысль: "было бы здорово иметь возможность посмотреть пробки не на текущий момент, а среднестатистические. Например, планируя заказ такси в аэропорт, посмотреть: а какие обычно пробки в это время по пути следования, и исходя из этого, заказать такси немного точнее". Эту мысль я изложил службе поддержки Яндекс, прекрасно понимая, что никто не воскликнет "Гениально!!!, как мы раньше не додумались?!!!". Просто пришла в голову мысль, просто поделился с ними. Сегодня пришел ответ. Все ожидаемо, но мне очень понравилось насколько вежливо сформулирован ответ: "Спасибо, что проявляете интерес к нашей работе. Я обязательно перешлю Ваше предложение менеджеру и разработчикам сервиса, а они, в свою очередь, рассмотрят его самым подробным образом. Мы свяжемся с Вами, если будем готовы реализовать вашу идею или у нас возникнут какие-то вопросы. Ещё раз спасибо!". Молодцы ребята. 

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

В этот момент всегда вспоминаю фильм Матрица и их разъемы в затылках. Когда уже наступит время, когда придуманный процесс достаточно будет прошить исполнителям в мозг и дальше только периодически обновлять прошивки по мере совершенствования процесса? 5 секунд и коронная фраза "Я знаю управление релизами" вылетает из уст очередного участника процесса. Мечта...

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

Компания PROLIN, известная тем, что она стояла у истоков HP OV SD (см. постер "30 лет прогресса в программном обеспечении ITSM"), некоторое время назад объявила о выпуске своего собственного клиента для HP OV SD. На страничке с описанием приводятся 25 улучшений по сравнению с обычным клиентом. Большинство из них просто наведение красоты и изменение интерфейса, но есть и интересные заявления, например "Graphical CMDB view".

Интересен также тот факт, что на форуме itrc.hp.com представители PROLIN заявляют:

«Of course, PROLIN hasn't restarted its business JUST to bring the fun back for OVSD customers, this is just the beginning. We have plans to once again change IT service management with leading-edge tools that improve productivity and drive down costs, especially for existing Service Desk customers.»

Т.е. вполне возможно, скоро мы получим еще один продукт. Поживем, увидим ...

Попались в руки две интересные новости. 

1. Компания Microsoft объявила цены на Microsoft System Center Service Manager 2010. (http://www.microsoft.com/systemcenter/en/us/service-manager/sm-pricing-licensing.aspx)
За 600$ обещают автоматизацию обработки инцидентов, запросов на обслуживание, CMDB, Self-service портал для пользователей, интеграцию с различными продуктами Microsoft и т.д. В руках пока не держал, но судя по описанию, для некоторых компаний, этот продукт может стать неплохим решением. Однако, стоит сразу учесть, что не все так просто, нужен еще SQL Server (его можно купить по специальной программе), если хотите разрабатывать для продукта, то понадобится Visual Studio и т.д.

2. Компания Hewlett Packard выпустила очередное обновление Service Manager. (http://h30501.www3.hp.com/t5/IT-Service-Management-Blog/Introducing-HP-Service-Manager-9-20/ba-p/2081) Теперь его версия 9.20. "Куда делась 8ка?", — спросите вы. Все просто, нумерацию решили привести к единому стандарту и теперь продукты будут выпускаться с единым номером (HP Universal CMDB 9.0, Release Control Analysis 9.0 и т.д.). Специалисты, успевшие установить продукт, не перестают удивляться направлению его развития. 

Например, не укладывается в голове фраза "Customers are excited about this new version of HP SM because it helps IT be more efficient than ever before. "  после того как видишь, что интерфейс форм объектов вместо закладок (так полюбившихся нам в HP OV SD) теперь стал полотенцем на несколько экранов вытянутым в длину с разбивкой по разделам. Причем, в Веб интерфейсе разделы можно сворачивать в одну строку, а в Win32 клиенте способ сворачивания пока не найден (более того, не всем удается воспользоваться колесом мышки для прокрутки формы). Это мелочь, но это очередная, новая мелочь, которых в продукте много и они сильно портят впечатление от хороших идей, которые закладывались в продукт, но так и не были доведены до ума. И мелочи эти не только делают продукт неудобным, но и сильно усложняют автоматизацию процессов. Например, в CMDB есть возможность устанавливать связи между объектами, но на визуализации типы связей не видны, в итоге мелочь превращает схему связей КЕ в бессмысленную паутину. 

Вчера на конференции ITSM-2010 краем уха прислушивался к докладам участников. Меня все время поражает то, как поставщики программных продуктов сравнивают себя друг с другом. Точнее не способ сравнения, а результат. Лучше все время тот, кто выступает Это мне напомнило мою учебу в университете, где преподаватель рассказывал: "Сфера запросто может иметь вид куба, если правильно выбрать способ измерения расстояния между точками". На практике, действительно, довольно сложно сравнить два продукта:

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

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

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

Вот и задумываюсь, что можно сделать для того чтобы менеджер лучше справился с этой задачей. Конечно, сами собой разумеются:

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

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

В итоге, моя практика показывает следующее:

1. Способности человека к управлению и заинтересованность в результате становятся видны на раннем этапе.
2. Если сложно выбрать кандидата на роль менеджера, то деловые игры, типа Аполло 13 могут помочь выявить наиболее подходящих кандидатов и снизить риски на раннем этапе.
3. Работа в проекте с человеком может дать результаты, только если он сам этого хочет. Заставлять бесполезно, лучше заменить менеджера на раннем этапе, чем потом получить неработающий процесс.
4. Управление процессом это тоже серьезная работа и нельзя ее делать по остаточному принципу, чем раньше это поймет сам менеджер и его руководитель, тем лучше.

А вы, что думаете?