Библиотека стандартов ITIL сегодня очень популярна в ИТ-индустрии и широко используется в больших компаниях. Однако, традиционно ITIL воспринимается как best practice проектирования различных сервисов и ИТ-инфраструктуры компании. Но на ITIL можно обратить внимание и с точки зрения информационной безопасности. Ведь в требованиях к проектированию ИТ-инфраструктуры предъявляется и обязательное обеспечение конфиденциальности информации. Отчасти сюда же можно отнести и отказоустойчивость, как элемент свойства доступности информации.
В сегодняшней публикации мы совсем кратко коснемся вопросов рассмотрения ИБ в свете библиотеки стандартов ITIL
В последнее время обеспечение IT-безопасности стало одной из важнейших задач менеджмента. Сегодня компьютерные сети разворачиваются не только в рамках одной организации, но и между несколькими партнерами по бизнесу. Все больше компаний начинают предлагать свои продукты и услуги через Интернет.
Все это многократно повышает опасность утечки персональных данных и конфиденциальной информации, хакерских и других атак. Ведь как компании, так и корпоративная информация становятся все более доступными, а это не может не сказываться на конфиденциальности данных. Следовательно, нужна продуманная система управления IT-безопасностью. Данному вопросу посвящен отдельный раздел библиотеки ITIL.
Поговорим об ITIL и ITSM. Часть 1
Введение в ITIL
В первую очередь необходимо разобраться, что представляет собой библиотека ITIL и как она связана с безопасностью. Итак, библиотека ITIL (IT Infrastructure Library) была разработана около 20 лет назад Центральным агентством по вычислительной технике и телекоммуникациям (Central Computer and Telecommunications Agency, CCTA) в Великобритании. Перед CCTA стояла задача структурирования всех существующих методов успешного использования IT-ресурсов и разработки способов их качественного применения. Таким образом, библиотека ITIL призвана оптимизировать набор процессов, направленных на обеспечение высокого качества IT-услуг и повышение уровня предоставляемых услуг. Результатом применения ITIL в организации должно стать повышение конкурентоспособности компании в целом.
Библиотека прежде всего разъясняет, что должно включаться в управление IT-услугами и как обеспечить качество этих услуг. В настоящее время ITIL становится стандартом де-факто в области информационных технологий. Однако ее нельзя использовать как прямое руководство к действию. Дело в том, что библиотека описывает только лучшие практики, которые на деле обязательно должны быть адаптированы к нуждам конкретной организации.
Особо отметим, что библиотека ITIL содержит отдельную книгу по управлению IT-безопасностью, которая называется Security Management. Она помогает гармонично интегрировать процесс управления IT-безопасностью в общую систему управления информационными технологиями в компании.
Как часть ITIL, управление IT-безопасностью играет очень важную роль. Правда, материалы ITIL не содержат конкретных требований к средствам защиты, а лишь описывают общую организацию работ. Другими словами, они рассматривают проблему IT-безопасности через призму бизнеса и дают общие рекомендации, что необходимо включить в управление IT-инфраструктурой в обязательном порядке, чтобы максимально обезопасить бизнес.
Предоставление ИТ-услуг как создание локальных ценностей для заказчика и потребителей
В рамках ITIL процесс управления IT-безопасностью ставит перед собой две цели: выполнение всех договоренностей между поставщиком и заказчиком IT-услуг в установленные сроки и обеспечение базового уровня информационной безопасности, не зависящего от внешних требований. Заметим, что роли поставщика и заказчика IT-услуг могут выполнять не только отдельные предприятия, но и разные департаменты одной организации.
Согласно ITIL, процесс обеспечения IT-безопасности состоит из нескольких этапов (см. рисунок).
Прежде всего он включает обеспечение базового уровня IT-безопасности, затем определение требований заказчика и анализ этих требований, далее подписание соглашения об уровне сервиса и, наконец, реализацию и контроль выбранного решения, отчетность и модификацию. Часть шагов циклически повторяется, обеспечивая тем самым постоянное взаимодействие всех участников процесса.
Первые шаги нового стандарта
На нулевом шаге процесса задача поставщика заключается в том, чтобы обеспечить заказчику базовый уровень IT-безопасности. Здесь сразу же следует заметить, что в качестве поставщика и заказчика необязательно выступают различные организации, скажем консалтинговая фирма и коммерческая компания. Напротив, библиотека ITIL позволяет оптимизировать IT-процессы даже в рамках одной организации. Так, заказчиком может стать отдел маркетинга или продаж, а поставщиком — IT-департамент или служба IT-безопасности.
Предположим, поставщиком услуг является IT-департамент компании. Тогда на нулевом шаге он обязан предоставить некоторый набор типовых методов защиты информации, описанных в ITIL. Таким образом, даже если заказчик явно не требует, чтобы поставщик установил и настроил межсетевой экран или антивирус, поставщику все равно придется это сделать, если, конечно, он работает в рамках ITIL. Отметим, что в некоторых случаях, когда ценность защищаемых ресурсов невелика, базового уровня безопасности может оказаться вполне достаточно. Правда, на практике такая ситуация встречается крайне редко.
На следующем (втором) шаге происходит определение требований заказчика, причем выражаются они в форме пожеланий — как заказчик видит процесс обеспечения IT-безопасности в интеграции с общими целями и задачами бизнеса. Эти пожелания будут еще неоднократно пересматриваться, модифицироваться и уточняться.
Далее IT-департамент проводит комплексный анализ всех требований заказчика и определяет возможность реализации их на практике (согласование сроков, соответствие выделенного бюджета намечаемой работе, обеспечение необходимого уровня IT-безопасности и т.п.). Если IT-департамент решает, что предпочтения заказчика по каким-то причинам не могут быть выполнены, например из-за несогласованности требований с бюджетом или же с базовым уровнем безопасности, то весь процесс возвращается на шаг назад. Представитель IT-департамента еще раз встречается с заказчиком, чтобы предоставить анализ требований, высказать пожелания и прийти к взаимовыгодному соглашению. На данном этапе все зависит от навыков ведения переговоров у представителя поставщика. От того, сумеет ли он доказать заказчику, что первоначальные требования не принесут ожидаемых результатов и что для эффективной безопасности необходимо выделить дополнительные средства, зависят условия дальнейшего сотрудничества.
Процесс обеспечения IT-безопасности в рамках ITIL
SLA — сердце ITIL
Придя к консенсусу, поставщик и заказчик фиксируют свои договоренности в разделе о безопасности документа SLA (Service Level Agreement) — соглашении об уровне услуг, по сути являющемся основой взаимодействия между заказчиком и поставщиком. В SLA определяется степень ответственности обеих сторон, причем все условия оговариваются в нетехнических терминах, на уровне понимания заказчика.
Соглашение, как правило, имеет иерархическую структуру. Концептуальные вопросы решаются с самим заказчиком, а действия конкретного характера согласуются уже с руководством подразделения или представителем заказчика.
В SLA отдельно оговаривается уровень ответственности каждой из сторон, чтобы в случае нарушения информационной безопасности вопрос «кто виноват?» даже не возникал. По умолчанию поставщик отвечает только за безопасность IT-инфраструктуры, но не за конкретные действия пользователей. В целом чем подробнее описан раздел об уровне IT-безопасности в SLA, тем более защищенным будет бизнес.
Внедрение SLA: неочевидные проблемы
Политика IT-безопасности компании и существующая система управления IT-безопасностью в организации — вот базис, на котором строится вся защита. А что делать, если политика расходится с основными необходимыми требованиями IT-безопасности, то есть грубо нарушается базовый уровень? Например, сотрудники компании никогда не создавали учетные записи.
Они уверены, что запоминание паролей, трата времени на авторизацию — занятие бессмысленное. Заказчик IT-услуг не хочет менять сложившиеся традиции в компании и категорически отказывается вводить пароли, потому что не видит в них особого смысла. Конечно, такой пример может показаться тривиальным, но на практике требования заказчика зачастую бывают еще более абсурдными.
В этом случае поставщик IT-услуг, конечно, может, несмотря ни на что, слепо выполнять все пожелания заказчика. В конце концов, кто платит деньги, тот и заказывает музыку. Однако такая позиция расходится с одной из основных задач процесса управления IT-безопасностью.
Если поставщик IT-услуг ставит перед собой цель не сиюминутной наживы, а прежде всего успешного завершения проекта и поддержки своей репутации, ему придется предупредить заказчика о неэффективной политике компании. Возможно, даже придется настоять на кардинальных изменениях, что заказчик наверняка воспримет в штыки. Следовательно, задача поставщика заключается в том, чтобы убедить заказчика в целесообразности перемен. Не важно, будет ли это описание всего спектра потенциальных угроз либо концентрация внимания заказчика на преимуществах предлагаемой защиты, главное — чтобы заказчик сам увидел уязвимость своей политики и захотел ее исправить.
Этап конкретизации в SLA
После того как политика IT-безопасности приведена в соответствие с базовым уровнем, стороны переходят к согласованию конкретных действий по реализации требуемого уровня IT-безопасности.
Самое слабое звено в процессе обеспечения IT-безопасности — это, конечно же, персонал. Никогда нельзя предугадать все действия пользователей: одни по незнанию, другие, наоборот, обладая очень глубокими знаниями, могут нарушить конфиденциальность или целостность информации. Во избежание этого в договоре оговариваются роли пользователей, степень доступности информации для каждой из них, организация обучения персонала. В некоторых случаях следует определить стратегию действия пользователей в случае возникновения инцидентов или сбоев в работе.
Важным аспектом в защите информации является то, что пользователи сами могут определять уязвимые места в IT-безопасности компании. Для этого следует обеспечить двустороннюю связь с IT-департаментом: служащий должен иметь возможность сообщить о найденной уязвимости специалистам, а представители IT-департамента должны обеспечить пользователю своего рода обратную связь, то есть показать, как департамент отреагировал на запрос служащего.
Заказчик и поставщик определяют степень ответственности каждой из сторон в случае нарушения IT-безопасности персоналом. Например, если пользователь нечаянно удалил важную информацию, что принесло компании ущерб, но его роль, прописанная в договоре, не запрещала этих действий, то ответственность за нарушение сотрудника несет заказчик.
После того как общие принципы «защиты от дурака» определены и основные роли пользователей назначены, заказчик и поставщик IT-услуг согласовывают технические средства для обеспечения IT-безопасности: оговаривают средства шифрования информации, методы разграничения доступа и т.д. В принципе, особо важная и сверхсекретная информация может нуждаться в физической защите и физическом наблюдении. Если требуется организовать видеонаблюдение или предоставить охрану, заказчик и поставщик должны оговорить данный вопрос отдельно. Каждому разделу SLA назначаются ответственные люди, которые осуществляют контроль своих направлений. Кроме того, указываются отчетный период и форма отчетности.
В SLA заказчик и поставщик IT-услуг оговаривают так называемые форс-мажорные обстоятельства. Для обеспечения непрерывности бизнеса определяются стратегически важные объекты, возможность их восстановления и альтернативные способы работы в случае критичных сбоев.
Подробное описание данного раздела одинаково важно как для бизнеса заказчика, так и для поставщика (будь он консалтинговой компанией или внутренним IT-департаментом). Бизнес в лице заказчика стремится обеспечить конкурентное преимущество на рынке за счет непрерывности бизнес-процессов.
Поставщик IT-услуг, в свою очередь, заинтересован в обеспечении максимальной надежности предоставляемых им услуг. Однако все непредвиденные обстоятельства учесть невозможно, да и особого смысла в этом нет. Какова, например, вероятность землетрясения в Центральном федеральном округе? Она практически равна нулю.
Поэтому включать эту угрозу в план по обеспечению непрерывности работы бизнеса в случае землетрясения нецелесообразно. Таким образом, важно соблюдать баланс и руководствоваться правилами логики и здравого смысла.
Возникает вопрос: насколько досконально нужно описывать раздел об управлении IT-безопасностью в SLA? С одной стороны, чем подробнее зафиксированы права и обязанности обеих сторон, тем меньше недоговоренностей остается между заказчиком и поставщиком. С другой стороны, все учесть в договоре практически нереально.
Талмуд с описанием всех возможных случаев писать не стоит. SLA должен быть четким, структурированным, понятным и доступным. Как найти грань между достаточной полнотой, удобочитаемостью и ясностью? Этот вопрос в каждом случае решается индивидуально и зависит от интуиции и опыта обеих сторон.
Операционное соглашение об уровне услуг (OLA)
Зафиксировав все договоренности в SLA, поставщик заключает операционное соглашение об уровне услуг (Operating Level Agreement, OLA) с исполнителями, которые прописаны в SLA как ответственные за то или иное направление. Непосредственными исполнителями могут выступать внутреннее IT-подразделение компании (тогда OLA заключается с представителем IT-департамента), сам поставщик, а также любая сторонняя компания.
В OLA поставщик IT-услуг и исполнитель конкретизируют договоренности о том, как именно будет достигнут необходимый уровень сервиса. Например, если в SLA зафиксировано, что некоторый особо важный объект должен быть обеспечен физической защитой, в OLA оговариваются детали защиты: скрытое наблюдение, охрана, ограничение доступа и т.п.
В частности, в рамках OLA происходит определение, разработка и формулирование внутренних требований безопасности для IT-услуг. Кроме того, исполнитель отвечает за мониторинг стандартов безопасности. Если стандарты безопасности поменялись, исполнитель должен сообщить об этом поставщику. Поставщик IT-услуг, в свою очередь, встречается с заказчиком и предлагает внести определенные изменения в SLA согласно новому стандарту.
В OLA поставщик IT-услуг и исполнитель фиксируют роли, задействованные в выполнении OLA, а также определяют ответственных на более низком уровне.
Этапы реализации
На следующем шаге осуществляются реализация и контроль всех соглашений. Поставщик IT-услуг передает SLA и OLA непосредственному исполнителю в форме плана по безопасности, который исполнитель обязуется реализовать в рамках оговоренных сроков. План по безопасности описывает политику внедрения IT-систем. Процесс реализации всех соглашений по IT-безопасности контролируют менеджеры вышестоящего уровня, они оценивают результаты и в случае несоответствия SLA и OLA возвращают его на доработку.
Остановимся более подробно на оценке запланированных мероприятий. Вначале заказчик сам может попытаться оценить деятельность исполнителя. Затем следует организовать внутренний и внешний аудит запланированных мероприятий. С целью обеспечения независимости экспертизы для проведения внутреннего аудита в компании-исполнителе возможно создание специального отдела.
Для проведения внешнего аудита поставщик IT-услуг должен нанять независимую стороннюю организацию. В сроки, оговоренные в SLA, поставщик IT-услуг предоставляет заказчику отчет, в который включается информация о выполненной работе, результаты внутреннего и внешнего аудита, а также дальнейшие планы по реализации соглашений.
Отметим, что иногда приходится вносить изменения в первоначальные соглашения. Все-таки обеспечение IT-безопасности — процесс динамический. Он зависит не только от внешних факторов, таких как изменение стандартов IT-безопасности, но и внутренних (развитие и расширение компании, изменение политики организации).
Поэтому инициатива по внесению изменений в первоначальные соглашения может исходить как от заказчика, так и от поставщика IT-услуг. В случае если возникает необходимость в модификации IT-инфраструктуры, поставщик и заказчик пересматривают предыдущее соглашение, предлагая внести в него определенные поправки. В результате круг замыкается, и весь процесс обеспечения IT-безопасности возвращается на первый шаг.
Заключение
В заключение отметим, что обеспечение IT-безопасности компании не самоцель, а лишь одно из звеньев процесса управления IT-услугами. Поэтому следует найти определенный баланс между доступностью и конфиденциальностью информации, чтобы IT-безопасность не стала ступором для бизнес-процессов компании. Подход в каждом конкретном случае индивидуален, общих рецептов на этот счет нет.
Библиотека ITIL предоставляет возможность IT-специалистам изучить лучшие примеры из практики по оптимизации работы IT-услуг, чтобы разработать свой, уникальный метод повышения качества IT-услуг. Другими словами, на практике следует использовать ITIL, чтобы адаптировать IT-услуги наилучшим образом для достижения целей бизнеса и ожиданиям заказчика. Такие гранды, как Microsoft, IBM и Hewlett-Packard, уже внедрили ITIL, создав тем самым для себя дополнительные конкурентные преимущества.
Источник: ipiskunov.blogspot.com
10 фактов, которые вы должны знать об ITIL
В последнее время в ИТ-кругах часто можно услышать термин ITIL в отношении построения работы ИТ-подразделения, предоставления услуг бизнесу или нового способа организации технической поддержки. Однако не все ИТ-менеджеры точно понимают, о чем речь. Приведем 10 ключевых фактов, которые сделают определение ITIL более понятным.
Внедрение ITSM-системы ServiceNow
1. ITIL расшифровывается как IT Infrastructure Library (библиотека инфраструктуры информационных технологий)
Библиотека ITIL содержит полный и подробный набор лучших практик, которые используются для разработки и осуществления управления ИТ-услугами. Реализация этих практик дает бизнесу целый ряд плюсов:
- Увеличение конкурентного преимущества за счет снижения затрат и гибкости управления.
- Повышение эффективности за счет оптимизации ИТ-процессов.
- Понимание ИТ для бизнеса и усиление значимости.
- Повышение удовлетворенности пользователей и клиентов.
2. Организация, разрабатывающая и поддерживающая ITIL, находится в Великобритании
Библиотека ITIL появилась в 1980-х по заказу британского правительства. Работа над ней велась с 1986 по 1989 год, а публикации начались с 1992 года. Однако долгое время за пределами Великобритании она была мало известна, пока большое число крупных компаний не заявило об использовании ITIL, а в СМИ не стали появляться публикации об опыте внедрения. На протяжении всего времени существования библиотеки она продолжает активно развиваться и сейчас доступна уже третья версия (ITIL v. 3).
На сегодняшний день более 10 000 компаний по всему миру используют ITIL для управления ИТ.
3. ITIL
В процессе развития библиотеки ITIL меняло число книг и их организацию.
Сейчас актуальна третья редакция ITIL (ITIL v.3), которая была выпущена в мае 2007-го. Она была сильно переработана по сравнению со второй, чтобы поддержать новый подход «формата жизненного цикла услуг».
ITIL v. 3 содержит уже только 5 книг, а не 7, как во второй редакции:
- Стратегия услуг (англ. Service Strategy),
- Проектирование услуг (англ. Service Design),
- Преобразование услуг (англ. Service Transition),
- Эксплуатация услуг (англ. Service Operation),
- Постоянное улучшение услуг (англ. Continual Service Improvement).
Кроме того, в эту редакцию входят еще две книги: Обзор ITIL и Карманный справочник, а также набор дополнительных отраслевых рекомендаций.
4. Чтобы добиться успеха c ITIL, необходим сильный инициатор
Внедрение практик ITIL – это изменение корпоративной культуры. На первых этапах пользователи будут недовольны тем, что им приходится делать все иначе, чем раньше, не так, как они привыкли. Чтобы преодолеть это скепсис, необходим сильный инициатор – «локомотив», которой сможет убедить людей и продвинуть проект, а также заинтересовать бизнес в изменении ИТ. Без такого человека реализация не приведет к желаемому успеху.
5. ITIL не средство управления проектами
Практики ITIL сфокусированы на предоставлении ИТ-услуг организации и процессе непрерывного совершенствования услуг и процессов их обеспечивающих, а не на управлении проектами компании.
6. Библиотеки ITIL содержат не так много информации
Библиотека содержит передовые подходы и лучшие практики для организации модели предоставления ИТ-услуг. В ней описаны некоторые процессы и шаблоны, но не детальная методология реализации процессного подхода. Компания, которая принимает решение использовать ITIL, получает общие принципы, но конкретные процессы должна разработать под свою инфраструктуру самостоятельно. Для более практического изучения построения ИТ согласно методологии ITIL можно пройти новый курс ITIL® Practitioner, направленный именно на людей, которые уже хорошо освоили модель предоставления ИТ-услуг для бизнеса, но не понимают, как лучше реализовать свои знания.
7. ITIL – это не инструмент
Для реализации принципов ITIL можно использовать многие профессиональные инструменты, но это совсем не обязательно. Если компания небольшая, будет вполне достаточно простых шаблонов документов и электронных таблиц, а для крупных организаций потребуется специализированное программное обеспечение.
8. ITIL не применяется по принципу «все или ничего»
Поскольку ITIL описывает подходы из разных областей, то компания может применять все сразу или только некоторые из них – нет строгих регламентов.
9. Практики ITIL можно реализовывать поэтапно
Так как нет правил, что внедрить необходимо сразу все практики, многие компании выбирают поэтапное внедрение в течение определенного периода. Это позволяет экономить ресурсы и добиться стабильного успеха на каждом из промежуточных этапов.
О важности поэтапного внедрения практик ITIL на примере ITSM мы уже писали в блоге.
10. Сертификация по ITIL
Существуют три основных уровня сертификации по ITIL:
- Foundation. Этот уровень означает, что вы понимаете основные термины и имеете базовые знания о модели ITIL.
- Practitioner – ваших знаний модели ITIL достаточно для применения конкретных процессов на практике.
- Intermediate – для специалистов с углубленными знаниями отдельных разделов ITIL.
А также есть уровень ITIL Expert, подтверждающий умение его владельца управлять всеми процессами ITSM как единой системой, и ITIL Master для руководителей ИТ-департаментов.
Знание этих 10 фактов позволит вам понять основные принципы ITIL, но для получения более глубоких знаний мы рекомендуем либо пройти сертифицированные курсы, которые позволят принять решение об использовании данных практик для своей организации, либо обратиться в компанию, занимающуюся автоматизацией бизнес-процессов и созданием сервисной модели по методологии ITIL.
Оставайтесь в курсе событий
Подписывайтесь на рассылку новых материалов блога по почте
Источник: it-guild.com
ITIL и ITSM — история большого обмана. Есть ли польза? Сколько это стоит и кому точно НЕ стоит «внедрять ITIL»?
Почти каждый день мы, в Okdesk, сталкиваемся с вопросом потенциальных клиентов «Соответствует ли ваш Help Desk ITIL-у?». Пришло время раскрыть историю большого обмана, связанного с этими 4-мя буквами.
ITSM — известный и подтвердивший свою эффективность годами подход к организации процессов управления ИТ. ITIL — источник лучших практик ITSM. Огромное количество статей на Хабре по теме ITIL/ITSM лишь подтверждает широкий интерес к теме.
В прошлом году вышла очередная версия библиотеки ITIL. “Концепция”, пожалуй, стала даже шире самой ИТ-отрасли. А очередная версия библиотеки только подтверждает актуальность порожденных ею изменений в подходах к управлению ИТ с учетом развития технологий, новых вызовов и т.д.
Однако так ли уж полезен ITIL и ITSM? В чем и кого он «обманул»? Имеет ли смысл следовать его рекомендациям, особенно среднему и малому бизнесу, и когда? Стоит ли его внедрять и сколько это вообще стоит?
ITIL и ITSM. Что это? Предыстория и основные моменты
ITSM — это подход к управлению и организации услуг в ИТ, детали реализации и лучшие практики из опыта подразделений и целых компаний которого описаны, например, в известной на весь мир серии документов ITIL.
Упомянутая библиотека появилась в конце 80-х годов прошлого века по заказу правительства Великобритании. Изначально они разрабатывались, чтобы обеспечить должный уровень качества ИТ-услуг в государственных учреждениях. Но довольно быстро подход пришелся по вкусу и бизнесу. В середине 90-х выпущенная библиотека получила наименование ITIL, а к ее обновлению подключилось независимое профессиональное сообщество itSMF.
На сегодняшний день формально ITIL является собственностью Комитета по вычислительной технике и телекоммуникациям при правительстве Великобритании. А распространением библиотеки и сертификацией учебных центров занимается компания Axelos, принадлежащая правительству Великобритании и местной Capita. Теперь эта инициатива, в комплекте с не дешевыми образовательными курсами, экзаменами, локальными и международными форумами, вполне коммерческая.
Хотя изначально все было ориентировано на госструктуры и ИТ, по мере развития документов они адаптировались для применения бизнесом, в том числе за пределами отдельно взятой отрасли. Правда, основная концепция и «объектная» модель при этом не менялись. Зато методология получала дополнения, связанные с последними современными тенденциями — тем же аутсорсингом.
Библиотека ITIL, а значит и ITSM как подход, использующий практики библиотеки, строится вокруг термина «Услуга». Для работы с услугами «организуются» процессы, а их функционирование обеспечивают определенные роли. В ITIL v4 дополнительно появился термин «практики» и другие новые абстракции, с помощью которых описание происходящего попытались сделать более детальным и осмысленным на исходе 2-го десятка 21 века.
ITIL. Как это использовать?
Важно понимать (об этом то нам явно ни на каких курсах не рассказывают), что рекомендации ITIL всегда были ориентированы на крупные «инфраструктуры» и компании — специально для них функции, компетенции и роли прописывались максимально детально. В редакции ITIL v3 от 2011 года только основных процессов — 26, а ведь некоторые из них можно разбить на несколько подпроцессов.
Несмотря на такое обилие информации, вопросы про конкретику остаются за кадром, поскольку задача библиотеки — рассказать о лучших подходах, а не о конкретной реализации в какой-то компании. Крупный бизнес весь этот объем информации может трактовать и, собственно, всегда трактовал очень по-разному.
Но небольшие компании никогда не находили ответов на самый важный для них вопрос: «что именно сделать в первую очередь». И именно в этом заключается основной «обман». ITIL — слишком верхнеуровневая абстракция, он слишком избыточен, слишком далёк, слишком сложен для любого бизнеса, а для среднего и малого бизнеса так практически не применим. Причем эта «неприменимость» связана как с выстраиванием внутренних процессов управления, так и с оказанием услуг внешнему заказчику. Это однако, не мешало тысячам, получивших диплом о прохождении базового курса, хотеть и желать всё сделать «по ITIL».
Внедрение ITIL. Есть ли смысл? Какие преимущества?
Чтобы не быть голословным, обратимся к цифрам.
В отечественном исследовании itSMF 2013 (к сожалению, новее ничего нет, однако вряд ли ситуация кардинально изменилась) года 41% ИТ-руководителей сообщали, что бизнес просто не видит преимуществ от внедрения ITSM. Хотя к тому моменту история развития ITIL насчитывала уже не один десяток лет, в бизнесе прижились лишь основные процессы — управление инцидентами и запросами на обслуживание.
Эти же процессы оказались самыми автоматизированными. А еще 24 процесса, описанные в методологии, пользовались заметно меньшим спросом. И дело не только и не столько в том, что эти процессы дают понятную и осязаемую ценность. Дело в том, что выстраивание любого процесса по ITIL предусматривает огромные затраты — финансовые, временные и организационные. В итоге если крупные компании под давлением советов директоров и «рынка» стараются «внедрять ITIL» (прим. здесь и далее фраза используется как некий «мем», характеризирующий зрелость рынка в понимании объекта обсуждения этой статьи, потому что, конечно, «внедрить ITIL» — то есть внедрить библиотеку — терминологически невозможно), то средний и малый бизнес этого делать не торопится.
Тот факт, что малый и средний бизнес не бежит, сломя голову, внедрять ITSM, виден и по сертификации. Список ITIL Expert-ов и сервис-менеджеров из России и стран СНГ, опубликованный на сайте itSMF России, включает чуть менее 350 человек. И большинство из них работают именно в крупных компаниях. На статистике сдавших экзамены отчетливо видны пики популярности сертификации под конец года — в период массового освоения бюджетов у «крупных» в России и Европе. При этом доля сдававших базовый экзамен сильно превалирует над всеми остальными экзаменами вместе взятыми.
Так нужен ли массам этот ITIL? Почему он так популярен?
Альтернативы ITIL. В чем отличия?
Не одним ITIL живет отрасль. В той же Великобритании разработан структурированный подход Prince2 — PRojects IN Controlled Environments — для управления социальными проектами. В принципе, он подходит даже для компаний из ИТ-сегмента. Кстати, по статистике сданных экзаменов он всего раза в 2 уступает ITIL, а права на торговую марку (и сертификацию) принадлежат все тому же Axelos.
У некоторых крупных мировых корпораций есть собственные теории относительно управления ИТ. Например, IBM в 70-х годах прошлого века сформулировала ITPM (IT Process Model) — стандарт, который по ряду ключевых моментов отличается от ITIL. А Microsoft использует MOF (Microsoft Operations Framework), который, наоборот, очень похож на ITIL, но ориентирован на собственные продукты компании.
Для небольших компаний также разрабатывался FITS, но, вероятно, потому что на нём не удалось заработать, проект «успешно» загнулся.
Есть и другие стандарты менеджмента ИТ услуг например, ISO 20000. Однако всем им до ITIL по популярности очень далеко, а фразы типа «внедрить ITIL» от клиентов, «согласно ITIL нужно делать так» от экспертов или вопросы к разработчикам вида «ваша система разработана на основе ITIL?» давно стали крылатыми. Так стоит ли «внедрять ITIL», кому стоит это делать и сколько всё это стоит?
Сколько стоит «внедрить ITIL» и «автоматизировать по ITIL»? Причем тут масштаб?
ITSM — это в первую очередь подход, который подразумевает изменение процессов (лично я давно запутался в их реально количестве) в компании. Несомненно такие перемены, как и любые организационные изменения, требуют времени и сил. Нужны люди, разбирающиеся в том, как “это работает”, то есть в библиотеке и особенностях ее применения (сертифицированные, а значит претендующие на определенный уровень оплаты труда). Но это лишь одна сторона медали под названием «внедрение по ITIL».
Понятно, что вся эта громадная «машина лучших практик», с историей, рекламой, товарными знаками, экспертами, курсами и сертификациями должна всем участникам приносить деньги. И приносит. Достаточно посмотреть на стоимость внедрения этого самого «передового опыта». А чтобы иллюзии окончательно исчезли, «приправить» блюдо системой автоматизации, тоже «на основании ITIL», которую еще и поддерживать нужно из года в год.
Информация о проектах организации процессов и их автоматизации всегда есть в открытом доступе. И это лишь малая, далеко не самая шокирующая цифрами, их часть:
- тендер на приобретение услуг по внедрению автоматизированной системы Service Desk и на приобретение лицензий АС Service Desk (BMC Remedy) в 2012 года на ~ 20 млн. рублей;
- тендер на передачу прав на использование OMNITRACKER выполнение работ по внедрению и сопровождению системы автоматизации на базе продукта OMNITRACKER в 2013 году на ~ 10,5 млн. рублей
- тендер на техническую поддержку HP Service Manager и HP Operations в 2016 году на почти 10 млн. рублей;
- поддержка Axios Assyst в 2018 году на почти 5 млн. рублей.
Внедрение ITIL и ITSM. Когда окупится?
Окупаются затраты только в том случае, когда масштабы работы довольно большие. Внедрение и последующее сопровождение ITSM в компании требует определенных трудозатрат — поддержание базы данных конфигураций, инцидентов, написание и актуализация регламентов и должностных инструкций. Но выигрыш от этой деятельности при малой сложности инфраструктуры не так заметен. Эту идею хорошо иллюстрирует анализ точки безубыточности, произведенный в статье “ITSM и бизнес” в журнале Открытые системы. СУБД (картинка из той же статьи):
У небольших компаний зачастую нет возможности внедрить «по ITIL» или тем более автоматизировать какой-то аспект деятельности с помощью Enterprise решений. У него не всегда есть средства даже на недорогое ПО и базовую автоматизацию своих процессов. А кроме того даже в ИТ-сегменте затраты на это малому бизнесу не отбить, не говоря уже о бизнесе в более традиционной области, где и доходность может быть ниже.
Гибкое решение, не требующее кардинальных изменений в структуре бизнеса и подсказывающее, что изменить прямо сейчас и получить выгоду (пусть и небольшую) завтра, обойдется дешевле и вызовет бОльший энтузиазм у руководителей.
Что делать и чего не делать малому бизнесу? Советы и рекомендации
Так что же делать среднему и малому бизнесу? Выкинуть из головы термины ITIL и ITSM?
Вовсе нет! Если хочется расширить кругозор или узнать «как нужно организовывать процессы управления ИТ в лучших (читать — самых крупных) домах Европы», то, несомненно, погрузиться в это стоит. Главное, понимать что скрывается за одной из самых известных в ИТ-отрасли по всему миру аббревиатуре, сколько это стоит и для кого всё это подходит.
Если переходить к конкретике, что делать и чего не делать малому и среднему бизнесу, то далее несколько советов.
НЕ нужно внедрять ITIL или «лучшие практики»
Модель управления в малом и среднем бизнесе не обязательно должна быть основана на библиотеке ITIL в общем или в частном. Такой бизнес обычно хочет увидеть готовое решение своих проблем. У него нет возможности выделить специалиста, чтобы тот изучал все тома последней редакции гибкой и всеобъемлющей библиотеки (для ITILv3 это 7 книг) или получил сертификацию ITIL Мастера за несколько сотен тысяч рублей и месяцев потраченного времени.
У малого бизнеса нет ресурсов и потребности в найме владельцев каждого из внедряемых процессов и т.п. Такой порог входа для него слишком велик.
Поэтому первое, что нужно осознать — серебряной пули нет и пытаться после 3-х дневного, пусть даже очного курса по основам ITIL, внедрить его у себя в небольшой компании нет абсолютно никакого смысла. ITIL не для малого и среднего бизнеса.