Различные подходы к внедрению процессов ITIL
Общие принципы
• Люди
– Подбор
– Обучение
– Мотивация
• Процессы
– Моделирование
– Документирование
– Контроль результатов
– Корректировки
• Технологии
– Системы обработки событий (trouble ticketing)
– Системы мониторинга ИТ-инфраструктуры
– Вспомогательные системы (базы знаний, CMDB, RWH, другие)
– Комплексные системы сервисного управления
– Системы call-center (ACD, IVR, другие)
Модель 1.«Классическая»
INC(+SD)->CFG->CHG->PRB->SLM
• Выгоды
– Опробованная модель
– Позволяет снять наиболее острые проблемы
– Основа для дальнейшего внедрения
• Трудности
– Больше реактивная, чем проактивная
– Требует значительных инвестиций на начальном этапе
– Требует значительных организационных изменений
Модель 2.«Контрактная»
• SLM->CFG->INC(+SD)->CHG->PRB
• Выгоды
– Формализует взаимоотношения с Заказчиком
– Подходит для ИТ-аутсорсинга
– Задает направление развития ИТ
• Трудности
– Риск несоблюдения SLA
– Заключение SLA с ИТ не всегда востребовано бизнесом
– Необходимо управлять требованиями Заказчика
Модель 3.«Инфраструктурная»
• Event Mgt (ICT+Applications)->CFG->PRB->INC(+SD)->SLM(+CHG)
• Выгоды
– Ориентация на критические системы/приложения/сервисы
– Инвестиции легко объяснимы
– Больше проактивная, чем реактивная
• Трудности
– Выбор поставщика ПО
– Измерять то, что необходимо
– Поддерживать актуальность CMDB – ответственность инженеров
Особенности ИТ сервисовв банковской сфере
Бизнес-критичные системы (core banking systems) – доступность, время восстановления, BCP/DRP
Информационная безопасность
Change Management для core banking systems
Удаленная поддержка, каналы связи (офисы продаж, банкоматы, трейдеры)
Круглосуточная поддержка
Большое количество business-driven проектов
Передача ИТ на аутсорсинг (Help Desk, desktop support, telecom)
Tags: IT, ITIL
ITIL v.3
Автор: Денис Легезо
Ближе к концу уже прошлого 2007 года появилась новая библиотека лучшего опыта управления сервисами ITIL — третья её версия. О том, что в ней изменилось по сравнению с предыдущей версией, как велась работа над библиотекой, из каких основных частей она состоит и каковы планы ее дальнейшего развития, на конференции российского itSM-форума рассказал Айвор Макфарлейн (Ivor Macfarlane) — председатель комитета по публикациям itSMF International, консультант IBM Global Technology Services, который участвует в разработке ITIL с самого начала. Свой собственный первый экзамен по ITIL менеджерского уровня Айвор Макфарлейн сдал еще в 1991 году.
ITIL была, является сейчас и останется в будущем собственностью британского правительства. Спонсором работ по её созданию выступает организация Office of Government Commerce (OGC). В начале 2005 года OGC принял решение обновить актуальную на тот момент вторую версию библиотеки. Разработка третьей версии в основном велась в рамках itSMF (IT Service Management Forum), причем в ней участвовали эксперты не только из международного отделения форума, но и из отделений itSMF в разных странах. Особенно Айвор Макфарлейн выделил своих коллег из Норвегии, Швеции, Дании, Италии, Германии и Японии.
Анализ запросов пользователей
Прежде всего коллективу экспертов, в том числе и Айвору Макфарлейну как руководителю комитета по публикациям международного itSMF, было поручено выяснить, какие именно изменения по мнению пользователей должны будут появиться в следующей версии библиотеки. В начале 2005 года в ходе шести семинаров, проведенных в Европе и Северной Америке, был проведен опрос и собрано множество мнений о том, чего не хватает во второй версии ITIL. По словам Айвора Макфарлейна, некоторые из этих мнений напрямую противоречили друг другу, были и совершенно нереализуемые пожелания, но команде удалось собрать более чем достаточное количество разумных идей. Свое слово о том, как должна выглядеть следующая версия ITIL, высказали и многие крупные компании. Среди них HP, IBM, Microsoft, Fujitsu Siemens и Computer Associates. Таким образом, перед началом работы над третьей версией ITIL большое количество людей поделилось с командой разработчиков собственным видением будущего библиотеки.
Главный вывод, который был сделан по собранной в итоге информации, таков: в третьей версии должно быть больше единообразия и согласованности. То есть с точки зрения участников опроса вторую версию ITIL назвать единообразной нельзя. Именно пожелание единообразия Айвор Макфарлейн посчитал самым важным результатом опросов. Кроме того, респонденты хотели видеть в библиотеке примеры, шаблоны, по которым они могли бы строить управление сервисами в своей компании, и разборы интересных случаев использования ITIL в других организациях. Вызывали нарекания и текущие экзаменационные вопросы, так как многие просили доработать процесс сертификации, была просьба учесть при разработке тот факт, что ITIL — не единственный набор руководств в мире, что кроме этой библиотеки существуют еще и CobiT, и CMM, и другие рекомендации.
ITIL и другие методологии
ITIL существует в мире, где более чем достаточно других методологий, пересекающихся с этой библиотекой, но она не конкурирует с ними. Ведь никто не занимается совершенствованием процессов согласно ITIL просто так, а используют её для повышения качества управления сервисами. По словам Айвора Макфарлейна, команда постаралась связать библиотеку практически со всеми стандартами, где это было возможно. Так, сейчас itSMF работает над подписанием меморандума с владельцами CobiT. Разработчики ITIL привлекли к данной деятельности руководителя комитета, занимающегося ISO 20000, и по мнению Айвора Макфарлейна есть полное соответствие рекомендаций этих двух библиотек в той части, где они пересекаются. Кстати, это и не удивительно, поскольку текст часто писали одни и те же люди. Двигается форум и в сторону создания связи между ITIL и eTOM.
Из чего состоит ITIL v.3
Еще на самом начальном этапе планирования было решено, что библиотека будет состоять из трёх частей. Перечислим их в порядке уменьшения уровня абстракции: ядро (core), дополнительные книги (complementary) и интернет-часть (Web). То есть кроме написанных командой экспертов книг ядра, в библиотеке будут и книги других авторов, которые дополнят их. Идеологическая часть ITIL v.3 — ядро — должна включать пять книг: по сервисной стратегии (service strategy), переходным процессам сервисов (service transition), операционным процессам сервисов (service operation), проектированию сервисов (service design) и их постоянному совершенствованию (continual service improvement). Выбор пяти пар авторов для пяти книг, ставших итогом всех перечисленных подготовительных мероприятий, по словам Айвора Макфарлейна, был проведен через тендерную систему Евросоюза.
В мае 2007 года были опубликованы первые книги ITIL v.3. Планируется, что книги ядра за авторством экспертов из itSMF должны сохранять актуальность в течение трех лет. Однако это только начало. Дело в том, что основные пять книг представляют собой руководства самого общего, верхнего уровня. Далее работа пойдёт над изданием дополнительной серии книг — complementary: их авторы будут концентрироваться уже не на идеологии, а на вопросе «как сделать?». В серии complementary планируется выпустить книги, посвященные как отдельным секторам рынка: государственному, финансовому, высокорисковым областям и т. п., — так и управлению ИТ-сервисами в конкретной культуре. Например, практика японских компаний значительно отличается от европейской и по мнению авторов третьей версии ITIL нуждается в отдельном издании. И если в России есть своя специфика организации управления сервисами, то российские эксперты itSMF, считает Айвор Макфарлейн, тоже должны будут написать такую книгу. Ряд практических книг уже сейчас готовится к выпуску. По словам Айвора Макфарлейна, со многими компаниями, готовыми поделиться информацией, уже достигнута договоренность о публикации записей, касающихся внедрения у них тех или иных элементов, относящихся к третьей версии ITIL. Наконец, третья — интернет-часть — третьей версии ITIL будет включать в себя информационные документы, примеры использования и другие сугубо практические материалы. В Интернете на безвозмездной основе будут опубликованы шаблоны и рекомендуемые схемы процессов. «Но мы еще не решили, будет ли доступ к ним общим, — прокомментировал Айвор Макфарлейн. — Есть вероятность, правда, небольшая, что только участники ITSM-форума смогут обращаться к этим материалам».
Российские компании только начинают задумываться об использовании ITIL
Георгий Ованесян, руководитель направления технической поддержки и аутсорсинга компании КРОК
Безусловно, новая версия ITIL v.3 давно привлекает внимание ИТ-сообщества (задолго до публикации специалисты читали краткие документы, например глоссарий ITIL v.3, чтобы оценить грядущие изменения). Выпущенная в свет новая версия библиотеки действительно не является чем-то кардинально новым. Это скорее обновление и устранение ошибок и несоответствий, которые были в версии 2. Однако наш опыт внедрения рекомендаций ITIL в России свидетельствует, что большинство компаний внедрили у себя только процессы, описанные в книгах «Поддержка услуг» и «Предоставление услуг» из второй версии библиотеки ITIL. Это косвенно подтверждается тем, что единицы российских компаний прошли сертификационный аудит по стандарту ISO 20000, так как пройти его может лишь предприятие, внедрившее у себя все тринадцать процессов, описанных в стандарте. Поэтому можно считать, что хотя сервисный подход «по третьей версии ITIL» в мире не является чем-то кардинально новым, российские компании только начинают задумываться о его использовании.
Ядерная анатомия
Как мы уже отмечали, в ядре ITIL v.3 пять книг. Первая книга — «Сервисная стратегия» — рассказывает о необходимости самого’ сервисного подхода. Здесь вводится представление о сервисе как о некой цельной сущности, а не просто надстройке над имеющимся программным инструментом, вокруг которого потом вдруг вырастает сервис. Рассказывается о том, какие преимущества дает бизнесу сервисная модель, как строить стратегическую политику соотнесения этой модели с внешними и внутренними стандартами организации, как рассчитать стоимость сервиса, управлять неопределенностью, сложностью, рисками. Состоялся переход от существовавшего ранее понятия цепочки ценностей к термину сети ценностей, который учитывает более сложные отношения компании: аутсорсинг, партнерство, большое количество клиентов. Команда разрабочиков признает, что со времени работы над второй версией мир заметно усложнился, и что если по каким-то причинам вы этого пока еще не почувствовали, то, как выразился Айвор Макфарлейн, скоро почувствуете.
Вторая книга носит название «Проектирование сервисов», и появление этого процесса в виде отдельной книги с точки зрения Макфарлейна — самое важное обновление во всей третьей версии ITIL. С одной стороны, всем кажется абсолютно очевидным, что любой сервис должен быть спроектирован. Но почему-то при этом во всех организациях, с которыми работал докладчик, существуют примеры обратного. Опять же под сервисом понимается целая совокупность понятий — не только программное и аппаратное обеспечение, но и способы его работы, поддержки, цена использования и т. п. В книге содержится рассказ о политике проектирования сервисов и даются ответы на вопросы: как выбирать сервисы, которые мы будем проектировать? что имеет смысл передать на аутсорсинг, что делать собственными силами, а где нужно использовать стратегию частичной отдачи сторонним исполнителям?
Результатом проектирования сервиса должен являться сервисный пакет (service package). По поводу этого термина спор среди разработчиков шел месяца три, и в итоге они остановились именно на такой формулировке. В сервисном пакете содержится подробнейшая информация о сервисе: за что он будет отвечать, как будет внедряться и даже какие обстоятельства могут заставить вас провести его перепроектирование. Причины перепроектирования, кстати, могут быть банальны и просты: возросшее количество пользователей, достижение сервисом определенного возраста и т. д.
Книга под номером три посвящена переходным процессам сервисов. Речь идет о том, что мы не можем судить о приемлемости ИТ-сервиса до тех пор, пока не узнаем точно, каким образом он будет использоваться. Часто заказчику бывает нужно нечто совершенно не похожее на то, что он сформулировал на этапе проектирования. В таком случае в уже спроектированном ИТ-сервисе делаются серьезные изменения. И необходимо, чтобы при построении новых сервисов можно было контролировать ход выполнения работы. В этой книге собраны методики перехода, оценки и тестирования сервисов. Кроме того, Айвор Макфарлейн выделил содержащуюся в томе формализацию поддержки «боевой» работы системы на ранних стадиях. Очень часто команда, занимавшаяся запуском ИТ-сервиса, самоустраняется сразу по окончании этих работ. Такой подход разрабочики ITIL не считают правильным, и их задачей было донести до читателей собственное ви’дение поддержки заказчика проектной командой на ранних стадиях «боевой» эксплуатации.
Взгляд на управление ИТ-услугами с точки зрения их жизненного цикла
Сергей Куликовский, руководитель направления Service Management, CompuTel
ITIL v.3 является закономерным развитием предыдущих версий, а главное различие между ними состоит в подходе к организации ИТ. Если в ITIL v.2 основное внимание уделялось качеству предоставляемых ИТ-услуг, то в ITIL v.3 упор делается на экономическую эффективность. В новой редакции предлагается взглянуть на управление ИТ-услугами с точки зрения их жизненного цикла. При этом авторы дают ответы на вопрос, как нужно делать, а не только что нужно делать, как это было в ITIL v.2, и предлагают конкретные методики (например, по расчету окупаемости инвестиций в ИТ или оценке эффективности применения модели аутсорсинга). Такой подход объединяет ITIL v.3 с общепризнанным стандартом в области управления качеством ИТ-услуг CobIT. Хочется отметить появление нового раздела Сompliance, который посвящен соответствию требованиям смежных стандартов в сфере управления качеством и управления ИТ, а также законодательным актам Сарбейнса — Оксли и Basel II. В ITIL v.2 эта тема не затрагивалась. В целом дальнейшее развитие ITIL и появление ITIL v.3 обусловлено, с одной стороны, растущим влиянием ИТ на бизнес, а с другой — ужесточением требований бизнеса к эффективности ИТ.
В четвертую книгу — «Операционные процессы сервисов» — перешли процессы сервисной поддержки (service support) из предыдущей версии библиотеки. Айвор Макфарлейн заявил, что команде удалось взять основу ITIL и заполнить ее слабые области без ущерба для соседних. Какие это области? Например, в книге о поддержке сервисов во второй версии ITIL подробно описан процесс управления инцидентами. Докладчик напомнил, что на иллюстрации со схемой процесса есть вопрос: «Это сервисный запрос?». И если ответ положительный, то следует указание запустить процедуру обработки сервисного запроса (service management procedure). Однако дальше в ITIL v.2 нет ни слова о том, что именно представляет собой эта процедура. В четвертой книге третьей версии ITIL процедура сервисных запросов наконец-то описана, как и процедура управления событиями (event management procedure). По словам Айвора Макфарлейна, здесь добавлено все то, чего не хватало для поддержки сервисов во второй версии.
В последней по очереди и самой маленькой по объему пятой книге рассказано о постоянном совершенствовании сервисов. Как заметил Айвор Макфарлейн, в черновиках разработчиков библиотеки этот том был самым объемным, но в итоге ими намеренно было оставлено только самое важное. В пятом томе описан семишаговый процесс поиска необходимых изменений для уже работающих сервисов. Рассказано о непременно предшествующей таким изменениям оценке двух ситуаций: той, в которой компания находится сейчас, и той, в которой планирует оказаться через некоторое время после усовершенствования сервиса. Звучит это настолько очевидно, что вряд ли кто-то сомневается в необходимости такой работы, но по опыту Айвора Макфарлейна этот тривиальный процесс не применяется в реальной работе компаний.
Российские ИТ-менеджеры уверены в ITIL v.3
В опросе, который мы провели среди 43 ИТ-менеджеров в России (см. статью «ИТ-сервисы в котловине разочарований») мы задавали вопросы и об отношении к третьей версии ITIL. Две трети респондентов считают, что третья версия библиотеки принесла нечто принципиально новое и полезное. Более того, популярность третьей версии в России очень велика. Практически 100% опрошенных планируют в будущем проводить на своих предприятиях какие-либо изменения в соответствии с рекомендациями ITIL v.3.
Жизненный цикл сервисов
Вокруг третьей версии ITIL уже довольно много спекуляций, так что встала задача разобраться, что вам придется менять при переориентировании своей работы с ITIL v.2 на ITIL v.3. Во-первых, все знакомые по второй версии процессы остаются, но в измененном, усовершенствованном виде. Абсолютно точно можно сказать, что никакие процессы в новой версии не устраняются совсем. Одним из важнейших изменений стало появление концепции жизненного цикла сервисов, но не надо думать, будто она заменила собой процессный подход!
Кажется странным, что понятие жизненного цикла сервиса появилось только сейчас, в третьей версии. На самом деле в каком-то виде оно существовало и в первой версии, и во второй. В ITIL v.1 была книга о планировании и контроле, содержавшая многое из того, что в сегодняшней версии назвали жизненным циклом сервиса. Аналогична ситуация с книгой о планировании и внедрении в ITIL v.2. Однако надо напомнить, что в первой версии ITIL разработчики отталкивались от понятия функции, поскольку именно функциональному подходу соответствовал тогда мир вокруг них, и именно так работали люди. Затем, после публикации Британского института стандартизации (BSI) в 1995 году, которая по сути стала введением во вторую версию ITIL, команда разработчиков переориентировалась на процессный подход. С тех пор, по мнению Айвора Макфарлейна, одним из самых значительных изменений не только в информационных технологиях, но и в мире вообще стал переход от товарных отношений к сервисным. Это относится к самым разным отраслям, от автомобилестроения до туристического бизнеса. Данная тенденция получила свое отражение в третьей версии ITIL, в появлении процесса жизненного цикла сервиса. Но разве может такая концепция заменить собой процессы, обеспечивающие работу и развитие предприятия? Макфарлейн неоднократно подчеркнул, что концепция жизненного цикла не замещает собой процессный подход, это просто другой способ смотреть на происходящее в компании.
Айвор Макфарлейн специально остановился на том, что совершенно неверно утверждение, будто только организации с высоким уровнем зрелости могут переходить к использованию концепции жизненного цикла сервисов. На самом деле жизненный цикл сервисов существует абсолютно на любом предприятии. На обычном уровне под этим термином понимается практическая реализация пожеланий сотрудников к данному ИТ-сервису, так что жизненный цикл сервисов в том или ином виде есть в каждой компании.
На плечах ITIL v.2
Завершая рассказ о новой версии ITIL, Айвор Макфарлейн вспомнил слова сэра Исаака Ньютона (хотя злые языки обвиняют его в краже этой фразы у монаха XIII века): «Если я и вижу дальше других, то лишь потому, что стою на плечах гигантов». Команда разработчиков третьей версии ITIL целиком и полностью согласна с этим. Айвор Макфарлейн предал гласности их общее мнение: третья версия прочно основывается на всем том удачном, что уже было сделано в предыдущей версии библиотеки, и если у них получилось что-то толковое, то целиком благодаря ITIL v.2. Докладчик настаивал на том, что третья версия написана не для самостоятельного использования без опоры на предшествующую, то есть не как самодостаточная библиотека ITIL. Для Айвора Макфарлейна критерием независимости и цельности третьей версии является её понятность: поймут ли люди, никогда прежде не слышавшие про ITIL, всё в ней изложенное сразу по третьей версии? А это по его мнению сомнительно, поскольку это совсем не то же самое, что перейти с одной версии СУБД на следующую.
Базовым намерением команды при разработке третьей версии было упростить практику управления ИТ-сервисами. Но упростить ее не для тех организаций, которые ограничили свою внедренческую практику объемом первых двух книг из второй версии о доставке и предоставлении сервисов. Айвор Макфарлейн уверен, что действуя таким способом вы не получите нормального управления сервисами. Если вы думаете иначе, то по мнению докладчика вы не очень хорошо знаете менеджерский курс ITIL. И если вы решитесь на переход к рекомендациям ITIL v.3, реализовав лишь процессы поддержки и доставки сервисов, то объем работы в этом проекте у вас будет очень большим.
На вопрос, придется ли покупать новые программные инструменты для использования рекомендаций третей версии ITIL, Айвор Макфарлейн заметил, что большинство сегодняшних программных реализаций ближе к третьей версии, нежели ко второй, поскольку все то время, пока разрабатывалась новая версия библиотеки, программы развивались независимо, своим путем, и многие подходы в них уже реализованы. Хотя если работающее у вас программное обеспечение не может поддерживать процессы из предыдущей версии ITIL, то Айвор Макфарлейн советует заменить его.
Если вторая версия описывала, к чему нужно стремиться, то третья говорит, как этого достичь
Кирилл Рубинштейн, руководитель проектов компании NAUMEN
Нельзя не согласиться, что ITIL v.3 — это важный этап в развитии данного стандарта управления ИТ. Если вторая версия описывала, к чему нужно стремиться, то третья говорит, как этого достичь. Появилось важное понятие жизненного цикла сервиса, оно приближает ИТ к бизнесу и более глубокому пониманию его потребностей, осуществляет переход от взаимодействия бизнеса и ИТ к интеграции ИТ в бизнес. Как верно замечено, ITIL v.3 — не революция, а эволюция, следовательно, не стоит приступать к внедрению третьей версии стандарта, не внедрив (или по крайней мере не поняв идеологию сервисного подхода) второй. Не надо расстраиваться и считать себя отстающими, если на вашем предприятии уже начато или вот-вот закончится внедрение ITIL v.2. Третья версия ITIL будет вашим следующим шагом — развитием созданного.
Резюме
Если попытаться обобщить мнение участников конференции, то третья версия библиотеки не сделала никакой революции. В ней безусловно есть интересные новые идеи, которых не было в ITIL прежде. Возможно, они были где-то рядом, в соседних методологиях, а теперь появились в структуре библиотеки. Но в общем и целом процесс представляется эволюционным, а не революционным. С книгами хорошо поработали, перегруппировали процессы, добавили новую информацию, проиллюстрировали жизненный цикл сервиса, однако во всем этом революции нет: ITIL просто продолжает плавно и постепенно развиваться. Появление жизненного цикла сервиса не несет в себе большого драматизма, учитывая, что понятие сервиса является одним из краеугольных камней двух предыдущих версий ITIL, здесь же мы видим более яркое выделение вопроса, уже существовавшего в библиотеке до того, т. е. поступательное развитие.
Tags: IT, ITIL, ITSM, библиотека IT, управление ИТ
Данный сайт посвящен подходам, процессам и методам управления Информационными Технологиями. На сегодняшний день самым популярным подходом к управлению ИТ в мире есть ITIL.
ITIL представляет собой свод лучших практик по организации и управлению ИТ из частного и правительственного сектора во всем мире.
ITIL состоит из серии книг, предоставляющих указания относительно предоставления качественных ИТ-услуг, а также на процессы необходимые для их поддержки.
Информационные технологии делают бизнес возможным! И на сегодняшний день и в будущем весь бизнес будет зависеть не только от профессиональной и качественной бухгалтерии, маркетинга и т.д. но и от ИТ тоже.
Поэтому вкладывая деньги в развитие информационной инфраструктуры бизнес должен понимать насколько качественно работает ИТ, насколько хорошо предоставляет услуги.
Под услугами иметься ввиду электронная почта, доступ в интернет. 1-с бухгалтерия. Все возможные crm, erp системы .
Использование ITIL дает следующие выгоды:
Сокращение расходов на содержание ИТ
Улучшение ИТ услуги за счет использования проверенных процессов и опыта
Улучшить удовлетворенность пользователей за счет более профессионального подхода к обслуживанию ИТ – услуг
Внедрение новых стандартов ISO 20000 и др.
Управление производительностью систем и т.д.
Tags: ERP, IT, ITIL, ИТ услуги
ITIL (англ. IT Infrastructure Library — библиотека инфраструктуры информационных технологий) (произносится как «айти́л») — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. Множество частных и государственных компаний в разных странах мира, включая и Россию (как пример компания Департамент ИТ), добились значительных успехов в повышении качества ИТ-сервисов, следуя изложенным в ITIL рекомендациям и принципам . В настоящее время ITIL становится стандартом де-факто и для Российского ИТ-рынка
Библиотека ITIL появилась около 20 лет назад по заказу британского правительства. В настоящее время она издается британским правительственным агентством Office of Government Commerce и не является собственностью ни одной коммерческой компании (формально библиотека принадлежит королевскому дому Англии, в частности — нынешней королеве). В семи томах библиотеки описан весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Следует отметить, что все эти процессы нацелены не просто на обеспечение бесперебойной работы компонент ИТ-инфраструктуры. В гораздо большей степени они нацелены на выполнение требований пользователя и заказчика. В конечном счёте, все процессы ITIL работают на повышение конкурентоспособности, а в наше время даже внутренние ИТ-подразделения компаний не могут чувствовать себя в абсолютной безопасности, так как вынуждены конкурировать с аутсорсинговыми компаниями.
Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, а также на ресурсах, затраченных на достижение этих целей. Процессный подход не имеет себе равных по обеспечению измеримости и управляемости деятельности предприятия, что, собственно, и сделало его таким популярным.
В настоящее время на основе ITIL разработан британский стандарт BSI 15 000, который практически без изменений перешёл в категорию международного стандарта под именем ISO 20000.
Структура ITIL
Вторая редакция ITIL включает в себя семь книг:
Поддержка услуг (Service Support)
Предоставление услуг (Service Delivery)
Планирование внедрения управления услугами (Planning to Implement Service Management)
Управление приложениями (Application Management)
Управление инфраструктурой информационно-коммуникационных технологий ( ICT Infrastructure Management)
Управление безопасностью (Security Management)
Бизнес-перспектива ( The Business Perspective)
а также «дополнительную» книгу — «Управление конфигурациями ПО» (Software Asset Management).
Наиболее известная часть ITIL — десять базовых процессов, обеспечивающих поддержку и предоставление ИТ сервисов — IT Service Management или ITSM:
Процесс управления инцидентами
Процесс управления проблемами
Процесс управления конфигурациями
Процесс управления изменениями
Процесс управления релизами
Процесс управления уровнем услуг
Процесс управления мощностями (емкостью)
Процесс управления доступностью
Процесс управления непрерывностью
Процесс управления финансами
Кроме того, в структуре процессов ITSM важную роль играет служба поддержки пользователей — Service Desk.
Новая редакция (третья) содержит уже только пять книг и была выпущена в мае 2007
Tags: IT, ITIL, библиотека IT
 |
