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

Давайте задумаемся. Буквально на секунду. Что представляет собой предпроектное обследование? Это, по сути – анализ предметной области (то есть, анализ состояния исследуемого объекта - предприятия, в заданном разрезе, с учетом оговоренных рамок и ограничений) «как есть», с одновременным сбором полезной для проекта информации. Затем – проект, проектирование и реализация «как будет». Так вот, стоит ли проводить это обследование, если заказчик и так знает, что у него происходит? Не уверен.

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

Попробую пояснить на примере. Организация внедряет процесс управления инцидентами, в соответствии с ITIL. Если руководство представляет себе ожидания бизнес-пользователей от внедрения, состояние управления инцидентами в настоящий момент – то предпроектное обследование становится просто ненужным. И имеет смысл лишь сбор информации, относящейся к проекту.

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

Ответы на наиболее часто задаваемые вопросы о том, как внедрять управление ИТ-услугами на основе рекомендаций ITIL

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

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

Библиотека ИТ-инфраструктуры (Information Techno-logy Infrastructure Library, ITIL) – это библиотека рекомендаций, обобщающая международный опыт по организации работы ИТ-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов. В настоящее время выпущена вторая версия ITIL, активно ведется работа над созданием третьей. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.

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

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

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

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

Увеличение эффективности и направление фокуса ИТ-деятельности на решение задач бизнеса.

Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу ИТ-службы таким образом, что в центре ее внимания окажется именно бизнес. ИТ-отдел из «вещи в себе» превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.

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

Дополнительным аргументом может служить ответ на вопрос об окупаемости проекта по внедрению ITSM. Стоимость решения заявки на этапе промышленной эксплуатации решения, состоящего из процессной части и настроенной системы автоматизации в случае, когда внедрена часть процессов ITIL, по сравнению с ситуацией, когда не внедрен ни один из процессов, в пересчете на единицу времени оказывается ниже. Таким образом, окупаемость проекта по внедрению рекомендаций ITSM может быть вычислена для каждой конкретной организации. В простейшем случае рассчитываются стоимости единицы рабочего времени специалиста каждой из линий поддержки до и после внедрения. Более сложный расчет учитывает стоимость возможного простоя сотрудников бизнес-подразделений, стоимость аренды помещений и т.д.

Следует ли затраты на ИТ распределять по бизнес-подразделениям и бизнес-пользователям?

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

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

С чего начать внедрение? Какие процессы внедрять?

Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел ИТ-департамента. Для анализа можно применять известные методики (например, Pink Elephant, HP ITSM) или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает ИТ-отдел в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы ИТ, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.

Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к ИТ-отделу на основе сбора и обобщения требований и ожиданий бизнеса от ИТ и возможностей ИТ-службы удовлетворить потребности бизнес-подразделений.

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

Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от ИТ-подразделения, и ИТ-услугами?

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

Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?

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

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

Обязательно ли организовывать Service Desk?

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

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

При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных ИТ-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.

При отсутствии службы Service Desk ее функции выполняет вся ИТ-служба.

Как оценить численность сотрудников Service Desk?

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

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

Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?

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

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

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

Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?

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

Отдельно следует рассмотреть параллельное внедрение ERP и ITSM. В этом случае вероятность успешного завершения каждого из проектов будет ниже, чем при последовательном внедрении. Дело в том, что и тот и другой проект относятся к так называемым «стрессовым» проектам, требующим перестройки как ИТ-службы, так и бизнес-подразделений. Таким образом, на время параллельного внедрения ERP и ITSM повышается нагрузка на сотрудников, возрастает неопределенность и влияние человеческого фактора, в итоге значительно повышаются риски подобного проекта.

Чем ITSM может помочь при организации аутсорсинга?

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

Обязательно ли использовать консалтинг при внедрении ITSM?

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

Что будет, когда закончится проект?

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

Размещено: Директор ИС, №03/2007

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

Кстати, WM2005, даже английской сборки, поддерживает отображение русских букв. Только с вводом проблема.:)

Впечатления от пользования.