|
| ITIL шествует по миру ИТ уже почти десять лет, вышла его третья версия, сформировалась целая сеть профессиональных сообществ и целая армия сертифицированных специалистов, растет осведомленность бизнеса о преимуществах ITSM, принципах и практиках ITIL. И тем не менее масштаб реального применения ITIL в бизнесе оказался не столь велик. По данным Gartner Group [1] лишь 20% компаний крупного бизнеса используют ITIL и 29% планируют его использовать. В среднем бизнесе эти цифры еще меньше: соответственно 7 и 19%. Внедрение процессов ITIL тоже идёт не широким фронтом. Большинство ИТ-служб в первую очередь внедряют их для поддержки ИТ-инфраструктуры, а бизнес-приложения часто откладываются «на потом». Что же сдерживает активное распространение ITIL? Наверное, было бы сильным упрощением связывать это с недостаточной квалификацией консультантов, слабой маркетинговой активностью профессионального сообщества или тотальной незрелостью бизнеса. Похоже, у данного явления есть более глубокие причины. |
|
|
|
|
|
|
|
Идеология управления ИТ-сервисами построена на модели партнерства ИТ-службы и бизнеса, когда обе стороны договариваются друг с другом. Если ИТ-служба всё «берет под козырек», то она выполняет поручения или свои функциональные обязанности. В случае ИТ-сервиса они договариваются по поводу уровня качества и условий его обеспечения, а также определяют ответственность обеих сторон. ИТ-сервис предполагает, что рост уровня его качества автоматически требует пересмотра сторонами условий и ответственности. Договариваются только равные, а неравные строятся в управленческую вертикаль. При выполнении функциональных обязанностей подразумевается, что ответственность лежит только на исполнителе (ИТ-службе). Качество — абсолютно, и если требования не обеспечены, исполнителя накажут. Сервис, от которого нельзя отказаться, — это должностная функция. В таком случае отношения между бизнесом и ИТ-службой будут строго иерархическими.С учётом сказанного вопрос о сдерживающих факторах внедрения ИТ-сервисов фактически можно переформулировать так: в каких задачах и при каких условиях бизнес и ИТ-служба готовы перейти от функциональных обязанностей к партнерским соглашениям? Опыт показывает, что это возможно, но далеко не всегда.Не все формы организации бизнеса [2] склонны выстраивать такие партнерские отношения между бизнесом и его подразделениями, в том числе и ИТ-службой. Например, быстро растущий холдинг, у которого административная и функциональная структуры не успевают за растущими бизнесами ее дивизионов, начинает терять централизацию управления. В этом случае создание единого сервисного пространства всего холдинга будет являться своеобразным «клеем», допускающим «пластичность» организации без потери ее целостности. ИТ-услуги хорошо вливаются в общий пул сервисов, предоставляемых управляющей компанией своим дивизионам.Способность разных форм организации бизнеса к построению внутреннего сервиса — тема отдельного исследования. В данной статье более подробно рассматриваются лишь технические факторы, а именно способность различных типов архитектур корпоративных информационных систем (КИС) к построению ИТ-сервисов. Замечу, что под КИС в дальнейшем мы будем понимать не отдельные, пусть и большие и критически важные для бизнеса приложения, а весь комплекс информационных систем предприятия абсолютно разного калибра в разрезе всех компонентов: данные, бизнес-приложения, ИТ-инфраструктура, бизнес-процессы и правила, персонал, работающий с КИС, и его компетенции.
Типы архитектур КИС
На сегодняшний день во всем мире существуют три основных типа архитектур КИС [2]. Gartner Group выделяет их больше, но доминирующими являются только три: «лоскутное одеяло», «сильная интеграция» и «слабая интеграция». Данные типы представляют собой точки зрения прежде всего бизнес-пользователей, а уж потом ИТ-специалиста.
«Лоскутное одеяло». Основной признак этого типа архитектуры КИС — большая избыточность данных, их дублирование в различных системах. Фактически передача информации между отдельными приложениями-«лоскутами» может сопровождаться вмешательством самих пользователей, подстраивающихся под текущую ситуацию в компании, подправляющих данные задним числом и т. п. По большому счету здесь мы имеем дело с информационным пространством, в которое пользователи вмешиваются постоянно. Сравнивать требования к разным видам архитектур мы будем в том числе и по такому показателю, как необходимая для их применения квалификация рядовых пользователей и руководящих сотрудников. В случае «лоскутного одеяла» к квалификации не предъявляется каких-либо серьезных требований. Сотрудники, как правило, работают по конкретным поручениям, которые при подобной архитектуре очень зависят от сложившейся ситуации. При этом модель деятельности предприятия, как правило, очень трудно описать в виде бизнес-процессов, так как они очень неустойчивы, а над формальными процедурами превалируют неформальные личные взаимоотношения сотрудников. Таким образом, организация, адекватная «лоскутной» архитектуре, в первую очередь опирается на личные связи между самими исполнителями. Важно понимать, что именно эти связи и лояльность сотрудников к своей компании являются интегрирующим фактором для данных в «лоскутном одеяле», а любые проблемы с лояльностью и связями в этой архитектуре моментально сказываются и на качестве данных.
«Лоскутное одеяло» очень устойчиво, но, как и в любой архитектуре, у него есть свои болевые точки. Прежде всего здесь трудно собирать аналитическую информацию. Отчетность может построить только человек, включенный во все существующие значительные личные связи. Архитектура не просто становится неотделимой от отношений между сотрудниками, она является их слепком. «Лоскутное одеяло» похоже на мозаику: глаз видит осколки, а картину достраивает воображение.
«Сильная интеграция». Можно сказать, что это антипод «лоскутного одеяла», другая крайность, в которой данные структурированы очень строго и их дублирование исключено. Типичным примером сильной интеграции может служить внедренная на предприятии ERP-система или же программа, разработанная самостоятельно, но также поддерживающая целостность транзакций на операционном уровне. Подобный тип архитектуры можно получить не обязательно в результате внедрения единой централизованной системы, но и, например, связав лоскуты архитектуры первого типа жесткими связями через API, на уровне ядер баз данных. В этом случае вы тоже получите схему с сильной интеграцией, которой, однако, будет тяжело управлять. Сильная интеграция ориентирована на автоматизацию именно бизнес-процессов. Они там действительно есть и очень устойчивы.
В этом случае требования к исполнителям на операционном уровне снова не высоки, так как система по сути выстраивает конвейер, к которому достаточно добавить инструкции пользователей. Пользователь здесь — это «прослойка между инструкцией и экраном». А вот на управленческом уровне, напротив, и архитектор системы, и ключевой специалист, ведущий бизнес-модель, должны быть людьми высочайшей квалификации. Они и только они обладают «тайным знанием» об устройстве системы и связях модели бизнес-процессов. Именно в серьезной зависимости от знающих людей заключена «ахиллесова пята» подобных архитектур. Многие ERP-проекты потерпели неудачу как раз потому, что таких людей со стороны бизнеса не было или их не удалось удержать по окончании работ. Кроме того, полученная модель системы должна быть стабильна, потому что если при сильной интеграции вы начнете менять бизнес-процессы, то это выльется в бесконечную перенастройку. Легко перенастраивать систему без данных. Но когда система проработала хотя бы полгода и «обросла» учетными данными, то перенастройки неизбежно будут сопровождаться их потерей.
При сильной интеграции крайне важен высокий уровень централизации управления, связанный с наличием центров компетенции, сотрудники которых, во-первых, представляют, как всё работает и на техническом уровне, и на уровне бизнеса, а во-вторых, не только дают советы, но принимают участие в принятии важных бизнес- и технических решений. Потеря централизации может привести к деградации данного типа архитектуры. Здесь не спасет даже исправно работающий механизм поддержки целостности транзакции. Например, два исполнителя по-разному назовут в системе один и тот же контрагент, сверить записи с другим источником и отследить ошибку по понятной причине не получится, и в номенклатурном справочнике начнут накапливаться несогласованности. Сильная интеграция похожа на головоломку-паззл, все впечатление от которой теряется, если выпадает хотя бы один кусок.
«Слабая интеграция». Этот тип архитектуры сейчас только начинает выходить на сцену российских ИТ, мы его пока еще осваиваем. Информационное пространство формируют два типа данных. Во-первых, первичные данные, к которым относятся такие информационные ресурсы, как документы, почтовые сообщения, базы данных, мультимедийная информация, ссылки и любые другие источники. Во-вторых, модели описания информационных ресурсов — каталоги, классификаторы и словари. Работа в этой архитектуре очень похожа на то, как вы работаете с обычными книжными библиотеками, начиная с классификатора информации, рубрикатора, а не сразу с книг-источников.
Здесь появляется иной подход к бизнес-приложениям. При сильной интеграции вы работали с функциями, которые исполняли как операции на конвейере. Задержка в выполнении любой функции приводила к остановке всего бизнес-процесса. Отказ от выполнения функций пользователю может только присниться в страшном сне. При слабой интеграции приложения представляют собой сервисы, которыми могут пользоваться работающие в информационной среде сотрудники, и у них появляется право выбора.
Безусловно, за это право приходится платить свою цену. При слабой интеграции квалификация пользователей на операционном уровне должна быть очень высокой. То же самое можно сказать и об уровне управления. Слабая интеграция — это не конвейер, это среда обитания, работа профессионалов, где они сами принимают решения о том, как им поступать. Это другая форма организации бизнеса, с очень глубокой децентрализацией и делегированием полномочий. Она требует формирования единого сервисного пространства. Если эта архитектура «загустеет» до неподвижных бизнес-процессов, сдвинется от сервисов в сторону функций, то квалификация профессионалов окажется невостребованной и они уйдут, не захотев работать простыми исполнителями. Профессионала в конвейер бизнес-процесса загнать нельзя. Им можно управлять только через ограничения.
Уже появились целые направления, которые описывают происходящее в компании не в терминах бизнес-процессов, а в виде системы бизнес-правил, отличающихся от процессов тем, что описывают жизнь предприятия не по принципу «делать так и только так», а по принципу ограничения «разрешено всё, что не запрещено». Это совершенно другой подход к организации бизнеса. В качестве типичного примера бизнес-правил можно привести законодательство государства или учетную политику предприятия. В области ИТ и управления начали появляться языки описания бизнес-правил. World Wide Web Consortium (W3C) уже содержит стандарты таких языков [3]. Язык Business Process Executive Language (BPEL) как раз позволяет на очень глубоком уровне детализации описывать бизнес-правила и бизнес-процессы. При слабой интеграции реальные траектории процессов в большей степени зависят не от заранее заданных маршрутов, а от происходящих в бизнесе событий, которые отражены в данных. Типичным примером бизнес-приложений, основанных на этой архитектуре, являются системы класса Enterprise Content Management (ECM). Они ориентированы на управление, например, документами, которое отталкивается не столько от бизнес-процессов их движения, сколько от содержания самих документов.
Слабая интеграция в большей степени похожа на голограмму. Если вы разобьете голографическое изображение, то увидите, что в каждом осколке сохранится целое изображение, но только с более низким качеством. В этом — отличие от интеграции сильной, где, как мы говорили, без любого своего фрагмента система рушится. Слабая интеграция обладает большой степенью избыточности, но и серьезным запасом гибкости.
Реальные архитектуры
У каждой архитектуры есть своя зона эффективности. Сильная интеграция (например, полномасштабная ERP-система) выживает в условиях стабильности бизнеса и ориентирована на обеспечение его эффективности. Она хороша там, где бизнес организован как поток типовых операций, от которых требуется производительность, ритмичность и эффективность. Примером такого бизнеса может служить крупносерийное машиностроительное производство или массовое оказание телекоммуникационных услуг.
Слабая интеграция выживает в условиях изменчивости и ориентирована на адаптивность. Применять ее стоит в том случае, когда в компании идут изменения и бизнес-процессы уже не являются стабильными. Будет эффективной слабая интеграция и тогда, когда бизнес делает ставку на индивидуализацию долгосрочных отношений с клиентом. Характерные примеры таких бизнесов представляют быстро растущие холдинги, НИОКР, ремонтные услуги крупных активов, страхование жизни или банковское долгосрочное кредитование.
«Лоскутное одеяло» — это единственная архитектура, выживающая в условиях очень высокой изменчивости и острого дефицита, т. е. в шоковой ситуации. Она наиболее широко распространена и характерна для бизнесов с жесткой авторитарной властью, ориентированных на межличностные отношения, а не на зафиксированные правила. «Лоскутное одеяло» может быть построено и для крупных компаний, работающих по жестким правилам. В этом случае вся тяжесть жесткой координации «лоскутов» этого одеяла ложится на плечи ИТ-службы.
Поскольку в крупных и средних компаниях всегда существуют зоны стабильности, развития и выживания, то реальная их архитектура в любом случае оказывается комплексной, смесью перечисленных нами выше типов. Важнейшая задача ИТ-стратегии как раз и состоит в том, чтобы понять, где должны быть проведены границы между типами в рамках единой архитектуры КИС. Стратегическая ошибка в их определении может очень дорого стоить компании в будущем. Особенно если вы остановились на строительстве архитектуры сильной интеграции по всему бизнесу, например, решили подогнать его под одну крупную ERP-систему. Не случайно они редко встречаются в чистом виде на предприятиях. Различные типы архитектур сосуществуют, образуя, как правило, уникальный симбиоз.
Применение ИТ-сервисов в рамках разных архитектур
Как влияет складывающаяся реальная архитектура КИС на возможность построения ИТ-службой сервисных отношений с бизнесом? Вероятные сценарии развития ИТ-сервиса приведены в таблице, где выделены четыре сценария отношений ИТ-службы с бизнесом.
Сценарии отношений между ИТ-службой и бизнесом
Сценарий 1: ИТ-служба — «пожарная команда». К этому сценарию ИТ-служба приходит в условиях, когда бизнес не хочет договариваться с ней. Часто он ее просто не замечает как субъект. Она для него ресурс, который он использует. Если такое использование ИТ-службы бизнесу кажется неэффективным, то виновата в этом, как правило, сама ИТ-служба. Попытка еще больше «закрутить гайки» загоняет всю КИС в более «шоковые условия».
Сценарий 2: ИТ-служба — «серый кардинал». Такой сценарий часто возникает при масштабном внедрении ERP-системы в компании, где реально появились лишь фрагментарные бизнес-процессы и вся основная деятельность так и осталась построена на личных отношениях и прецедентах. Удачный запуск системы в эксплуатацию заслуженно приближает руководителя ИТ-службы к первым лицам бизнеса. При этом все руководители бизнес-подразделений обнаруживают новый центр влияния в отношениях, который базируется на «тайном знании» айтшников и «близости» к первым лицам. Иногда это становится сюрпризом и для самих первых лиц. «Серый кардинал», как правило, имеет короткую жизнь и быстро эволюционирует в «пожарную команду». Если бизнес не хочет видеть в ИТ-службе партнера, то ИТ-сервисы в лучшем случае могут завестись в технической поддержке элементов ИТ-инфраструктуры, куда бизнес редко заглядывает.
Сценарий 3: ИТ-служба — «центр компетенции». К такому сценарию ИТ-служба часто приходит с масштабным внедрением ERP-системы в компании, в которой бизнес сознательно регламентирует свою основную деятельность зафиксированными бизнес-процессами. В этом случае бизнес получает высокоэффективную КИС, но в то же время и сильную зависимость от высококвалифицированной команды. В сильной интеграции эффективность оплачивается высокой сложностью КИС. Ценой высокой сложности всегда является высокая квалификация тех, кто с этой сложностью умеет работать. Такую команду надо неплохо оплачивать, да еще и удержать. Они на ИТ-рынке нарасхват. Это одна из «скользких» сторон крупных и даже успешных проектов по созданию сильно интегрированных КИС. «Центр компетенции» всегда балансирует на грани с «серым кардиналом». Для того чтобы не сорваться в сценарий №2, бизнес должен отчетливо понимать те выгоды, которые он получает от внедрения архитектуры сильной интеграции, и те границы, из которых она не должна выйти.
Сценарий 4: ИТ-служба — «сервисный центр». Именно этот сценарий идеально ложится на ITIL. Он имеет свои небольшие модификации. В архитектуре слабой интеграции каталог сервисов может четко соответствовать прикладным сервисам (почта, групповая работа, поиск, регистрация документов, согласование, хранение). В «лоскутном одеяле» каталог сервисов выстраивается вокруг бизнес-приложений («лоскутов»). В любом каталоге сервисы должны быть независимы друг от друга. Это принципиально отличает данный сценарий от сценария №3, где попытка построения каталога сервиса, например, по модулям сильно интегрированной системы приводит к тому, что весь каталог сворачивается в один сервис — доступ к интегрированному приложению. В третьем сценарии 80% инцидентов, связанных с КИС, являются уникальными, такими, которые может понять только небольшая группа специалистов. В то время как ITIL предполагает, что 60 — 70% инцидентов должно разрешаться на уровне Service Desk. Это также цена сложности. Именно в сценарии 4 — сервисного центра — ИТ-сервисы хорошо выносятся на аутсорсинг.
Заключение
Представленный анализ показывает, что возможность построения ИТ-сервисов сильно зависит, во-первых, от желания бизнеса выстраивать партнерские отношения со своими подразделениями, в том числе и с ИТ-службой, а во-вторых, от тех архитектурных решений КИС, к которым стремится сама ИТ-служба. В каждом бизнесе реальная архитектура КИС представляет собой уникальный симбиоз различных типов архитектур, который оказывается чрезвычайно чувствительным к изменениям самого бизнеса и статуса его ИТ-службы. В этом случае построение отношений между ИТ-службой и бизнесом также будет синтезом различных сценариев. Поэтому превращение функций ИТ-службы в ИТ-сервисы — процесс не быстрый, а иногда и обратимый. Видимо, с этим связаны и масштабы использования ИТ-сервисов, приведенные Gartner Group [1]. Ограничения в применении — это свойство любой практически значимой методологии. Если мы не понимаем ее ограничений, значит, мы не понимаем, как эффективно ее использовать. Универсальны только неработающие методологии.
Задачу разработки каталога ИТ-сервисов следует рассматривать в контексте всей ИТ-стратегии бизнеса, которая должна анализировать долгосрочные тенденции изменения самого бизнеса. Особенно остро проблема ИТ-сервисов возникает с появлением у бизнеса планов аутсорсинга. На аутсорсинг можно вынести только сервисы. Многочисленные попытки «вытолкнуть» на аутсорсинг свою ИТ-службу, назвав их функциональные обязанности ИТ-сервисами, всегда заканчивались серьезными проблемами для бизнеса [3]. Представленный анализ показывает также, что вывод на аутсорсинг — процесс постепенный и, возможно, обратимый. Не исключено, что существует и большее разнообразие сценариев развития отношений между ИТ-службой и бизнесом, которое даст новые ниши для ИТ-сервисов. В данной статье автором проведен анализ только тех сценариев, с которыми ему пришлось сталкиваться в реальной практике.
Литература
- Holmstrom Eija. IT Service Management — best practices / Presentation in Moscow. itSMF Russia, 25.04.2007.
- Ананьин В. И. Формирование архитектуры корпоративной информационной системы путем естественного отбора // Intelligent Enterprise, 2006, №17.
- Хейвуд Д. Б. Аутсорсинг. В поисках конкурентных преимуществ. Москва — Санкт-Петербург — Киев, ИД «Вильямс», 2004.
Об авторе:
Владимир Игоревич Ананьин, независимый консультант.На рынке IT с 1987 г. Занимается разработкой корпоративной IT-стратегии, управлением программами создания корпоративных информационных систем. Руководил проектами внедрения ERP систем Oracle Applications, SAP R/3. Занимался созданием и внедрением системы электронного документооборота, внедрением CAD систем. Сфера профессиональных интересов — IT-консалтинг в следующих областях: стратегическое управление корпоративными IT, управление проектами, сервисная организация корпоративных IT-служб и IT-аутсорсинг, контракты в IT. Преподавательская деятельность: курс “Бизнес и IT-стратегия”, Школа IT-менеджмента при Академии Народного Хозяйства при Правительстве РФ, MBA образование для руководителей. Автор ряда статей по тематике IT и управлению проектами.E-mail автора: v.ananiin@gmail.com
|
По сути: IT Service Management (ITSM) - совокупность 10 процессов, описанных в ядре ITIL: томах Service Support и Service Delivery:1. Управление инцидентами (Incident management). Цель процесса - скорейшее устранение инцидентов, под которыми понимаются любые события, требующие ответной реакции: сбои, запросы на консультации и т.п. В тесной связи с данным процессом рассматриваются вопросы создания и управления подразделением, которое является единой точкой контакта с пользователями и координирует устранение инцидентов, диспетчерской службой (Service desk).2. Управление проблемами (Problem management) . Цель - сделать так, чтобы инцидентов стало меньше. Это достигается за счет выявления и устранения причин инцидентов.3. Управление конфигурациями (Configuration management). Цель - создать и поддерживать в актуальном состоянии логическую модель инфраструктуры.4. Управление изменениями (Change management). Каждое изменение делается из благих намерений, но каждое изменение потенциально опасно для инфраструктуры. Цель процесса - допускать только разумные изменения, а также координировать проведение изменений.
5. Управление релизами (Release management). Если считать управление изменениями головой, то этот процесс - руки, которые производят изменения в инфраструктуре. Цель процесса - сохранить работоспособность производственной среды при проведении изменений.
6. Управление уровнем сервиса (Service level management). Зачастую поставщик и потребитель ИТ сервисов по-разному представляют себе, в чем эти сервисы состоят, какие операции и как быстро должны проводиться. Цель процесса - выявить требуемый состав и уровень сервиса, следить за его достижением, а при необходимости - инициировать действия по устранению некачественного сервиса.
7. Управление финансами (Financial management for IT services). Цель процесса - обеспечить надежную финансовую базу для всех прочих процессов.
8. Управление мощностью (Capacity management). Недостаточная мощность инфраструктуры приводит к появлению жалоб на скорость работы, или, хуже того, к невозможности продолжать работу. С другой стороны, излишняя, неиспользуемая, мощность - это впустую потраченные деньги. Цель это ITIL процесса - найти разумный компромисс между затратами и потребностями.
9. Управление непрерывностью (IT service continuity management). Цель процесса - обеспечить гарантированное восстановление инфраструктуры, необходимой для продолжения бизнес-операций , в случае чрезвычайной ситуации: пожара, наводнения, отключения электроэнергии. В последнее время к эти классическим угрозам добавился терроризм.
10. Управление доступностью (Availability management). Доступность - очень часто используемый показатель уровня сервиса. Однако не только обеспечение заданного уровня доступности, но даже определение и измерение доступности настолько сложны, что для всех связанных с доступностью задач организуется отдельный процесс.
http://www.5-55.ru
Проблема управления ИТ-ресурсами и повышения эффективности ИТ-услуг стара, как и само применение этих ресурсов и услуг. Поэтому сейчас, говоря об ITSM, мы имеем в виду новые концептуальные подходы к решению тех вопросов, которые были на теоретическом уровне сформулированы 20 лет назад и оказались реально востребованы фактически только сейчас, в начале нового столетия.
Ключевая идея ITSM в современном ее понимании заключается в необходимости перехода от традиционной модели, где главная цель - это собственно поддержка ИТ-инфраструктуры, к схеме, ориентированной на обслуживание основного бизнеса компании. Решение такой задачи осложняется тем, что для этого потребуется довольно радикально пересмотреть общее позиционирование сервисных ИТ-подразделений в структуре компаний. И тут нужно обратить внимание на две стороны данного вопроса.
Во-первых, ИТ-инфраструктура предприятий зачастую формировалась весьма хаотичным образом, оперативно отвечая на те или иные запросы со стороны основного бизнеса. В результате ИТ-службы обычно представляют собой весьма запутанную структуру, как с технической, так и экономической точки зрения.
Во-вторых, ИТ-департаменты исторически рассматриваются как вспомогательные, сугубо бюджетные подразделения. А это означает (точнее, из этого следует), что руководство компаний не может четко выявить взаимосвязь между инвестициями в развитие и поддержку ИС и повышением эффективности основного бизнеса.
Повышение интереса к концепции ITSM в значительной степени определялось также экономическим кризисом начала нынешнего века, когда во многих компаниях - довольно неожиданно для себя - наряду с дефицитом выделяемых им бюджетов стали ощущать новые требования со стороны руководства в виде необходимости предоставления отчетов по расходам и сведений об ожидаемой прибыли от инвестиций в ИТ-ресурсы. Это подтверждается целым рядом исследований по всему миру. Их результаты говорят также о том, что ИТ-менеджеры не всегда могут четко определить, какие преимущества получают внутренние или внешние клиенты ИТ-подразделений от той или иной услуги.
По оценкам Meta Group, ситуация на рынке такова, что около 75% ИТ-подразделений сегодня выступает в роли не более чем поставщиков инфраструктуры, ориентированных исключительно на ее технологическое развитие вне связи с деятельностью предприятий в целом. В то же время компании хотят пользоваться экономически эффективными ИТ-услугами, отвечающими их индивидуальным потребностям и способными помочь им в решении ключевых бизнес-задач. Поэтому ИТ-департаменты должны предпринять усилия и сделать шаг вперед, который позволит им стать не просто поставщиками ИТ-инфраструктуры, а настоящими сервис-провайдерами, а затем и стратегическими партнерами руководства компаний, предоставляющими широкий спектр услуг, эффективность которых поддается достаточно простой оценке со стороны их потребителей.
Meta Group считает, что во всем мире только 25% компаний приступило к внедрению сервисной модели обслуживания и лишь 5% из них удалось вырасти до того уровня (по состоянию на 2003 г.), когда ИТ-подразделение становится для своей компании ценным стратегическим ресурсом. Однако по прогнозам, приведенным в том же отчете, в ближайшие три года такой переход сможет осуществить подавляющее большинство ИТ-подразделений крупных и даже средних компаний.
По сути дела, концепция ITSM полностью соответствует общей нацеленности заказчиков на более широкое использование ИТ-аутсорсинга, в том числе и в сфере услуг. Таким образом, задачей ИТ-подразделений становится применение модели аутсорсинга на внутреннем уровне своей организации. И в этой связи аналитики предупреждают: тех, кому не удастся успешно реализовать новые принципы работы, скорее всего ждет расформирование, а их функции будут возложены на внешние специализированные организации.
Андрей Колесов
Ниже представлена Модель ITSM от компании HP:
IT Service Management Reference Model от компании HP:
Tags: ERP, IT, ITIL, ITSM, service desk, ИТ-служба, КИС
Для многих сфер деятельности созданы и формализованы эталонные модели, обобщающие передовой опыт работы. Для ИТ услуг такой опыт обобщен в ITIL (Information Technology Infrastructure Library), библиотека передового опыта управления ИТ услугами.
Tags: IT, ITIL, ИТ услуги