Корпус приятный на вид и на ощупь. Пользуясь определением С.Голубицкого ("Компьютерра") - "тактильность на высоте". WM2005 приятно порадовала поддерживаемой возможностью поворота экрана. Так же, как и жестко предустановленный набор софта от HP.

Из благ цивилизации: неплохой (с моей точки зрения) процессор 312 МГц, 128 Мб ОЗУ, 64 ПЗУ, модуль Bluetooth. Последняя фича оказалась просто незаменимой: синхронизация наладонника может быть выполнена "легко и изящно", то есть - прозрачно.

Это - бочка меда. Ложка дегтя состоит в том, что на указанном девайсе поначалу не было русификации (пробовал поставить с диска Fuji - как и следовало ожидать, не пошло). Также не поддерживается ввод русских букв (отображается без проблем). Ввод русских букв решился просто - Resko Keyboard Pro/ Русификация интерфейса была признана ненужной, и поиски в этом направлении более не велись.

Вторая ложка дегтя - странное поведение устройства. iPAQ 2190 вис при выключении, грелся и сам разряжал батарею. Поиск по базе знаний (читай: в интернет) выдал следующий результат: проблема в Active Sync, которая по непонятной причине синхронизируется когда не лень и когда не надо. Проблема решается просто (ниже привожу рецепт, скомпилированный из ветки форума )

Неплохо еще В общем Start - Settings - Personal - Today - Items - отключить галочку у Today Timeout

Кстати, у меня приведенное выше решение сработало на 100%.Итог: могу рекомендовать HP iPAQ как недорогой и неплохой наладонник для тех, кто не предъявляет требований к супермобильности и крутизне, но понимает, зачем ему КПК:)

С удивление констатирую факт: в настоящее время нет

(по крайней мере в Санкт-Петербурге)

просто наладонника без "наворотов".

История вопроса проста и печальна: верой и правдой служивший мне Toshiba e355 почил. Сначала там "накрылся" аккумулятор (время автономной работы упало до катастрофически неприличного значения - 40 и менее минут), затем отошел край корпуса, прилегающий к экрану, после чего отломалось крепление к USB. Результатом явилось признание аппарата неработоспособным, требующим достойной замены со всеми вытекающими последствиями.

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

1. Читаю книги
2. Использую в качестве большой записной книги
3. Иногда пишу что-нибудь (небольшие заметки)
4. Один раз за несколько лет вышел в Интернет

Соответственно, требования минимальные: чтобы был как класс, без лишних наворотов (зачем мне WiFi или Bluetooth, которыми я не пользуюсь? - хотя Bluetooth как интерфейс был бы нелишним для организации беспроводной связи "компьютер -наладонник" - отметим, как требование). Большой экран, желательно с хорошим разрешением (не критично, просто комфортнее). GPS, GPRS и т.д. не требуется - GPS я не пользуюсь, а GPRSG/GSM не нужен просто потому, что для этих целей имеется телефон.

Анализ рынка показал, что Toshiba перестала поставлять свои КПК на наш рынок (а жаль! - хорошая была техника), правда, рынок прирос массой конкурирующих предложений. В основе своей все эти предложения "жутко HiTech" - интерфейсы WiFi, Bluetooth, быстрый процессор, QVGA и т.д. встречается чуть ли не на каждой модели. Что примечательно: простого наладонника (совсем-совсем без наворотов) мне найти ... правильно, удалось! HP iPAQ 1710. Модель, снятая с производства, но пока еще присутствующая в продаже (как я думал - наивный!) в некоторых магазинах.

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

Что в итоге? Выбор продолжается. Не удалось уложиться в "бюджетную" модель, по причине отсутствия оной. Зато найдено несколько интересных моделей - совсем бесполезные мне HP iPAQ серии 19хх и интересные iPAQ серии 2ххх. Интересны они тем, что при стоимости на 2 000 руб. больше, чем 1710, по начинке они от них не отличаются практически ничем, кроме Bluetooth модуля.

Последняя ремарка этого довольно сумбурного поста: как оказалось, VGA и QVGA разрешение экрана идет вкупе с безумным количеством наворотов. А жаль!

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

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

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

Что, кстати, мне всегда нравилось у Белянина – автор всегда выпячивает роль судьбы – понимаешь, так вот получилось, а мы (герои) вообще-то тут так, рядом проходили:))) Но у него герои по крайней мере – нормальные (в основном) люди, каждый со своим «ку-ку» (а куда же без этого), а не супергерои.

Что сказать в итоге? Книгу осилил в поезде Москва – Питер (то есть, прочитал за 4 часа). Один раз прочитать можно, мозг расслабляет и местами заставляет поулыбаться, забыв на время о делах...

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

Например, при решении задачи «в лоб», каталог сервисов часто заменяют на перечень эксплуатируемых ИТ систем и базового ПО. Подобный подход имеет ярко выраженный недостаток: при инвентаризации в средней компании (то есть, с числом АРМ порядка 500) может быть обнаружено порядка 100..300 систем и приложений, которые могут быть классифицированы как сервис. Таким образом, пользователь, обращаясь в ИТ для решения каких-либо вопросов, вынужден формулировать свой запрос «на языке ИТ», что принципиально противоречит рекомендациям ITIL. Другая крайность – чересчур широкое определение сервиса. Например, сервис «рабочее место пользователя» может включать в себя ПК, базовое ПО, специфическое ПО и периферийные устройства, что приближает количество инцидентов, связанных с данным сервисом, к 100% от общего числа зарегистрированных инцидентов.

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

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

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

• Составляется инвентарный перечень всех программных и аппаратных средств, а также политик
• Составляется список пользователей, которые работают с указанными средствами
• Пользователи объединяются в группы по определенным признакам (соответственно, выделяются признаки классификации)
• Для каждой из сформированных таким образом групп пользователей выделяются те ресурсы (программные и аппаратные средства, политики), которые ими используются
• Определяется примерный перечень сервисов для каждой из групп пользователей
• Определяется примерный перечень всех сервисов, которые предоставляются отделом ИТ
• Проводится аудит перечня сервисов

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

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

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

Управление каталогом сервисов включает в себя:

• Мониторинг текущего каталога сервисов
• Выявление новых сервисов
• Выявление новых территорий, требующих разворачивания тех или иных ИТ сервисов
• Выявление утративших актуальность сервисов
• Актуализация каталога сервисов

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

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

7 января 2007 года состоялся 12 Круглый стол по ИТ сервис менеджменту.

В отличие от прошлого мероприятия, которое мне откровенно не понравилось, этот был на гораздо более высоком уровне. Понравилось конструктивное выступление Михаила Потоцкого относительно 3 версии ITIL (Михаил приоткрыл завесу таинственности над ITIL3 и назвал конкретные сроки выхода: примерно май 2007 года). ITIL 3 является логическим продолжением ITIL 2, значительно переработанным и усовершенствованным. По утверждению М.Потоцкого, в работе над 3 версией ITIL приняло рекордное количество специалистов из Америки (напомню: традиционно над ITIL работали европейские специалисты). Благодаря этой «свежей крови» рекомендации (по заявлениями знакомых с пре-релизами ответственных товарищей) стали более конкретными, смещаясь от акцента относительно того «что надо делать» к акценту «как надо делать». Отмечу, что вторая версия ITIL не отвечала на вопрос «как надо делать» вообще никак. Кроме того, в третьей версии ITIL появятся разделы, ориентированные на малые (до 100 человек) предприятия, и декларативно будет описан процесс управления персоналом (читаем между строк: самым общими фразами). Кроме того, ITIL 3 полностью перегруппирует и перекомпанует процессы, характерные для ITIL 2 (что говорит о их переосмыслении). Среди официальных языков ITIL 3 значится и русский, что не может не радовать. Правда, пока непонятно, кто именно будет выполнять перевод (оригинал все равно разрабатывается на английском).

Вторая часть Круглого стола была посвящена проблеме оценки рисков при управлении проектами. Выступал представитель компании PM Expert, который здорово (действительно здорово!) описал, как можно управлять рисками проекта со стороны заказчика. За что и был засыпан горой вопросов относительно того, а как управлять рисками проекта в целом (и заказчика, и исполнителя), а также как отдельно управлять рисками исполнителя.

Подробности – на http://www.itsmforum.ru/